[SOLVED] HP Laptop Keyboard Not Working At LM Boot Start

[Inundated]

I have the same symptoms of the OP in this thread:

viewtopic.php?f=49&t=286484

My laptop keyboard stopped communicating with Linux Mint. I first noticed it when logging in (no way to type my password in the log in window). Then I tried several combinations of key combinations (especially with the Fn key), including NumLock, but with no success. I then connected an USB keyboard and it worked. I also logged entered the BIOS setup on start up and, not only the function keys were working (or I wouldn't be able to enter the BIOS setup) but all the other keys (like the arrow keys and enter) were working. So, this doesn't seem to be a problem with the hardware part of the keyboard.
I also booted from an USB stick (Linux Mint 18) and it didn't work.

Linux Mint 20.2 is running on an SSD, the computer comes with Windows.

1) The keyboard works fine in Grub, but then stops when I try to log in. There is no keyboard issue in Windows or in the BIOS setup.
2) Sometimes the keyboard is on at the login prompt.
3) Sometimes the keyboard "turns on" after some time, either when trying to get it going (i.e. ENTER at login prompt. a few times, or just waiting).
4) A software keyboard is now on at login, though that is disabled in Accessibility (and looks a little different than that keyboard). I turned on that login software keyboard entirely by accident.
5) The no hardware keyboard at login problem predates the software keyboard, in fact, it started coming up after I just hit random keys trying to get the hardware keyboard going.

This command did nothing, and said it was already installed.

Code: Select all

sudo apt-get install xserver-xorg-input-all

And here is my inxi - Fxz for good measure:

Code: Select all

ystem:
  Kernel: 5.10.0-1052-oem x86_64 bits: 64 compiler: N/A 
  Desktop: Cinnamon 5.0.7 Distro: Linux Mint 20.2 Uma 
  base: Ubuntu 20.04 focal 
Machine:
  Type: Laptop System: HP product: HP Laptop 14-dq2xxx v: N/A 
  serial: <filter> 
  Mobo: HP model: 87FD v: 57.19 serial: <filter> UEFI: AMI v: F.16 
  date: 10/15/2021 
Battery:
  ID-1: BAT0 charge: 42.1 Wh condition: 42.1/41.0 Wh (103%) 
  model: HP Primary status: Full 
CPU:
  Topology: Quad Core model: 11th Gen Intel Core i3-1125G4 bits: 64 
  type: MT MCP arch: Tiger Lake rev: 1 L2 cache: 8192 KiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 31948 
  Speed: 661 MHz min/max: 400/3700 MHz Core speeds (MHz): 1: 640 2: 447 
  3: 973 4: 542 5: 617 6: 642 7: 1004 8: 815 
Graphics:
  Device-1: Intel vendor: Hewlett-Packard driver: i915 v: kernel 
  bus ID: 0000:00:02.0 
  Display: x11 server: X.Org 1.20.11 driver: modesetting 
  unloaded: fbdev,vesa resolution: 1920x1080~60Hz 
  OpenGL: renderer: Mesa Intel UHD Graphics (TGL GT2) v: 4.6 Mesa 21.0.3 
  direct render: Yes 
Audio:
  Device-1: Intel vendor: Hewlett-Packard driver: sof-audio-pci 
  bus ID: 0000:00:1f.3 
  Sound Server: ALSA v: k5.10.0-1052-oem 
Network:
  Device-1: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter 
  vendor: Hewlett-Packard driver: rtw_8822ce v: N/A port: 3000 
  bus ID: 0000:01:00.0 
  IF: wlo1 state: up mac: <filter> 
Drives:
  Local Storage: total: 704.06 GiB used: 26.64 GiB (3.8%) 
  ID-1: /dev/sda vendor: Samsung model: MZNLH128HBHQ-000H1 size: 119.24 GiB 
  temp: 30 C 
  ID-2: /dev/sdb type: USB vendor: SanDisk model: Extreme 55AE 
  size: 465.73 GiB 
  ID-3: /dev/sdc type: USB model: Multiple Card Reader size: 119.08 GiB 
