linux-kernel - Re: [PATCH 1/2] platform/x86: asus-wmi: Call new led hw

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: <CAD8Lp45FmOMK3B537sKfnC3STtxwspNdoRVKTyaoDnsJ3EMEtg@mail.gmail.com>
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