Message-ID: <20190318120032.nynbshqudmlslxxz@pali>
Date:   Mon, 18 Mar 2019 13:00:32 +0100
From:   Pali Rohár <pali.rohar@...il.com>
To:     Renato Soma <renatoys08@...il.com>
Cc:     platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mario Limonciello <mario.limonciello@...l.com>,
        mistave@...ntermail.com
Subject: Re: [PATCH 0/1] platform/x86: dell-wmi: Uncomment events that were

Hello!

On Sunday 17 March 2019 15:30:49 Renato Soma wrote:
> Hello,
> 
> On Sat, Mar 16, 2019 at 10:17:56AM +0100, Pali Rohár wrote:
> > 
> > Looks like that those keys are not as obvious as you wrote. Look at my
> > email with some investigation about Dell Audio With Preset Switch key:
> > https://www.spinics.net/lists/platform-driver-x86/msg15593.html
> > 
> > Also there is another user who wrote about 0xe02c key generated by
> > Inspirion 7520: https://ubuntuforum-br.org/index.php?topic=105434.0
> > 
> > You can a testing machine 5420, can you prove that behavior described in
> > my previous email match also your machine?
> > 
> 
> Thanks for the feedback, I was unaware of this issue.
> I've performed some tests in my machine and this is what I've found so far:
> 
> =====================================================================
> 
> ----------------------------------------
> Left WMI key: Windows Mobility Center
> Press:    'x'
> Hold:     -
> Release:  -
> 
> In my machine (Inspiron 5420), whenever I press this key, the key
> outputs the character "x". I've seen nothing on dmesg even if I
> keep this key pressed for longer amounts of time. I'm still trying
> to understand why this is hapenning.

This is strange. Is not also some Alt/Meta/Ctrl or other modifier sent
too? Because Meta+X could be some windows shortcut...

> 
> ----------------------------------------
> Middle WMI key: Dell Audio With Preset Switch
> Press:    Key with type 0x0000 and code 0xe02a pressed
> Hold:     -
> Release:  Key with type 0x0000 and code 0xe02b pressed
> 
> Differently from what you saw on a Inspiron 7520, I could not
> reproduce the behavior that you reported on the first link above.
> In my case, when I press the key, the code 0xe02a is shown at dmesg
> only once. Also, even though I keep it pressed for longer than ~30
> seconds or so, I could not see the entry 0xe02c apper. More on that
> behavior later on. When releasing the key, I can see the code 0xe02b
> show up at dmesg.
> 
> ----------------------------------------
> Right WMI key: Dell Instant Launch
> Press:    -
> Hold:     -
> Release:  -
> 
> This key is with a really weird behavior on my machine.
> When testing, I would normally press and relase so that the following
> messages would pop-up:
> 
> [ 2830.499420] atkbd serio0: Unknown key pressed (translated set 2,
> code 0x60 on isa0060/serio0).
> [ 2830.499422] atkbd serio0: Use 'setkeycodes 60 <keycode>'
> to make it known.

This means that you have not configured atkbd keycodes yet. Run
setkeycodecs and assign some keycode for that scancode 60. After that
kernel atkbd (PS/2 keyboard) starts sending events to userspace.

> But what I realized was that, if I kept this button pressed for about
> ~3 seconds or so (like when your experiment in the link above), dmesg

That experiment is not my, Mistave did it. Now I'm CCing.

> would not ouput anything untill those ~3 seconds elapsed. When they
> did, then dmesg log would have the following entries:
> 
> [ 3058.494003] atkbd serio0: Unknown key pressed (translated set 2,
> code 0x60 on isa0060/serio0).
> [ 3058.494008] atkbd serio0: Use 'setkeycodes 60 <keycode>'
> to make it known.
> [ 3058.501494] dell_wmi: Unknown key with type 0x0000 and code
> 0xe028 pressed
> 
> The last message being the weirdest, It would seem that only after
> about 3 seconds or so, the driver is being notified of it.

There are two ways how Dell firmware can inform operating system that
key was pressed. Notebook keyboard is connected to motherboard via
classic PS/2 port (of PS/2 port is emulated for OS). So operating system
sees PS/2 keyboard and key pressed are received by PS/2 atkbd driver.
For some (unknown/strange?) reasons firmware send some keys not via PS/2
keyboard port, but via ACPI interface, hence needs for dell_wmi driver
which handle them.

So some keypress events come via PS/2, some via ACPI-WMI. Linux kernel
then send all keypress events to userspace.

When debugging problems with hot keys, you always need to look at all
possible sources...

> =====================================================================
> 
> Anyway, It's clear now that this patch trully makes no sense since the
> hardwares (Inspiron 7520 x Inspiron 5420) are behaving somewhat
> differently on these keys.
> 
> Either way, It seems that at both of them, there are three behaviors
> that are strange. I'm still trying to learn kernel development (I'm a
> newbie) so could you please point out whether this is worth it to
> investigate, or if should I leave this as is?

dell-wmi.c is a driver for receiving APCI-WMI events; atkbd.c is a PS/2
keyboard driver.

In dell-wmi.c is a function dell_wmi_events_set_enabled which is needed
to call on some Dell machines to start receiving those ACPI-WMI events.
You can try to call it for your laptop, maybe it is needed too.
Currently it is called only for two laptop models, see table
dell_wmi_smbios_list.

> In the meantime, I'll try to find out why the first button is outputting
> an "x" character on my machine.

Check that you caught all keypresses. X11 tools just print keys known to
X server, not all which are supported by Linux kernel.

You can use e.g. input-events utility. And also check all input devices,
as wrote some keys are send via PS/2 keyboard input device, some via
ACPI-WMI input device.

> Thanks!
> Renato

Also I added Mario from Dell to list of receivers, maybe he could have
more details about this problem...

-- 
Pali Rohár
pali.rohar@...il.com

Powered by blists - more mailing lists