Re: [Regression]: Changing brightness does not work with v3.16-rc4

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

Hi,

On 07/16/2014 10:13 AM, Hans de Goede wrote:

<snip>

> I realize that this does not fix Julian's problem. As I see it there are
> 2 separate problems here:
> 
> 1) backlight control issues on Windows 8 laptops, this is what we are
> trying to solve with video.use_native_backlight=1 (and without using
> any acpi_osi override)
> 
> 2) Some component in the stack needs to responds to backlight key-presses
> and actually use the backlight control to change the backlight setting,
> normally this is done by gnome / kde / unity / xfce, but what about users
> not running those? For some of those users brightness_switch_enabled=1
> has been making things work for them, but that only works if acpi-video
> controls the backlight, which it does not do everywhere, and which we
> want to get away from for Windows 8 laptops since it is just too broken
> there.
> 
> Note that 2. is not limited to Windows 8 laptops / acpi-video in any
> way, we've 23 non acpi-video backlight drivers under drivers/platform/x86/
> alone + the native gpu backlight drivers. So what we really need is a
> solution for any laptop not using acpi-video for backlight control and
> not running one of the big 4 desktop environments.
> 
> Note that we pretty much have the same problem for any acpi event,
> power button pressed, lid closed, etc. are all "key press" type
> events typically handles by the desktop enviroment (e.g. we don't
> automatically suspend on lid-close, we just tell userspace). And we already
> have a solution for these type of events when running a desktop environment
> which handles them, these get handled by acpid. So to me it seems that

s/handles/does not handle/  small but important typo.

> the obvious (and one and only right) way to fix this is to teach acpid
> to deal with brightness key-presses.
> 
> I'm willing to write a patch for acpid to implement this, and then
> Julian's setup should just work without needing any special kernel
> commandline options.
> 
> Julian would that be an acceptable solution for you, and would you be
> willing to test such a patch ?

Regards,

Hans