| 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
| ||
|
Message-ID: <20120113224211.GB29022@srcf.ucam.org> Date: Fri, 13 Jan 2012 22:42:11 +0000 From: Matthew Garrett <mjg@...hat.com> To: Corentin Chary <corentin.chary@...il.com> Cc: platform-driver-x86@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, linux-input@...r.kernel.org Subject: Re: Handling special keys in platform drivers On Mon, Jan 09, 2012 at 07:24:14AM +0100, Corentin Chary wrote: > The real problem is that for keyboard backlight to work, it needs DE > cooperation, and only gnome as implemented that right now, and other > (except KDE) will probably neither have the resources to handle all > the possible keys correctly. And of course, who should handle the keys > when there is no DE running at all ? The problem with handling this in kernel is that there isn't an obviously correct policy. ACPI will typically only expose 16 or so backlight levels so the behaviour is easy enough, but (depending on how the hardware is wired up) i915 may expose around 20,000. Further, one machine may expose different backlight controls for different displays, and in that situation you need to know which one the input event is expected to correspond to. Doing backlight control properly involves a lot of policy work, and I'm reluctant to argue that that ought to be in the kernel. -- 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/
Powered by blists - more mailing lists