RAID:
  Hardware-1: Intel Volume Management Device NVMe RAID Controller 
  driver: vmd v: 0.6 bus ID: 0000:00:0e.0 
Partition:
  ID-1: / size: 456.93 GiB used: 26.62 GiB (5.8%) fs: ext4 dev: /dev/sdb2 
Sensors:
  System Temperatures: cpu: 43.0 C mobo: N/A 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 268 Uptime: 6m Memory: 3.49 GiB used: 1.31 GiB (37.5%) 
  Init: systemd runlevel: 5 Compilers: gcc: 9.3.0 Shell: bash v: 5.0.17 
  inxi: 3.0.38

[SMG]

And here is my inxi - Fxz for good measure:

There are newer OEM and regular kernels available if you would like to try one. You have very new hardware so perhaps that might help. Let us know if you want to try one and need directions for installing it.

[Inundated]

And here is my inxi - Fxz for good measure:

There are newer OEM and regular kernels available if you would like to try one. You have very new hardware so perhaps that might help. Let us know if you want to try one and need directions for installing it.

Hmm, interesting thought. I even tried booting into one of the existing other kernels...no change. But I haven't tried a new one.

I am not sure if it'll work...after the keyboard shows up, it keeps working fine.

But I am willing to give it a shot...or any idea anyone else has.

[SMG]

I am not sure if it'll work...after the keyboard shows up, it keeps working fine.

It might be somehow related to power management for the bus on which the keyboard is located.

If you want to stay with an OEM Kernel, you have two options:

• Install the latest 5.13-oem kernel with sudo apt install linux-oem-20.04c and reboot.
• Install the latest 5.14-oem kernel with sudo apt install linux-oem-20.04d and reboot.

There are also two non-OEM kernel options available in Update Manager.
Instructions for upgrading to the 5.11 or 5.13(non-OEM version) kernel:

• Open Update Manager.
• Select View > Linux Kernels and click Continue.
• Select 5.11 or 5.13 on the left panel and then click the top-most option on the right panel. An "Install" button will appear.
• Install the kernel and then reboot for it to become active.

[Inundated]

I am not sure if it'll work...after the keyboard shows up, it keeps working fine.

It might be somehow related to power management for the bus on which the keyboard is located.

If you want to stay with an OEM Kernel, you have two options:

• Install the latest 5.13-oem kernel with sudo apt install linux-oem-20.04c and reboot.
• Install the latest 5.14-oem kernel with sudo apt install linux-oem-20.04d and reboot.

Neither of these made any difference.

I haven't tried the non-OEM kernels yet, but I doubt they will fix anything. I will try anyway to clear the list.

I read something about the system going into tablet mode, which might explain it, but I applied the fix I copied in my message above, and that didn't change anything either.

Next, I'll look at power management settings and see if anything stands out to me.

[Inundated]

Nothing stood out in Power Management.

One new data point - the original Linux Mint USB that I used to install also has the no working keyboard at start option, which I tested by trying to type in Terminal. The keyboard started working after a few keystrokes.

Another data point - an external HDD I also installed LM upon shows the same symptoms.

In all cases, the keyboard starts working after a time, a few seconds up to a minute later, usually after many attempted keystrokes.

Again: The keys work in Grub at all times. The keys work in Windows 11 (installed on the laptop) at all times and in the BIOS at all times.

[runningmonk]

Hi - I have a similar laptop running Ubuntu 21.10 and have the same issue of keyboard not registering keystrokes either after boot up or waking up from suspend/hibernate. I tried adding extra parameters to grub with no effect.

Separately, have you been able to get the fingerprint reader working under Linux?

[SMG]

In all cases, the keyboard starts working after a time, a few seconds up to a minute later, usually after many attempted keystrokes.

Have you just let it sit without typing to see if maybe there is some type of time delay on it starting? If that type of situation is happening there might be something in the logs.

What is the output of xinput?

[Inundated]

In all cases, the keyboard starts working after a time, a few seconds up to a minute later, usually after many attempted keystrokes.

Have you just let it sit without typing to see if maybe there is some type of time delay on it starting? If that type of situation is happening there might be something in the logs.

What is the output of xinput?

I've been leaving it a minute or two and so far, so good, though the first time I did that I had to hit a single key before it turned the keyboard on with the second key. I think I am going to time a specific time each time before using the keyboard and see if it makes a difference.

As for xinput:

Code: Select all

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Logitech Wireless Mouse                 	id=10	[slave  pointer  (2)]
⎜   ↳ SYNA32AD:00 06CB:CD50 Mouse             	id=12	[slave  pointer  (2)]
⎜   ↳ SYNA32AD:00 06CB:CD50 Touchpad          	id=13	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ HD Pro Webcam C920                      	id=9	[slave  keyboard (3)]
    ↳ HP TrueVision HD Camera: HP Tru         	id=11	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=14	[slave  keyboard (3)]
    ↳ Wireless hotkeys                        	id=15	[slave  keyboard (3)]
    ↳ HP WMI hotkeys                          	id=16	[slave  keyboard (3)]

[SMG]

I've been leaving it a minute or two and so far, so good, though the first time I did that I had to hit a single key before it turned the keyboard on with the second key. I think I am going to time a specific time each time before using the keyboard and see if it makes a difference.

That might give us a clue as to what time-frame to narrow the search on the logs. I'm not sure exactly what we're looking for as it may be that something else is interfering and until the something else is done the keyboard would not work.

As for xinput:

Code: Select all

 ⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=14	[slave  keyboard (3)]

The keyboard is showing as being there. Those are standard outputs that my older laptop has.

[Inundated]

The keyboard is showing as being there. Those are standard outputs that my older laptop has.

I was trying to put in xinput when the keyboard wasn't there (copy/paste/virtual keyboard) but I was too late.

I have moved to 3 minutes from the login prompt to wait and try it. It has been there except for that one time described above, where it came on after some pushes well past 3 minutes 30 seconds from login prompt. (All these times are after the login prompt first shows, as the keyboard always works in Grub.

The time seems to vary.

Should I start looking at logs?

[SMG]

Should I start looking at logs?

I just ran the following on my laptop:

Code: Select all

journalctl -b | grep -i kbd

and it returned

Code: Select all

Dec 07 06:42:58 SMG-HP-6360t kernel: serio: i8042 KBD port at 0x60,0x64 irq 1

When I searched syslog for "kbd" or "i8042" nothing came up, so you might have to focus on dmesg or journalctl.

Perhaps after noticing the keyboard is working (around the 3 minute mark) run dmesg -T | tail -n 200 to get the last 200 lines of dmesg?

[Inundated]

New data point: I bought a Logitech wireless keyboard (for other reasons) and IT WORKS AT THE LOGIN PROMPT EVERY TIME.

It even works when the built in keyboard does not. In fact, the internal keyboard was off for a few minutes until right before I started the message with the wireless keyboard.

I ran the

Code: Select all

dmesg -T | tail -n 200

command both before and after the internal keyboard came on, and the second time this showed up about 5 minutes after the original boot:

Code: Select all

[Sun Dec 12 19:59:27 2021] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sun Dec 12 19:59:27 2021] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[Sun Dec 12 20:04:19 2021] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input115

The first two lines were in the original run, the last line was added when the internal keyboard started working.

And as mentioned, the wireless keyboard always works.

[SMG]

Code: Select all

 [Sun Dec 12 20:04:19 2021] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input115

The first two lines were in the original run, the last line was added when the internal keyboard started working.

And as mentioned, the wireless keyboard always works.

Keyboards are pretty basic. My HP laptop is much older than yours and this is the line from journalctl.

