Laptop Panel brightness control
ajax at nwnk.net
Wed Jan 6 11:04:48 PST 2010
On Wed, 2010-01-06 at 17:05 +0000, Matthew Garrett wrote:
> On Mon, Jan 04, 2010 at 01:37:00PM -0500, Adam Jackson wrote:
> > The brightness control should be internally routed in the kernel to be a
> > DRM output property, which the X server then proxies through as a RANDR
> > output property. DeviceKit doesn't get involved here, just make the
> > kernel do the right thing.
> I'd disagree with this. It ought to be exposed as a backlight class
> device, for consistency with everything else. The server may want to
> then expose it as a RANDR property.
In the glorious future, when the kernel grows DDC/CI support, we're
going to end up with a DRM output property for backlight anyway. And we
definitely want to expose it as RANDR property, because backlight level
is part of the session state for fast-user-switching.
But my major problem with exposing it as a backlight class device is the
same problem I had with trying to use /proc/acpi/video/*/*/edid: The
kernel doesn't give userspace enough information to know which backlight
is bound to which output. As with ACPI's EDID method, it's sort of
academic, since there's not many cases where it's ambiguous. If you've
only got one video card, then the ACPI EDID methods are yours; if you've
only got one backlight, then the backlight is yours. But I have no
trouble imagining (eg) a kiosk machine with two LVDS panels, and, then
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20100106/65c74875/attachment.pgp
More information about the xorg-devel