Messages in this thread | | | Date | Thu, 16 Nov 2006 22:48:20 +0100 | From | "Miguel Ojeda" <> | Subject | Re: ACPI output/lcd/auxdisplay mess |
| |
On 11/16/06, James Simmons <jsimmons@infradead.org> wrote: > > > > > cfag12864bcfb is a "fbdev" (actually, it is a "fb wrapper" for > > cfag12864b, so it behaves like a framebuffer, although it is not an > > usual framebuffer. f.e. it has asynchronous refresh rate, a mmaped > > page to appear to be a fb...). > > BTW to use it as a fb you need to set the FILLRECT etc. See Kconfig in the > drivers/video directory and look at one of the graphic card examples.
I see, thanks you. I will take care of that.
> > > Still, it is not the front panel lcd of any specific device like PDA, > > so people that expects only their primary video/ displays may be > > confused if it appears at such section. So we decided to go away from > > video/. Maybe we can change the description, as right now it only > > refers to front panel lcds. > > Neither is a monitor for a PC desktop. That is why we have ddc. If I > take a desktop with more than one video card and swap the lcd monitors > the lcd monitor data remains the same. As soon as the display device is > attached to the graphics card the graphics card will then communicate > with the monitor to retrieve data. For example if the mode of the > graphics card is set to 1900x1080 which is supported by the current > monitor. Then we swap it for a CRT that supports only 1280x1024 then in > that case when the graphics card probes the CRT it will change the > resolution to the maximum that is supported by the CRT. > Currently the fbdev layer handles all this with struct fb_monspecs. Now > I know that structure doesn't cover everything. Nor does it handle > multiple displays attached to one piece of hardware. These where things I > was hoping to fix. Now that there are display devices that can handle > there own power management I have no problem having another sysfs device > to handle it. A representation that is more generic than lcd in the > backlight directory. Like the output device suggested by Yu. Of course I'm > not fond of that name. Display would be better. >
Yep, indeed it would be better to have both generic place and sysfs device to put all these generic displays, however, I think they shouldn't be at video/* (maybe video/something/* or outside). I mean, we can do something like:
1. First, we move auxiliary-special displays (including cfag12864b, [*]"Arc Monochrome LCD board" and stuff like that: they aren't really primary video displays) to another folder outside video/, maybe "drivers/display/" ("drivers/auxdisplay/"...). 2. Then we create a sysfs device, called "display" ("auxdisplay"...) for all of them, which must be generic as you suggested, not just lcds or "front panels".
So finally we will have usual-primary fbdevs and video drivers at "drivers/video/*", and all the other stuff at "drivers/display/*" or some similar place.
Is that a good suggestion?
[*] I saw fbdevs like "Arc Monochorme LCD board support" that can be put there the same way like auxdisplay/cfag12864b, as they look pretty similar.
-- Miguel Ojeda http://maxextreme.googlepages.com/index.htm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |