linux-kernel - Re: Backlight control only in the kernel?

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: <1375871766.10292.7.camel@x230.lan>
Date:	Wed, 7 Aug 2013 10:36:08 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"seth.forshee@...onical.com" <seth.forshee@...onical.com>,
	"joeyli.kernel@...il.com" <joeyli.kernel@...il.com>,
	"daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
	"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lenb@...nel.org" <lenb@...nel.org>, "rjw@...k.pl" <rjw@...k.pl>,
	Aaron Lu <aaron.lu@...el.com>
Subject: Re: Backlight control only in the kernel?

On Wed, 2013-08-07 at 09:44 +0200, Borislav Petkov wrote:

> Background is that on my x230, I needed to connect the
> Fn-Fx backlight hotkey presses to a script to write to
> /sys/class/backlight/intel_backlight/brightness because Fluxbox doesn't
> do that (and maybe doesn't have to).
> 
> So, without presuming any ACPI or backlight knowledge, can we make the
> backlight control work only in the kernel by connecting the hotkey
> presses to some backlight controlling interface which backlight-capable
> devices implement so that it works regardless of userspace environment?
> Even if the machine is not running X?

Not really. The ACPI driver is able to do this because the events and
the backlight are associated with the same device. We could potentially
make something work with GPU backlight drivers since their PCI device
should also be associated with the backlight device, but things get
complicated quickly - once ddcci support is hooked up you'll also have
kernel backlight devices for some external monitors, and now you need to
make a policy decision about which display should be controlled in
response to the keypress. One reasonable choice would be whichever
display contains the currently focused window, which is obviously out of
scope for the kernel.

So if we're going to do this then we need a generalised mechanism
in-kernel for connecting input devices to backlight devices, and we need
a mechanism for disabling it when userspace knows better. This sounds
like a lot of work for something that should really just be handled by
userspace already.

-- 
Matthew Garrett | mjg59@...f.ucam.org