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: <20180609003303.GD111314@localhost.localdomain>
Date:   Fri, 8 Jun 2018 17:33:03 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Benjamin Berg <benjamin@...solutions.net>,
        Chris Chiu <chiu@...lessm.com>,
        Bastien Nocera <hadess@...ess.net>,
        Daniel Drake <drake@...lessm.com>,
        Corentin Chary <corentin.chary@...il.com>,
        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>
Subject: Re: [PATCH 1/2] platform/x86: asus-wmi: Call new led hw_changed API
 on kbd brightness change

On Wed, Jun 06, 2018 at 05:32:52PM +0200, Hans de Goede wrote:

> > > > > If we are adding hwdb entries anyway to control the userspace
> > > > > interpretation of the TOGGLE key, then we could also add the new CYCLE
> > > > > key and explicitly re-map it to TOGGLE. That requires slightly more
> > > > > logic in hwdb, but it does mean that we could theoretically just drop
> > > > > the workaround if we ever stop caring about Xorg.
> > > > 
> > > > Hmm, interesting proposal, I say go for it :)
> > > > 
> > > 
> > > So maybe the next stop is that I can follow Darren's suggestion to eliminate
> > > the is_kbd_led_event() and send a v2 for review?
> > 
> > I believe the best compromise we have right now is to do what Hans
> > suggested in an earlier proposal. That is implementing the two separate
> > behaviours in the kernel
> > 
> >   1) handle this in the kernel as if the hardware changed it, and
> >   2) send a new KEY_KBDILLUMCYCLE event [default].
> 
> I think you mean or, not and, depending on a module option the
> code should do either 1) or 2) not both :)
> 
> Darren, Andy could you live with a module option for this?

We are of course strongly opposed to adding module options.

I agree we can't ignore Xorg.

I agree policy in general should not be in the kernel.

I also see many of these drivers as the last mile to getting a platform
fully working. If there is a place for one-off fixes, it's in these
drivers. I'd love to refactor and use proper abstractions and all that
as the patterns make those abstractions clear - but I don't want to
delay getting something working waiting for the ideal solution.

So I have two questions I'd like to confirm before saying "OK" to a
module option.

1) Hans I think you said that doing the code conversion from TOGGLE to
UP based on the LED value and the max value was racy with userspace.
What is the failure mode here? Is it not easily recoverable? And how do
I enter it? Do I have to simultaneously modify the software brightness
control AND press the keyboard brightness control? How practical is
that? If recoverable AND hard to trigger, I think there is value in the
very simple 3 level brightness cycle being handled in the kernel.

2) Why is a module option preferable to a compile time option? It seems
to me the policy will be largely distro dependent, and the same kernel
needing to support both modes seems likely to be pretty rare.

-- 
Darren Hart
VMware Open Source Technology Center