Keyboard not working after shutdown (ASUS Zenbook 13 OLED UM325S)

I just installed Ubuntu 20.04 on my new ASUS Zenbook 13 OLED UM325S.

Keyboard is not working after a cold boot. Keyboard will start working on the next boot, if the device is rebooted at Cryptsetup stage or later. Cryptsetup is affected as well, so encrypted installations are impossible to enter without an external keyboard.

My grub entry; GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Discoveries made

serio_raw kernel module does not load when you do a cold boot. Discovery made in this gist.
AT Translated Set 2 keyboard is the laptop keyboard. This is not visible after a cold boot, but is after a reboot. Gist here.
I am unable to use xinput to manage the properties of the device as suggested by @Sancho.s in his answer below. Sometimes xinput does not show any of the keyboards attached, it only shows virtual devices. libinput on the other hand, shows all devices properly.
WMI ASUS Hotkeys are working, so occasionally I see that brightness adjustments work, sound, etc when F1-F12 is used in combination with the fn key.

Attempts to make it work

I have force loaded serio_raw both using initramfs and load-modules.d without success. Module loads, but does not affect keyboard problem.
Tried running xinput set-prop "AT Translated Set 2 keyboard" "Device Enabled" 1 however, xinput fails that the device is not found.

Workaround at the moment is to connect an external keyboard, wait for Cryptsetup to start, and then press CTRL+ALT+DEL and then boot normally. If I do reboot from GRUB, it has no effect.

Thanks

Solution 1:

I will build on your good work identifying differences between "working-conditions" (WKC) and "non-working-conditions" (NWC).
Note: I am surprised you have to do any of what is suggested below, but if it works... good for you.

You may need to explicitly force loading of module serio_raw by systemd at boot time. Try adding it to /etc/modules (source). Or create file /etc/modules-load.d/serio_raw.conf containing serio_raw. Cold boot and post feedback (how did this affect the differences you found before? see this to check for module insertion).

If you need to load the module earlier on (you mention "cryptsetup is asking for my password on my encrypted drive"), during boot load with initrd, you can use initramfs-tools or dracut. This and this may help. See also official info, or this.

If that alone doesn't work, assuming when you executed xinput list under WKC there was no external keyboard, AT Translated Set 2 keyboard is the internal keyboard (source).

Add automatic execution of command

$ xinput list-props "AT Translated Set 2 keyboard"

upon boot to see if you get something like

Device 'AT Translated Set 2 keyboard':
    Device Enabled (124):   0
    ...

when cold booting. If so, add automatic execution of command

$ xinput set-prop "AT Translated Set 2 keyboard" "Device Enabled" 1

and cold boot again. Please post feedback.

You could also inspect the state of your system in NWC by sshing into it. Perhaps this is "less invasive" than using an external keyboard in terms of keyboard configuration.

Related:

https://unix.stackexchange.com/questions/89538/how-to-tell-which-keyboard-was-used-to-press-a-key

Solution 2:

Your question indicates that the keyboard is not detected by the Linux kernel at all. It does not seem to be related to only the X-Server. Otherwise you would be able to type a password to decrypt the disks or on a virtual terminal.

While desktop keyboards are usually connected via USB nowadays, laptop keyboards can be special. The keyboard of my DELL Precision 5520 keyboard for example is connected to the i8042 Keyboard controller of the SuperIO chip. This is usually the case for standard AT- as well as PS/2 keyboards. If it was compiled as a module, the module would be called "i8042". Ubuntu however compiles serio_i8042 directly into the kernel (see: https://kernel.ubuntu.com/~kernel-ppa/config/hirsute/linux/5.10.0-14.15/amd64-config.flavour.generic ).

If you search for i8042 and "Zenbook", there seem to be known issues with the driver and Zenbooks which is related to the fact that the Zenbooks have i8042 selftest disabled. This used to cause issues with the keyboard after suspend/resume. The first time this was patched with commit 77b425399f6d in 2016 and there is a recent patch to fix this issue for the Zenbook Flip with Kernel 5.4.243 (see: https://lore.kernel.org/lkml/[email protected]/ ). It also looks like the Convertible patch broke something before Kernel 5.11.057 which was fixed back in March 2021. ( https://lore.kernel.org/lkml/[email protected]/ ). My Ubuntu is currently running Kernel 5.11.0-34 which means, that it still has this issue - so might your kernel. I would suggest that you try to update to a later kernel and see if this fixes your issue.

You can either download the .deb packages for a later kernel from: https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D - or you can use the mainline tool to install a more recent kernel:

sudo add-apt-repository ppa:cappelikan/ppa
sudo apt update
sudo apt install mainline
sudo mainline --install-latest

You then have to reboot and pick the most recent Kernel from your bootloader (usually grub).

If the issue related to the kernelbug, your keyboard should now work. you can also have a look at /proc/bus/input/devices to see if your keyboard shows up there.

Solution 3:

There was a kernel bug a few versions back that would affect some notebook keyboards. While a fix was released for 5.8.0-20, this may be an avenue to explore.

Try this:

Open Terminal (if it's not already open)
Determine the chassis type of your machine:
```
cat /sys/class/dmi/id/chassis_type
```
If the value is 31 or 32, disregard the rest of this answer.
Check to see if intel_vbtn is loaded:
```
sudo dmesg | grep intel-vbtn
```
If there is no output, disregard the rest of this answer.
In the event you've made it this far, the solution may be to block intel_vbtn from being loaded:
1. Create a new file in /etc/modprobe.d:
```
sudo vi /etc/modprobe.d/intel-vbtn.conf
```
  ^{Note: Feel free to use a text editor of your choosing. The use of vi in the example is more muscle memory than an endorsement.}
2. Copy the following into the file:
```
# This module breaks the keyboard, so don't load it
blacklist intel_vbtn
```
3. Save the file and exit:
  
  If you're using vi, this would be Esc, then : ⇢ w ⇢ q ⇢ Enter to write and quit the editor.
Shut down and restart to verify that the keyboard works after a cold boot