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
| ||
|
Date: Mon, 4 Jun 2018 07:51:43 -0600 From: Daniel Drake <drake@...lessm.com> To: Hans de Goede <hdegoede@...hat.com> Cc: Chris Chiu <chiu@...lessm.com>, Corentin Chary <corentin.chary@...il.com>, Darren Hart <dvhart@...radead.org>, Andy Shevchenko <andy.shevchenko@...il.com>, Linux Kernel <linux-kernel@...r.kernel.org>, Platform Driver <platform-driver-x86@...r.kernel.org>, acpi4asus-user <acpi4asus-user@...ts.sourceforge.net>, Linux Upstreaming Team <linux@...lessm.com>, Bastien Nocera <hadess@...ess.net>, Benjamin Berg <benjamin@...solutions.net> Subject: Re: [PATCH 1/2] platform/x86: asus-wmi: Call new led hw_changed API on kbd brightness change On Mon, Jun 4, 2018 at 7:22 AM, Hans de Goede <hdegoede@...hat.com> wrote: > Is this really a case of the hardware itself processing the > keypress and then changing the brightness *itself* ? > > From the "[PATCH 2/2] platform/x86: asus-wmi: Add keyboard backlight > toggle support" patch I get the impression that the driver is > modifying the brightness from within the kernel rather then the > keyboard controller are ACPI embeddec-controller doing it itself. > > If that is the case then the right fix is for the driver to stop > mucking with the brighness itself, it should simply report the > right keyboard events and export a led interface and then userspace > will do the right thing (and be able to offer flexible policies > to the user). Before this modification, the driver reports the brightness keypresses to userspace and then userspace can respond by changing the brightness level, as you describe. You are right in that the hardware doesn't change the brightness directly itself, which is the normal usage of LED_BRIGHT_HW_CHANGED. However this approach was suggested by Benjamin Berg and Bastien Nocera in the thread: Re: [PATCH v2] platform/x86: asus-wmi: Add keyboard backlight toggle support https://marc.info/?l=linux-kernel&m=152639169210655&w=2 The issue is that we need to support a new "keyboard backlight brightness cycle" key (in the patch that follows this one) which doesn't fit into any definitions of keys recognised by the kernel and likewise there's no userspace code to handle it. If preferred we could leave the standard brightness keys behaving as they are (input events) and make the new special key type directly handled by the kernel? Daniel
Powered by blists - more mailing lists