Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems

[Yves-Alexis Perez <corsac@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]

On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote:
> > On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> > > Right, the kernel has special-casing to hook the backlight keys up to 
> > > the ACPI backlight control. This is an awful thing, because there's no 
> > > way to detect this case other than parsing a single driver-specific 
> > > module parameter.
> > 
> > I'm not sure what that means. To detect what case exactly? That the
> > brightness is handled by video.ko?
> 
> That the kernel will automatically handle backlight key presses.

Ok, so for detection by userspace? hal managed to do that just fine, it
seems that upower doesn't, for some reason.

> The behaviour is already inconsistent. If you have an ACPI backlight 
> interface, hitting the keys makes your brightness change without any 
> userspace help. If you don't, it doesn't.

At least on the same (class of) hardware it always behaves the same.
> 
> > And in the end, the user just want the brightness keys to correctly
> > handle the brightness, full stop. Having multiple brightness daemons
> > using different policies on different hardware is a nightmare for the
> > end user, imho. From a user point of view, having it handled all in the
> > kernel works really pretty fine and is completely transparent (I have to
> > admit that from that point of view, it was even better when it was
> > handled by the EC but those times seem long gone).
> 
> I agree, we should standardise the behaviour. And the only way we can 
> standardise the behaviour is to leave it up to userspace.
> 
It's pretty clear we disagree on this and that my opinion won't really
matter here. But letting userspace handle that just means broken
functionality for those who have the chance (apparently) to have an ACPI
backlight interface.

Regards,
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]