linux-kernel - Re: [PATCH 2/2] platform/x86: panasonic-laptop: allow to use all hotkeys

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]

Date:   Fri, 17 Jun 2022 15:51:55 +0800
From:   Kenneth Chan <kenneth.t.chan@...il.com>
To:     Hans de Goede <hdegoede@...hat.com>,
        Stefan Seyfried <stefan.seyfried@...glemail.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Stefan Seyfried <seife+kernel@...systems.com>
Subject: Re: [PATCH 2/2] platform/x86: panasonic-laptop: allow to use all hotkeys

On Thu, 16 Jun 2022 at 03:28, Hans de Goede <hdegoede@...hat.com> wrote:
>
> Kenneth, can you check with e.g. evemu-record or evtest
> where the double events are coming from ?  Obviously one of
> the events is coming from the panasonic-laptop driver, but
> where is the other event coming from. Is it coming from the
> atkbd driver; or ... ?   Maybe from the acpi-video driver
> for the brightness keys ?
>

Here's the evtest results:

acpi-video driver generates KEY_BRIGHTNESSDOWN, KEY_BRIGHTNESSUP
atkbd generates KEY_MUTE, KEY_VOLUMEUP, KEY_VOLUMEDOWN

Hotkey_input=Y (i.e. before patch ed83c9171829)
panasonic-laptop driver generates all keys, i.e. KEY_SLEEP,
KEY_BATTERY, KEY_SUSPEND plus all the above keys

hotkey_input=N
panasonic-laptop driver generates KEY_SLEEP, KEY_BATTERY and KEY_SUSPEND

So the duplicated brightness and volume key events come from the atkbd
and acpi-video drivers on my CF-W5. I haven't looked at the other
platform drivers. I'm wondering if they honour atkbd and acpi-driver
events in a case like this, or just report everything.

Attached is the dmidecode of my CF-W5, just to be verbose.

> Hence the module parameter so that the two known users of this module (Kenneth and me) can adjust this to their needs.
>
> Now about the DMI match: I can do that.
> But let's face it: the panasonic laptops are pretty rare in the wild, so even if I'm "whitelisting" the CF-51, then probably other models will need the same treatment and we have no real way of finding out which ones, unless people complain.
> So even if I add the DMI match (which is a good idea anyhow because then "my" model will work out of the box, while right now I need to add a module parameter or switch it on later), I'd still vote for having a possibility for overriding the DMI results.

In an ideal world, more panasonic-laptop users will send us their
DSDT. I think the most uptodate model has a MAT0035 device_id (it
increments for each generation) while our driver is at the very
outdated MAT0021. But before it happens, I agree with Stefan on that
point.

-- 
Kenneth

Download attachment "cfw5-4.dmidecode" of type "application/octet-stream" (10989 bytes)