Hi, On 02/12/2014 09:14 PM, 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. I think I'm going to save myself some time and just believe you, esp. since you ... > > 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. Also bring up Matthew Garrett, who seems to have a knack for working on things which involve inflicting a certain amount of pain onto the developer working on them. I still believe we need to do better, but maybe that better needs to be done in userspace rather then in the kernel. More about that further down in this thread. Regards, Hans _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
