linux-kernel - Re: [PATCH RFC 0/4] Linking DRM Connectors to Backlight Devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1410381657.4117.3.camel@nebula.com>
Date:	Wed, 10 Sep 2014 20:40:57 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	"dh.herrmann@...il.com" <dh.herrmann@...il.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
	"jg1.han@...sung.com" <jg1.han@...sung.com>,
	"lee.jones@...aro.org" <lee.jones@...aro.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"cooloney@...il.com" <cooloney@...il.com>,
	"airlied@...il.com" <airlied@...il.com>,
	"ajax@...hat.com" <ajax@...hat.com>
Subject: Re: [PATCH RFC 0/4] Linking DRM Connectors to Backlight Devices

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.

-- 
Matthew Garrett <matthew.garrett@...ula.com>