On Wed, 2014-09-10 at 17:54 +0200, David Herrmann wrote:
- User-space currently has a hard-time figuring out which backlight device to use, and which backlight device belongs to which display. So far, most systems only provide backlight-devices for internal displays, so figuring out the connection is easy, but that might change with more capable external connectors.
The parent device of the backlight will be the correct display, if the kernel has a meaningful way to determine that. We could do a better job in the ACPI code than we currently do, but (unfortunately) that requires us to know the ACPI IDs that each GPU vendor uses.
If multiple backlights are available, the easiest solution is to simply write to all of them and hope at least one of them works. This obviously fails if the devices interact badly, so it's not really a solution.
There's a pretty well-defined process for that, although it sucks - if it's an LVDS or eDP display and there's a backlight of type "firmware", use it. If there's no "firmware" backlight, but there is a "platform" one, use that. Otherwise look for a "native" backlight that has the output as a parent. libbacklight does all of this for you.
- User-space needs root privileges to write to sysfs. There are no char-devs that can be used to control access-management to the backlight API, so /sys is the only interface available. So far, udev policy has been "/sys is read-only for non-root" and it's not going to change. char-devs are *THE* standard way to provide non-root user-space APIs, so use them!
Yeah, this is a problem.
This series tries to solve this problem with a much simpler approach: Instead of moving backlights into DRM, we simply link DRM properties to a backlight device. That is, the kernel manages a link between a connector and a backlight device (or n backlight devices) which can be modified by udev in case the kernel got it wrong (we don't want huge board-fixup-tables in the kernel). User-space can now use the simpl DRM API to manage backlights, and the kernel does not need any special driver code to make it work.
This doesn't really simplify userspace significantly - something's still going to have to make the same policy decision as we do right now, and the kernel isn't really the right place to do that. It does have the benefit of allowing that policy decision to be made at boot time and then allow that to be consumed by all later userspace, so there is *some* benefit, but I think the "make unprivileged userspace possible" argument is much more compelling.