System details
Fujitsu LIFEBOOK P727 (UEFI 1.27); Omarchy 4.0.4-1; Linux 7.2.5-3-omarchy.
What's wrong?
At early boot, the built-in keyboard does not accept input at the encrypted-root (LUKS) unlock prompt. The same keyboard works in UEFI setup and the boot menu, and works normally after Linux finishes booting. I had to use a USB keyboard to enter the disk passphrase.
The kernel detects the built-in keyboard after boot as an AT Translated Set 2 keyboard on the i8042 controller. Its boot log reports an active i8042 multiplexing controller.
Workaround confirmed
Adding i8042.nomux to the kernel command line fixed input at the unlock prompt. I first verified it as a one-boot Limine option, then persisted it with KERNEL_CMDLINE[default]+=" i8042.nomux" in /etc/limine-entry-tool.d/lifebook-p727-i8042.conf and rebuilt the UKI using limine-mkinitcpio. The built-in keyboard continued working at disk unlock after reboot.
Could this model/controller behavior be documented or otherwise handled for affected hardware? I have not attached the full diagnostic output because it includes machine-specific identifiers and network details.
System details
Fujitsu LIFEBOOK P727 (UEFI 1.27); Omarchy 4.0.4-1; Linux 7.2.5-3-omarchy.
What's wrong?
At early boot, the built-in keyboard does not accept input at the encrypted-root (LUKS) unlock prompt. The same keyboard works in UEFI setup and the boot menu, and works normally after Linux finishes booting. I had to use a USB keyboard to enter the disk passphrase.
The kernel detects the built-in keyboard after boot as an AT Translated Set 2 keyboard on the i8042 controller. Its boot log reports an active i8042 multiplexing controller.
Workaround confirmed
Adding
i8042.nomuxto the kernel command line fixed input at the unlock prompt. I first verified it as a one-boot Limine option, then persisted it withKERNEL_CMDLINE[default]+=" i8042.nomux"in/etc/limine-entry-tool.d/lifebook-p727-i8042.confand rebuilt the UKI usinglimine-mkinitcpio. The built-in keyboard continued working at disk unlock after reboot.Could this model/controller behavior be documented or otherwise handled for affected hardware? I have not attached the full diagnostic output because it includes machine-specific identifiers and network details.