On 11/16/06, James Simmons <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
