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]

Message-ID: <20130625205430.GA2438@srcf.ucam.org>
Date:	Tue, 25 Jun 2013 21:54:30 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Yves-Alexis Perez <corsac@...ian.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 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.

> > Could this functionality be duplicated across other backlight drivers? 
> > Not easily. The ACPI driver receives keypresses and performs backlight 
> > control. The i915 driver doesn't receive keypresses. We could easily tie 
> > certain keycodes into backlight events, but which backlight should they 
> > control? You're really starting to get into the kind of complex policy 
> > decision that's best left to userspace, which is where it should have 
> > been to begin with.
> > 
> Well, I get the reasoning, but I'm not sure I agree. That means
> userspace behavior is inconsistent depending on who does it
> (gnome-power-manager, gnome-setting-daemon, whatever), and it usually
> means there's nothing handling the brightness before those are running,
> not to mention people not running them because they don't run a full
> blown desktop environment (until someone starts thinking it's a good
> idea to handle brightness in systemd).

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.

> 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.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/