Fixing the kernels backlight API

[Ville Syrjälä]

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=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,

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.

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

This would still be an issue though.

I like the idea of the property, but I'm not volunteering to do any
of the work.

> 
> 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
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC