Bug 213031 - MEDION notebook internal keyboard not recognized / not working correctly
Summary: MEDION notebook internal keyboard not recognized / not working correctly
Status: NEW
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: acpi_config-interrupts
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-11 19:37 UTC by Manuel Krause
Modified: 2021-06-10 11:39 UTC (History)
4 users (show)

See Also:
Kernel Version: 5.11.+
Tree: Mainline
Regression: No


Attachments
i8042 kernel parameters testing results (1.91 KB, text/plain)
2021-05-25 19:49 UTC, Manuel Krause
Details
i8042 kernel parameters testing results (2.17 KB, text/plain)
2021-05-28 19:20 UTC, Manuel Krause
Details
dmesg log of kbd testing @ #11 (85.09 KB, text/plain)
2021-05-28 19:43 UTC, Manuel Krause
Details
Working patch to enable internal keyboards on MEDION M15T based notebooks (730 bytes, patch)
2021-06-01 20:14 UTC, Manuel Krause
Details | Diff
Function-key-test MK (2.95 KB, text/plain)
2021-06-03 23:48 UTC, Manuel Krause
Details
2nd variant of working patch to enable internal keyboard on MEDION M15T notebooks (729 bytes, patch)
2021-06-04 19:01 UTC, Manuel Krause
Details | Diff
a new testing patch (1.77 KB, application/mbox)
2021-06-06 14:19 UTC, Hui Wang
Details
final version patch (2.92 KB, application/mbox)
2021-06-10 11:39 UTC, Hui Wang
Details

Description Manuel Krause 2021-05-11 19:37:50 UTC
Hi kernel people,

I really hope that I'm right on here to ask for your help with my new notebook's keyboard:
From dmesg: "DMI: MEDION P15651/M15T, BIOS 209 11/24/2020". OS: openSUSE Tumbleweed, kernel: custom vanilla 5.12.2 with a slightly reduced .config from openSUSE default.

Problem: With Linux booted, the internal keyboard doesn't work correctly. It fully works in Windows 10 and in the GRUB2 menu.
The only keyboard keys working under Linux are three function keys for the display-backlight (-/+/on&off == Fn+F5/F6/F7) and keyboard-backlight (Fn+SPACE).
The internal touchpad works, but this is driven over I2C, as it looks like.
An external keyboard (in my case a PS/2 via USB-adapter) works fine.
Under Win 10 the keyboard looks like to be driven by the standard driver: I8042PRT.SYS [5] 

The manufacturer and the vendor (MEDION, ALDI) are stuck to Windows-only, no constructive support available, not even from their user community support forum. [1] 

There are some very few reports on the web, telling me that I'm not the only one with this issue and we're getting more over time [2...3]. Source list at the bottom. I've tested all of the basic suggested debugging proposals without effort.

Affected Notebooks as of 2021-05-11:
MEDION P15651 (model: M15T)    [1], [2]
MEDION S15450 (model: M15T)    [1], [2]
MEDION S15449 (model: M15T)    [3], [2]
MEDION S154495 (typo?)         [2]
Seems like all have the TigerLake chipset and the same CPU, Intel 11th Gen Intel Core i5-1135G7, in common.


Stumbling over the many kernel options for i8042 I lost any path for further testing for a useful targeted debugging. Although, I've tried some random patterns without effort, so far.

Maybe someone of you can tell me what path would be useful for debugging this odd keyboard + controller and / or whom to contact.

I'd provide any info you need upon your request, I just have lost any sense about what you might find useful, atm.
(Please move this posting to a more appropriate thread if beneficial !)

Best regards and TIA,
Manuel

Sources of information:
 [1] https://community.medion.com/t5/Notebook-Netbook/Hilfeanfrage-MEDION-P1561-Notebook-Tatstatur-keyboard-Linux/td-p/110891    (german)
 [2] https://forums.linuxmint.com/viewtopic.php?f=49&t=339480
 [3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1909814
 [4] https://forums.linuxmint.com/viewtopic.php?t=341013    (espagnol)
[5] https://forums.linuxmint.com/viewtopic.php?p=1995078&sid=58ce5aca7c82ae431d721deb9e6c47b6#p1995078

Many thanks go to the participants for their provided information !
Comment 1 George Dited 2021-05-14 22:03:04 UTC
Hi everyone,

i confirm everything said by Manuel Krause and i would add that, surprisingly, the the keyboard works well in the FreeBSD 12 Installer but i coulnd't install the system becouse it didn't detect the wifi chip.

So the problem is only related to Linux.

I hope this information will be useful.

George
Comment 2 Hui Wang 2021-05-25 03:08:59 UTC
Please check if there is a /sys/devices/platform/i8042 folder?

If yes, then run 'ls /sys/bus/serio/devices/', let us see how many devices there.
Comment 3 Manuel Krause 2021-05-25 19:49:56 UTC
Created attachment 296979 [details]
i8042 kernel parameters testing results

During the past weeks I've done some testing with the i8042 and atkbd kernel parameter options.
I hope the .txt "chart" is readable for you.
Comment 4 Manuel Krause 2021-05-25 20:03:16 UTC
(In reply to Hui Wang from comment #2)
> Please check if there is a /sys/devices/platform/i8042 folder?
> 
> If yes, then run 'ls /sys/bus/serio/devices/', let us see how many devices
> there.

The folder /sys/devices/platform/i8042 does exist. And in /sys/bus/serio/devices/ there is one item "serio0" which is a link to "../../../devices/platform/i8042/serio0".
This also corresponds to the enumeration shown in dmesg early:
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0

I've used "xev", but as expectable, when kernel doesn't like the keyboard, only the above mentioned keyboard keys do produce a response.

Thank you very much for your highly appreciated support !

Best regards,
Manuel
Comment 5 Hui Wang 2021-05-26 00:45:52 UTC
(In reply to Manuel Krause from comment #4)
> (In reply to Hui Wang from comment #2)
> > Please check if there is a /sys/devices/platform/i8042 folder?
> > 
> > If yes, then run 'ls /sys/bus/serio/devices/', let us see how many devices
> > there.
> 
> The folder /sys/devices/platform/i8042 does exist. And in
> /sys/bus/serio/devices/ there is one item "serio0" which is a link to
> "../../../devices/platform/i8042/serio0".
> This also corresponds to the enumeration shown in dmesg early:
> input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input0
> 
I checked all dmesg in the https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1909814, there is no "input: AT Translated Set 2 keyboard as...", how did you make that happen?

If you could make the "input: AT Translated Set 2 keyboard as..." show in the dmesg, that means the keyboard is found and registered. Then could you try 'sudo showkey' and 'sudo showkey -s' and press some keys, this will print keycode or scancode of the key you pressed.

thx.
Comment 6 Manuel Krause 2021-05-26 22:06:32 UTC
(In reply to Hui Wang from comment #5)
> I checked all dmesg in the
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1909814, there is no
> "input: AT Translated Set 2 keyboard as...", how did you make that happen?
> 
> If you could make the "input: AT Translated Set 2 keyboard as..." show in
> the dmesg, that means the keyboard is found and registered. Then could you
> try 'sudo showkey' and 'sudo showkey -s' and press some keys, this will
> print keycode or scancode of the key you pressed.
> 
> thx.

That's a point. I haven't noticed it. 
I've now searched several dmesg logs, and "input: AT Translated Set 2 keyboard as..." looks like to have appeared only with my latest keyboard-test parameter change in kernel command line to: i8042.dumbkbd=1 i8042.noaux=1 i8042.kbdreset=1

Unfortunately, your suggested use of "showkey" only gives poor feedback:
Only the keys for display brightness (Fn+F5/F6) show something:

showkey:
keycode 224 press
keycode 224 release
keycode 225 press
keycode 225 release

showkey -s:
0xe0 0x4c 0xe0 0xcc 
0xe0 0x54 0xe0 0xd4

TIA
Comment 7 Manuel Krause 2021-05-28 19:20:21 UTC
Created attachment 297029 [details]
i8042 kernel parameters testing results

Let me add the updated chart of my keyboard related testing.

From my short analysis, the parameter 'i8042.dumbkbd=1' looks like to lead to the enumeration line "input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0" in dmesg, but it doesn't lead to added functionality, as reported above.

Below I'd add a dmesg log from my last test.
Comment 8 Manuel Krause 2021-05-28 19:43:10 UTC
Created attachment 297031 [details]
dmesg log of kbd testing @ #11

Here comes a dmesg of my last test No. #11.

In here, we see little additional output of 'i8042.debug=1' and 'i8042.unmask_kbd_data=1' kernel command line parameters.
Shouldn't there be some interrupt related calls?

I've made some other finding, what hasn't occurred on my last and much older notebook: The lines 570+
[    0.422398] ACPI: IRQ 1 override to edge, high
[    0.422406] pnp 00:03: Plug and Play ACPI device, IDs PNP0303 (active)

If I got it correctly, the IRQ 1 and the ID PNP0303 correspond to the KBD port.
Would the "override to edge, high" be correct? (It's in /usr/src/linux/drivers/acpi/resource.c @line 409 in kernel 5.12.7.)

Both may be misleading traces, but I want to also add odd thoughts.
Comment 9 Hui Wang 2021-05-31 03:05:17 UTC
If you press non-function keys on the keyboard, does it trigger interrupt? (by checking "/proc/interrupts/ | grep i8042"


And you could add noapic in the bootargs to skip the irq override, that means the log in the comment 8 will not show if you add noapic:
[    0.422398] ACPI: IRQ 1 override to edge, high
[    0.422406] pnp 00:03: Plug and Play ACPI device, IDs PNP0303 (active)
Comment 10 Manuel Krause 2021-05-31 22:23:27 UTC
(In reply to Hui Wang from comment #9)
> If you press non-function keys on the keyboard, does it trigger interrupt?
> (by checking "/proc/interrupts/ | grep i8042"

'cat /proc/interrupts | grep i8042':
1:   0   0   0   0   0   0   0   0  IR-IO-APIC  1-edge   i8042
Even the function keys don't change this. :-(
(This is still with the last mentioned parameter setup #11.)

> And you could add noapic in the bootargs to skip the irq override, that
> means the log in the comment 8 will not show if you add noapic:
> [    0.422398] ACPI: IRQ 1 override to edge, high
> [    0.422406] pnp 00:03: Plug and Play ACPI device, IDs PNP0303 (active)

Please give me some time for this "noapi" testing. Maybe I therefor should change some of the parameters or leave them at default. If you have hints regarding those, please let me know!
Comment 11 Manuel Krause 2021-05-31 23:16:20 UTC
Short update:
With changed related parameters to: 
i8042.debug=1 i8042.unmask_kbd_data=1 i8042.direct=1 i8042.dumbkbd=1 i8042.kbdreset=1 atkbd.reset=1 noapic

I get the following in dmesg:
[    1.396863] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    1.396865] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    1.396954] i8042: [1] 20 -> i8042 (command)
[    1.397163] i8042: [1] 65 <- i8042 (return)
[    1.397239] i8042: [1] 20 -> i8042 (command)
[    1.397449] i8042: [1] 65 <- i8042 (return)
[    1.397489] i8042: [1] 60 -> i8042 (command)
[    1.397910] i8042: [2] 34 -> i8042 (parameter)
[    1.398770] i8042: [2] 60 -> i8042 (command)
[    1.398887] i8042: [2] 25 -> i8042 (parameter)
[    1.398907] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.398927] i8042: [3] Interrupt 1, without any data
[    1.399086] mousedev: PS/2 mouse device common for all mice
[    1.399111] input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input0

After some keys pressed:
'cat /proc/interrupts | grep i8042':
1:   1   0   0   0   0   0   0   0  XT-PIC   i8042

I'm clueless about how to go on. I'm not even sure to be searching in the right place. Is this an i8042 keyboard at all? 
I really don't want to disassemble this new machine.
Comment 12 Hui Wang 2021-06-01 01:47:39 UTC
(In reply to Manuel Krause from comment #10)
> (In reply to Hui Wang from comment #9)
> > If you press non-function keys on the keyboard, does it trigger interrupt?
> > (by checking "/proc/interrupts/ | grep i8042"
> 
> 'cat /proc/interrupts | grep i8042':
> 1:   0   0   0   0   0   0   0   0  IR-IO-APIC  1-edge   i8042
> Even the function keys don't change this. :-(
> (This is still with the last mentioned parameter setup #11.)
> 
The function key event is reported to kernel through acpi event, it triggers acpi irq instead of i8042 irq.
Comment 13 Hui Wang 2021-06-01 02:13:33 UTC
(In reply to Manuel Krause from comment #11)

> 1:   1   0   0   0   0   0   0   0  XT-PIC   i8042
> 
> I'm clueless about how to go on. I'm not even sure to be searching in the
> right place. Is this an i8042 keyboard at all? 
> I really don't want to disassemble this new machine.
Someone said the keyboard works well under windows, you could check if it is i8042 keyboard from windows, and what driver is used for it and what resource is assigned to it. For example, the driver is system32\drivers\i8042prt.sys system32\drivers\kbdclass.sys


And if you could build the kernel yourself, you could change the keyboard irq forcibly to below 4 combos (and remove noapic, remove i8042 related parameters like i8042.dumbkbd=1...):
Level High
Level Low
Edge High
Edge Low

This is an example diff to forcibly set the irq to LEVEL Low:

--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -401,10 +401,16 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
         * using extended IRQ descriptors we take the IRQ configuration
         * from _CRS directly.
         */
+       printk("wwwwwwwhhhhhhhhhhhhh gsi = %d triggering = %d polarity = %d\n",
+              gsi, triggering, polarity);
        if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
                u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
                u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
 
+               if (gsi == 1)  {
+                       trig = ACPI_LEVEL_SENSITIVE;
+                       pol = ACPI_ACTIVE_LOW;
+               }
                if (triggering != trig || polarity != pol) {
                        pr_warn("ACPI: IRQ %d override to %s, %s\n", gsi,
                                t ? "level" : "edge", p ? "low" : "high");
Comment 14 Manuel Krause 2021-06-01 18:19:19 UTC
(In reply to Hui Wang from comment #13)

There's nothing better than constructive collaboration with Linux people !

You have led to a first success. :-D  I thank you very much !!!

> Someone said the keyboard works well under windows, you could check if it is
> i8042 keyboard from windows, and what driver is used for it and what
> resource is assigned to it. For example, the driver is
> system32\drivers\i8042prt.sys system32\drivers\kbdclass.sys

Yes, toma1970 @linuxmint said it and he re-checked the related driver for me, as I haven't been brave enough to play back my windows backup. (Source: https://forums.linuxmint.com/viewtopic.php?p=2015222&sid=21339e6e4397312b231f3927bfa6d962#p2015222 )

> And if you could build the kernel yourself, you could change the keyboard
> irq forcibly to below 4 combos (and remove noapic, remove i8042 related
> parameters like i8042.dumbkbd=1...):
> Level High
> Level Low
> Edge High
> Edge Low

I've taken your column above, and my first shot "LEVEL HIGH" enabled the keyboard under Linux in tty1 and under X.

Unfortunately, the keypresses do lag for a noticeable amount of ms (also to repeating too often).

Let me check, whether one of the other combos do it better.

Would you say that having "threadirqs" in kernel command line may be counter-productive?
And, could removing the external kbd (via USB adapter) prevent the lagging?
Comment 15 Manuel Krause 2021-06-01 19:59:28 UTC
Short update:

Using "LEVEL LOW" in your patch proposal works PERFECTLY now.

No lagging, no multiple repeating, no false characters printed.

There's also no interference with an addtitionally connected kbd, like mine. The "threadirqs" parameter also doesn't harm atm.

I'm so thankful, that you helped leading to a usable solution, you can't imagine!

My very best regards to you, Hui Wang,

Manuel
Comment 16 Manuel Krause 2021-06-01 20:14:32 UTC
Created attachment 297109 [details]
Working patch to enable internal keyboards on MEDION M15T based notebooks

tested on kernel 5.12.8
Comment 17 Manuel Krause 2021-06-01 22:12:27 UTC
Can be that some special keys don't work with that setup:

Fn +F1 (sleep) +F2 (flight) +F9 (touchpad on/off) +F10...12 (sound).

The brightness and screen Fn keys do work (Fn + F5..F8).
Comment 18 Manuel Krause 2021-06-02 17:41:28 UTC
By now, I've also tested the other variants, to make the pattern filled. Also the last one does work.

Complete result:
LEVEL HIGH: lagging keypresses, repeated keypresses, Shift working wrongly
LEVEL LOW:  no problems, only special keys failing *)
EDGE HIGH:  no internal kbd available, the original setup under this BIOS + Linux
EDGE LOW:   no problems, only special keys failing *)

*) The Fn +F1 (sleep) +F2 (flight) +F9 (touchpad on/off) +F10..12 (sound) don't work. The sound keys can go mad (keypresses repeated !). The brightness and screen Fn keys do work (Fn + F5..F8).
Between these different settings I can't notice any difference using the kbd.

Besides these little issues I'm very glad to use this notebook as it is intended, now.

I'm really curious on how we get this into the kernel, and in what appropriate fashion.

Best regards, 
Manuel
Comment 19 Hui Wang 2021-06-03 04:19:55 UTC
(In reply to Manuel Krause from comment #18)
> By now, I've also tested the other variants, to make the pattern filled.
> Also the last one does work.
> 
> Complete result:
> LEVEL HIGH: lagging keypresses, repeated keypresses, Shift working wrongly
> LEVEL LOW:  no problems, only special keys failing *)
> EDGE HIGH:  no internal kbd available, the original setup under this BIOS +
> Linux
> EDGE LOW:   no problems, only special keys failing *)
If your machine have s2idle by default instead of deep, after your machine enter suspend, you could wakeup the system by the normal keys on the keyboard like the key "Enter", Do the both LEVEL LOW and EDGE LOW could wakeup the system by Enter key? or only one of them could? 

> 
> *) The Fn +F1 (sleep) +F2 (flight) +F9 (touchpad on/off) +F10..12 (sound)
> don't work. The sound keys can go mad (keypresses repeated !). The
> brightness and screen Fn keys do work (Fn + F5..F8).
For those unusable function keys, if you run 'sudo showkey -s/sudo showkey' and press those keys, is there any keycode?

Then run 'acpilisten' and press those keys, is there any acpi event?

The function keys are usually implemented by acpi event, and the driver for them is usually in the drivers/platform/x86/*.c

> Between these different settings I can't notice any difference using the kbd.
> 
> Besides these little issues I'm very glad to use this notebook as it is
> intended, now.
> 
> I'm really curious on how we get this into the kernel, and in what
> appropriate fashion.
> 
> Best regards, 
> Manuel
Comment 20 Manuel Krause 2021-06-03 23:40:51 UTC
(In reply to Hui Wang from comment #19)
> If your machine have s2idle by default instead of deep, after your machine
> enter suspend, you could wakeup the system by the normal keys on the
> keyboard like the key "Enter", Do the both LEVEL LOW and EDGE LOW could
> wakeup the system by Enter key? or only one of them could? 

From "cat /sys/power/state" I only have "freeze mem disk".
Both, freeze & mem come back normally, once 'anykey' pressed. LEVEL LOW or EDGE LOW don't make a difference.
Comment 21 Manuel Krause 2021-06-03 23:48:56 UTC
Created attachment 297139 [details]
Function-key-test MK

I've collected the keyboard function-key tests.
Comment 22 replydev 2021-06-04 13:39:41 UTC
Hi everyone I wanted to report that I have tested the patch of Manuel Krause on Kernel 5.12.9, compiled with Arch Build System and that the internal keyboard works properly except the malfunctions with the Fn functions.
Comment 23 Manuel Krause 2021-06-04 19:01:40 UTC
Created attachment 297159 [details]
2nd variant of working patch to enable internal keyboard on MEDION M15T notebooks

This is the second variant to drive IRQ 1 for the kbd, that's working properly on my notebook. On my system it works without dis-/advantages. 
I want to add it for completeness and for the case that someone has spare time to cross-test it with the other.
Please note: This is preliminary code to enable and test basic kbd function.
Comment 24 Dmitry Torokhov 2021-06-05 22:45:47 UTC
What are the original level and trigger values for IRQ1, before we remap them to "edge, high"?
Comment 25 Hui Wang 2021-06-06 08:12:02 UTC
(In reply to Dmitry Torokhov from comment #24)
> What are the original level and trigger values for IRQ1, before we remap
> them to "edge, high"?

Through disassembling DSDT, the original level and trigger is LEVEL_LOW.

      Device (PS2K)
        {
            Name (_HID, "MSFT0001")  // _HID: Hardware ID
            Name (_CID, EisaId ("PNP0303") /* IBM Enhanced Keyboard (101/102-key, PS/2 Mouse) */)  // _CID: Compatible ID
            Name (_UID, Zero)  // _UID: Unique ID
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                Return (0x0F)
            }

            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0060,             // Range Minimum
                    0x0060,             // Range Maximum
                    0x00,               // Alignment
                    0x01,               // Length
                    )
                IO (Decode16,
                    0x0064,             // Range Minimum
                    0x0064,             // Range Maximum
                    0x00,               // Alignment
                    0x01,               // Length
                    )
                IRQ (Level, ActiveLow, Exclusive, )
                    {1}
Comment 26 Hui Wang 2021-06-06 14:19:25 UTC
Created attachment 297187 [details]
a new testing patch

This is a testing patch, I tested it on over 10+ lenovo and 10+ dell machines.
Comment 27 Manuel Krause 2021-06-06 18:43:51 UTC
(In reply to Hui Wang from comment #26)
> Created attachment 297187 [details]
> a new testing patch
> 
> This is a testing patch, I tested it on over 10+ lenovo and 10+ dell
> machines.

Quite comprehensive -- and great work --
that approach also works fine on here (MEDION Akoya P15651/M15T).

(I assume, the failing Fn+ keys are a different issue, not to be followed in this thread from now on.)

Thank you very very much and best regards,

Manuel
Comment 28 replydev 2021-06-09 19:15:50 UTC
(In reply to Hui Wang from comment #26)
> Created attachment 297187 [details]
> a new testing patch
> 
> This is a testing patch, I tested it on over 10+ lenovo and 10+ dell
> machines.

I wanted to ask, what is the practical difference between these three patches? Is there a patch that is better to use? Will these fixes be merged into mainline kernel?

Thanks for your work.
Comment 29 Hui Wang 2021-06-10 11:39:30 UTC
Created attachment 297289 [details]
final version patch

This is the final version of patch and which is merged to linux-acpi repository.


https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=0ec4e55e9f571f08970ed115ec0addc691eda613

Note You need to log in before you can comment on or make changes to this bug.