Re: Fixing the kernels backlight API

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 02/12/2014 11:26 PM, David Herrmann wrote:
> Hi
> 
> On Wed, Feb 12, 2014 at 9:43 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
>> On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
>>>>
>>>> The biggest remaining stumbling block is the backlight API, because opening the
>>>> sysfs files requires root rights. I'll very likely write a little helper for this
>>>> for now, but in the long run it would be good to have a better solution.
>>>>
>>>> While discussion this in the graphics devroom at Fosdem, the general consensus
>>>> seemed to be that the current backlight API is in need of an overhaul anyways.
>>>>
>>>> There are several issues with the current API:
>>>> -there is no reliable way to determine the relation between a backlight
>>>>  control in sysfs and the display it controls the backlight off
>>>> -on many laptops we end up with multiple providers of backlight control
>>>>  all battling over control of the same backlight controller through various
>>>>  firmware interfaces
>>>> -and there is no way to do acl management on it because of sysfs usage
>>>>
>>>> At Fosdem it was suggested to "simply" make the backlight a property of
>>>> the connector in drm/kms and let users control it that way. From an acl pov
>>>> this makes a ton of sense, if a user controls the other display-panel settings,
>>>> then he should be able to control the backlight too.
>>>>
>>>> This also nicely solves the issue of userspace having to figure out which backlight
>>>> control to use for a certain output.
>>>>
>>>> Last this makes it the kernels responsibility to figure out which firmware interface
>>>> (if any) to use and tie that to the connector, rather then just exporting all of
>>>> them, including conflicting ones, and just hoping that userspace will figure things out.
>>>>
>>>> Note that wrt the last point, the kernel is the one which should have all the hardware
>>>> knowledge to do this properly, after all hardware abstraction is one of the tasks of
>>>> the kernel.
>>>>
>>>> I realize moving this more into the kernel, and tying things into drm is in no means
>>>> easy, but it is about time we clean up this mess.
>>>>
>>>> Note that although I'm kicking of this discussion, my focus within the graphics team is
>>>> mostly on input devices, so I'm hoping that someone else will pick things up once we've
>>>> a better idea of how we would like to solve this.
>>>>
>>>
>>> I hate to respond with yeah no, but yeah no,
>>>
>>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
>>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
>>>
>>> read down that until you see me and tagr talking, read it a few times,
>>> and the follow on chat with dvdhrm.
>>>
>>> The biggest problem with leaving the kernel to pick the correct one,
>>> is the kernel simply never knows which is the
>>> correct one,
>>
>> That could be solved by still allowing userspace to change the
>> connection between the property and the actual backlight device.
>>
>> With the prop approach + atomic modeset you could also do some
>> slightly fancier things like changing the backlight at the same
>> time as doing a modeset or just adjusting some other display
>> related properties.
> 
> The "attach" stuff actually sounds doable, but who decides which one
> to attach? You still need some user-space script during device-plug
> for that.
> But to be honest, the simplest way would be a "backlightd"
> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
> brightness-value, which the daemon looks up in /sys and sets.. This
> has the advantage that we can do any fancy matching in user-space. We
> can provide quirks (maybe even via udev-hwdb) and other helpers for
> weird setups.

This sounds like a good idea, note that at-least gnome already has
something similar in the form of the (one-shot, not daemon)
gsd-backlight-helper which also has some code to try and figure out
what is the right backlight class device to use.

Interestingly enough the xf86-video-intel driver does this on its own
using somewhat more complex logic to find the right backlight class
device to use, and then exporting this as a property on the connector
in Xrandr.

So a first rough idea of how this would work / a plan would be:

1) We have a bus-activated backlightd running as root

2) This can be asked for backlight properties on a certain drm/kms
connector

3) If there actually is a backlight for the connector, it can also be
used to change the backlight brightness

4) The xserver will get some helper functions which drivers can call
to create a backlight property on xrandr connectors

5) In the long run gsd-backlight-helper and the xf86-video-intel
backlight code can be removed

Note there also is a step:

0) Get xf86-video-intel backlight code to work without root in some
way for now


Regards,

Hans