On Mon, Jun 4, 2018 at 7:22 AM, Hans de Goede <hdegoede@xxxxxxxxxx> 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
