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

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

Hi,

On 07/16/2014 01:50 PM, Julian Wollrath wrote:
> Am Wed, 16 Jul 2014 10:35:33 +0200
> schrieb 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 ?
> Yes, of course that would be an acceptable solution for me and yes, I
> would be willing to test such a patch.

Ok, great. I've putten this (pretty high) on my todo list, I'll let you
know when I've something ready to test.

Regards,

Hans