Code: Select all

kernel: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3

The input number is much lower. Maybe something else is happening on yours which is resulting in the higher input number and that is also what makes it not work right away?

I do not know why there would be a difference between the two keyboards unless there are some hardware gremlins at work.

[Inundated]

The input number is much lower. Maybe something else is happening on yours which is resulting in the higher input number and that is also what makes it not work right away?

I do not know why there would be a difference between the two keyboards unless there are some hardware gremlins at work.

Would posting the full output of the dmesg command show anything?

By the way, xinput does not show the AT keyboard input before it starts working.

[SMG]

By the way, xinput does not show the AT keyboard input before it starts working.

That is to be expected. If the system does not see the keyboard (ie. it is not showing in xinput), then the keyboard can not be used by the system.

Would posting the full output of the dmesg command show anything?

We could see if
dmesg | grep -i 'kbd\|i8042'
indicates any issues.

[Inundated]

We could see if
dmesg | grep -i 'kbd\|i8042'
indicates any issues.

Code: Select all

[    0.304189] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    0.304190] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    0.310255] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.661177] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input8

[SMG]

Code: Select all

[    0.304189] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    0.304190] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    0.310255] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.661177] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input8

I would have expected the usb keyboard to show, but perhaps that is not i8042.

Comparing your results to mine (below), I see a big time difference between the initial lines and the last one for your set. I have an older (and slower) computer than you have so while my initial times are slower than yours, there is not much difference between the initial lines and the AT Translated Set line.

Code: Select all

[    1.167901] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    1.169749] i8042: Detected active multiplexing controller, rev 1.1
[    1.170512] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.170518] serio: i8042 AUX0 port at 0x60,0x64 irq 12
[    1.170558] serio: i8042 AUX1 port at 0x60,0x64 irq 12
[    1.170589] serio: i8042 AUX2 port at 0x60,0x64 irq 12
[    1.170620] serio: i8042 AUX3 port at 0x60,0x64 irq 12
[    1.194911] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[    2.444336] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input11

I'll see if I can find any info about what might affect the timing of when the keyboard is recognized.

[SMG]

Found the following on post #37 on ArchLinux: Various problems with HP Spectre x360 aw2xxxng (Tiger Lake)

Kind-of-workaround for the long keyboard initialization: add "i8042.dumbkbd=1" to the kernel command line.
This is not the best solution as it breaks caps lock led, but otherwise it's ok

Then on post #48 that person goes into the details of what they discovered seemed to be happening. Some people mentioned a BIOS/UEFI update fixed the issue, but others said it did not.

If you would like to try the kernel paramenter, you can use the following information How to add a kernel parameter to temporarily or permanently add the parameter.

[Inundated]

Found the following on post #37 on ArchLinux: Various problems with HP Spectre x360 aw2xxxng (Tiger Lake)

Kind-of-workaround for the long keyboard initialization: add "i8042.dumbkbd=1" to the kernel command line.
This is not the best solution as it breaks caps lock led, but otherwise it's ok

Then on post #48 that person goes into the details of what they discovered seemed to be happening. Some people mentioned a BIOS/UEFI update fixed the issue, but others said it did not.

If you would like to try the kernel paramenter, you can use the following information How to add a kernel parameter to temporarily or permanently add the parameter.

So far, so good! Only one boot, but the keyboard turned on immediately.

Here is the output of the dmesg | grep -i 'kbd\|i8042':

Code: Select all

[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.14.0-1011-oem root=UUID=5f087105-b218-4fe9-bf04-72385613a4e6 ro quiet splash i8042.dumbkbd=1
[    0.018787] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.14.0-1011-oem root=UUID=5f087105-b218-4fe9-bf04-72385613a4e6 ro quiet splash i8042.dumbkbd=1
[    0.311174] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    0.311175] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    0.315644] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.315809] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3

If this keeps working, I will add it permanently!

Thank you for all your help and dedication in this thread!