Keyboard is unresponsive for some seconds during boot

Framework Laptop 16 Linux
1

Which Linux distro are you using?
Arch Linux x86_64

(If rolling release, last date updated?)
20204-12-27

Which kernel are you using?
6.12.6-arch1-1

Which BIOS version are you using?
03.05

Which Framework Laptop 16 model are you using?
AMD Ryzen™ 7040 Series

Hello,
I am using certain kernel parameters and initramfs hooks in order to have data-at-rest encryption of my root partition with LUKS.

As such, during boot, while in the initramfs stage, the system asks me to input the password for the drive. All good so far.

the problem is that even after this prompt appears, for 2-4 seconds it won’t register any keystrokes. Only after that time passes, can i input the password

My understanding is that the keyboard, like all other input modules, is USB based, and this is a departure from most laptop keyboards which are usually PS/2. I strongly suspect this is at the heart of the issue. Is there a way to make the USB recognition process go faster so that it’s ready by the time the LUKS prompt shows up?

Some info:
Here are my mkinitcpio hooks:

HOOKS=(base systemd autodetect modconf keyboard sd-vconsole sd-encrypt block filesystems fsck)

As you can see, keyboard is before sd-encrypt. I have also replicated this with booster, an alternative initramfs generator.

Here’s lsusb:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 005: ID 8087:0032 Intel Corp. AX210 Bluetooth
Bus 001 Device 006: ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd. Goodix Fingerprint USB Device
Bus 001 Device 007: ID 32ac:0012 Framework Laptop 16 Keyboard Module - ANSI
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 05e3:0625 Genesys Logic, Inc. USB3.2 Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 32ac:0002 Framework HDMI Expansion Card
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

and with lsusb -t we can see the keyboard is using the usbhid kernel module:

/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 480M
    |__ Port 002: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
    |__ Port 003: Dev 003, If 0, Class=Hub, Driver=hub/3p, 480M
    |__ Port 004: Dev 004, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 001: Dev 006, If 0, Class=Vendor Specific Class, Driver=[none], 12M
        |__ Port 003: Dev 007, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 003: Dev 007, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 003: Dev 007, If 2, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 003: Dev 007, If 3, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 005: Dev 005, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 005: Dev 005, If 1, Class=Wireless, Driver=btusb, 12M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    |__ Port 002: Dev 002, If 0, Class=Hub, Driver=hub/3p, 10000M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 10000M
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 001: Dev 002, If 0, Class=Billboard, Driver=[none], 12M
    |__ Port 001: Dev 002, If 1, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 10000M
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
/:  Bus 008.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 10000M
2

Hi,

I have an LUKS encrypted root partition.
I don’t need any special kernel parameters to get it to prompt me for a password.
My kernel command line is:
Command line: BOOT_IMAGE=/vmlinuz-6.12.6 root=UUID=e8662e14-37a5-4f5a-ad40-2a6b505ad5e7 ro rootflags=subvol=@
No initrd hooks.
Using btrfs as the filesystem.
Using Ubuntu as the OS.
The “e8662e14-37a5-4f5a-ad40-2a6b505ad5e7” is the dm-0, that is the unencrypted device created by LUKS.

3

Try switching your Plymouth theme to a text theme. Does that help things?

4

I’m not using plymouth at all, it’s all text based. I don’t eve nhave quiet passed as a param.

It starts up, I get some systemd logs and then the prompt to enter the password.
If I start pressing keys immediately, they won;t be registered. Onyl if I wait for soime 2-4 seconds.

5

Try turning off panel replay on the kernel command line and see if that’s influencing this.

It’s one of the amdgpu.dcdebugmask parameters. I forget the mask though, you will need to look it up.

6

I know that the value for disabling both PSR and Panel Replay is amdgpu.dcdebugmask=0x410

7

I have the same problem as @lpapadakos but with a different setup:

I am using rEFInd to load up zfs boot menu (zbm), which in turn boots from the correct zfs dataset.
Because my zfs mirror is encrypted, I am prompted to enter the password right after selecting the zbm entry in rEFInd.

For quite a while, I had to enter the password twice because the first was wrong. This thread gave me the hint I needed:
I can immediately input a “1” once the password prompt appears, wait some seconds, enter the correct password and it is accepted. Which means that the keyboard is actually unresponsive in the moment the password prompt is shown.

I also tried this with the amdgpu.dcdebugmask=0x410 in the kernel command line (for zbm, as it is the zbm kernel that is loaded at that time) and the behaviour didnt change.

My system

Distro: Ubuntu
Kernel: 6.8.0-50-generic
BIOS: 3.05
Model: 7840HS w/ 7700S

8

Yes, We do seem to have the same problem.

Also, disabling Panel Replay by itself is amdgpu.dcdebugmask=0x400

However that doesn’t help.
I don’t really see this being a GPU issue (for once!) but instead, one arising from the main keyboard being USB.

I’ve tried adding the modules usbhid, hid_generic e.t.c into the image but they actually od get added by default

9

Maybe try building the USB hid directly into the kernel and then it will be ready sooner?

10

An update on this:

I just tried dracut for initramfs generation (I have actually used these 3 in various periods: mkinitcpio, dracut, booster)

Using dracut I don’t get theis issue, and I also don’t get some other issues I had. I’ll list them here:

  1. Keyboard unresponsive for some seconds after prompt shows (the issue of this thread)
  2. amdgpu being loaded causes a flash of black screen and afterwards my vconsole font would return to default.
  3. LUKS password was not being correctly propagated to gdm for unlocking the keyring during autologin, which was causing GNOME to ask for the password again during login (same issue as this Fedora forum post).

For 1) and 2), they probably still occur in a way, but it’s not annoying anymore. IT seems to me dracut has its hooks ordered in a better way or something. Because I can I see the OEM logo and I can tell towards the end, that amdgpu has loaded because it flashes black screen but:

  • it’s not as disruptive because it goes OEM logo → black for a second → LUKS prompt and
  • the keyboard in the prompt works ok
  • the vconsole font afterwards is correct.

Essentially it seems we stay on the OEM logo screen ~2 seconds more butthat gives these things the leeway to be ready when the prompt appears

For 3) the issue is that you have to be using the systemd hook for decrypting the disk, and that one can then communicate to PAM and GDM the password you typed for unlocking the keyring.

mkinitcpio worked correctly for this because I was using the sd-encrypt tool, and dracut uses systemd by default as well, but booster is using its own solution so it didn’t work with that one.

TL;DR Use dracut if you get this issue, it’s a much better initramfs experience for me right now.

My config is /etc/dracut.conf.d/framework.conf:

# Early KMS Start
force_drivers+=" amdgpu "

# Fixes rngd.service start failure
install_items+=" /etc/conf.d/rngd "

# brltty gives error messages and causes shutdown to stall
omit_dracutmodules+=" brltty "

# We're loading microcode with separate initrd cmdline argument
early_microcode="no"

The hook I’m using to automatically generate initramfs is alaso passing manually the options --hostonly and --no-hostonly-cmdline as the cmdline in my case is passed as an argument through EFI vars/EFISTUB

Side NOTE: I am also passing amdgpu.dcdebugmask=0x400 to my params which disabled Panel Replay because otherwise I get some random green artifcats on my desktop when using 165Hz.