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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 16 Jun 2022 at 03:28, Hans de Goede <hdegoede@xxxxxxxxxx> 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

Attachment: cfw5-4.dmidecode
Description: Binary data


[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux