Thread (1 message) 1 message, 1 author, 2014-02-13

Re: Fixing the kernels backlight API

From: Hans de Goede <hidden>
Date: 2014-02-13 19:43:10
Also in: dri-devel

Hi,

On 02/13/2014 06:19 PM, Matthew Garrett wrote:
On Thu, Feb 13, 2014 at 02:41:53PM +0100, Hans de Goede wrote:
quoted
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.
Right, but as Dave Airlie pointed out that means putting links between
two completely unrelated subsystems, causing locking and module load
ordering problems.

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.

This sounds like a reasonable and workable plan to me, but I must admit
I'm very naive when it comes to backlight stuff.

Regards,

Hans
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help