On Wed, Jan 06, 2010 at 02:04:48PM -0500, Adam Jackson wrote: > 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.
Even with DDC/CI, it ought to be a backlight device so existing software works with it... > 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. This is fixable. We just need to set the parent member to the appropriate output. The ACPI problem was that we don't have a good way of binding ACPI outputs to card outputs, which isn't an issue here. > 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 what. We just need to populate things appropriately. When the DRM layer is handling things, there shouldn't be any ambiguity. -- Matthew Garrett | [email protected] _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
