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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Jun 2013 23:10:11 +0200
From:	Yves-Alexis Perez <corsac@...ian.org>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	linux-acpi@...r.kernel.org, seth.forshee@...onical.com,
	joeyli.kernel@...il.com, daniel.vetter@...ll.ch,
	intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org, lenb@...nel.org, rjw@...k.pl,
	Henrique de Moraes Holschuh <hmh@...ian.org>
Subject: Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems

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

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)