Message-ID: <653402b90611161348k163a004ax483f1c2bc6928fd9@mail.gmail.com>
Date:	Thu, 16 Nov 2006 22:48:20 +0100
From:	"Miguel Ojeda" <maxextreme@...il.com>
To:	"James Simmons" <jsimmons@...radead.org>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Linux Fbdev development list" 
	<linux-fbdev-devel@...ts.sourceforge.net>,
	"Luming Yu" <Luming.yu@...el.com>,
	"Andrew Zabolotny" <zap@...elink.ru>, linux-acpi@...r.kernel.org
Subject: Re: ACPI output/lcd/auxdisplay mess

On 11/16/06, James Simmons <jsimmons@...radead.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists