Fixing the kernels backlight API

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:

(quoted diff) +0 -3

-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.

Quoted 32 lines

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:

(quoted diff) +0 -3

-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.

Quoted 7 lines

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=2014-02-04
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-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,

and you also have to deal with a load of problems like runtime module deps between very misc modules
or using some kind of notifier mechanism that will turn into a locking nightmare.

I don't mean to dissuade you from trying to "fix" this, but actually getting a solution upstream is going to require a lot of messing around.

Talk to Matthew Garrett, if you haven't talked to him, then you haven't talked to anyone who understands backlights.

Dave.
_______________________________________________
dri-devel mailing list [email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 45 lines · Dave Airlie

Quoted 32 lines

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:

(quoted diff) +0 -3

-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.

Quoted 7 lines

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=2014-02-04
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-05

Quoted 6 lines

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.

Quoted 9 lines · David Herrmann

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.

What would be done with Samsung monitors (like an old SyncMaster 770P) that have a DVI connection, no physical buttons and have to be controlled via DDC-CI? Currently, ddccontrol works (via /dev/i2c-*), but only from root. I would like this use case to be covered in such a way that it could work both in Xorg and in Wayland, and, if possible, without races related to i2c usage from the kernel and from userspace.

Hi

Quoted 53 lines · Ville Syrjälä

Quoted 45 lines · Dave Airlie

Quoted 32 lines

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:

(quoted diff) +0 -3

-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.

Quoted 7 lines

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=2014-02-04
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-05

Quoted 6 lines

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,

Quoted 7 lines

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.

Quoted 32 lines

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:

(quoted diff) +0 -3

-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.

Quoted 7 lines

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=2014-02-04
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-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, and you also have to deal with a load of problems like runtime module deps between very misc modules
or using some kind of notifier mechanism that will turn into a locking nightmare.

I don't mean to dissuade you from trying to "fix" this, but actually getting a solution upstream is going to require a lot of messing around.

Talk to Matthew Garrett, if you haven't talked to him, then you haven't talked to anyone who understands backlights.

I still believe we need to do better, but maybe that better needs to be done in userspace rather then in the kernel.

Quoted 2 lines · Hans de Goede

I still believe we need to do better, but maybe that better needs to be done in userspace rather then in the kernel.

One option is to put it on the connector but provide some mechanism for userspace to define the relationship between platform/firmware interfaces and connectors. We ought to be able to tie connectors into the ACPI namespace and do a better job than we currently do with the association between backlight and connector. The bigger problem is figuring out how platform interfaces tie into things, and that's where heuristics are probably going to be involved.

I can understand where Dave is coming from, from a kernel pov, so this might really be easier to just solve in userspace. I don't know if you've seen my very rough sketch of how this could work in userspace in my other mail. The idea would be to still make this show up on a specific connector, but only at the xrandr level, not at the drm level, and have the xserver talk to some kind of backlightd for this. The backlightd API should of cource be generic enough that it can be used in wayland too.

Quoted 7 lines · Hans de Goede

I can understand where Dave is coming from, from a kernel pov, so this might really be easier to just solve in userspace. I don't know if you've seen my very rough sketch of how this could work in userspace in my other mail. The idea would be to still make this show up on a specific connector, but only at the xrandr level, not at the drm level, and have the xserver talk to some kind of backlightd for this. The backlightd API should of cource be generic enough that it can be used in wayland too.

Sure. You should probably take a look at libbacklight, which already has some amount of support for appropriate heuristics.