UX410UA: Missing dom0 kernel modules for asus wmi

[qwrd]

Qubes OS version
R4.0 (4.0.2-rc2)

Affected component(s) or functionality
Laptop keyboard

Brief summary
Some Fn+X keyboard buttons are not working

To Reproduce

1. Use an Asus Zenbook UX410UA (probably affects other Zenbooks too)
2. Perform default Qubes installation on it (UEFI, need to disable secure boot)
3. Boot the system (optional: update dom0, reboot)
4. Press the Fn+X buttons (X = F3, F4, F9, maybe some others)
5. Nothing happens

Expected behavior
All Fn+X keys should work.

Actual behavior
Some Fn+X keys like keyboard backlight brightness (Fn+F3, Fn+F4) and touchpad toggle (Fn+F9) are not working. Others like Fn+F5/F6/F7 (display brightness) and Fn+F10/F11/F12 (sound volume) work fine. Arch linux wiki has a page for Zenbook UX31A that has a list of function keys that are similar to UX410UA (see links below).

Screenshots
https://www.asus.com/Laptops/ASUS-ZenBook-UX410UA/

Additional context
The relevant WMI kernel modules for asus zenbook laptops appear to be missing in dom0 (they are present in Fedora 30 AppVM though).

In dom0: (kernel 5.3.7.1)

[user@dom0 ~]$ find /lib/modules -name *asus*
/lib/modules/5.3.7-1.pvops.qubes.x86_64/kernel/drivers/input/tablet/pegasus_notetaker.ko
/lib/modules/5.3.7-1.pvops.qubes.x86_64/kernel/drivers/media/rc/keymaps/rc-asus-pc39.ko
/lib/modules/5.3.7-1.pvops.qubes.x86_64/kernel/drivers/media/rc/keymaps/rc-asus-ps3-100.ko
/lib/modules/5.3.7-1.pvops.qubes.x86_64/kernel/drivers/hwmon/asus_atk0110.ko
/lib/modules/5.3.7-1.pvops.qubes.x86_64/kernel/drivers/hid/hid-asus.ko
/lib/modules/5.3.7-1.pvops.qubes.x86_64/kernel/drivers/net/usb/pegasus.ko
/lib/modules/5.3.7-1.pvops.qubes.x86_64/kernel/drivers/platform/x86/asus-laptop.ko
/lib/modules/5.3.7-1.pvops.qubes.x86_64/kernel/drivers/platform/x86/asus-wireless.ko
/lib/modules/4.19.80-1.pvops.qubes.x86_64/kernel/drivers/input/tablet/pegasus_notetaker.ko
/lib/modules/4.19.80-1.pvops.qubes.x86_64/kernel/drivers/media/rc/keymaps/rc-asus-pc39.ko
/lib/modules/4.19.80-1.pvops.qubes.x86_64/kernel/drivers/media/rc/keymaps/rc-asus-ps3-100.ko
/lib/modules/4.19.80-1.pvops.qubes.x86_64/kernel/drivers/hwmon/asus_atk0110.ko
/lib/modules/4.19.80-1.pvops.qubes.x86_64/kernel/drivers/hid/hid-asus.ko
/lib/modules/4.19.80-1.pvops.qubes.x86_64/kernel/drivers/net/usb/pegasus.ko
/lib/modules/4.19.80-1.pvops.qubes.x86_64/kernel/drivers/platform/x86/asus-laptop.ko
/lib/modules/4.19.80-1.pvops.qubes.x86_64/kernel/drivers/platform/x86/asus-wireless.ko

[user@dom0 ~]$ lsmod | grep asus
asus_wireless          20480  0

In Ubuntu Mate 19.10 Live: (kernel 5.3.0-18)

ubuntu-mate@ubuntu-mate:~$ find /lib/modules/ -name *asus*
/lib/modules/5.3.0-18-generic/kernel/drivers/hid/hid-asus.ko
/lib/modules/5.3.0-18-generic/kernel/drivers/hwmon/asus_atk0110.ko
/lib/modules/5.3.0-18-generic/kernel/drivers/input/tablet/pegasus_notetaker.ko
/lib/modules/5.3.0-18-generic/kernel/drivers/media/rc/keymaps/rc-asus-pc39.ko
/lib/modules/5.3.0-18-generic/kernel/drivers/media/rc/keymaps/rc-asus-ps3-100.ko
/lib/modules/5.3.0-18-generic/kernel/drivers/net/usb/pegasus.ko
/lib/modules/5.3.0-18-generic/kernel/drivers/platform/x86/asus-laptop.ko
/lib/modules/5.3.0-18-generic/kernel/drivers/platform/x86/asus-nb-wmi.ko
/lib/modules/5.3.0-18-generic/kernel/drivers/platform/x86/asus-wireless.ko
/lib/modules/5.3.0-18-generic/kernel/drivers/platform/x86/asus-wmi.ko

ubuntu-mate@ubuntu-mate:~$ lsmod | grep asus
asus_nb_wmi            28672  0
asus_wmi               32768  1 asus_nb_wmi
sparse_keymap          16384  1 asus_wmi
asus_wireless          20480  0
wmi                    32768  2 asus_wmi,wmi_bmof
video                  49152  2 asus_wmi,i915

Full list of running kernel modules for Ubuntu Mate 19.10 on UX410UA:
https://pastebin.com/9i9JpPrA

I've done some tests using ubuntu live 19.10 and the Fn+X keys appear to be working just fine. Removing the "asus-nb-wmi" kernel module by using the rmmod command caused the mentioned Fn+X (X = F3, F4, F9) keys to stop working while the others (X = F5, F6, F7, F10, F11, F12) worked fine. When adding the module back using modprobe, the keys started working again.

The Qubes dom0 kernel should include the missing WMI kernel modules for asus laptops.
Looks like the missing modules are: asus-wmi, asus-nb-wmi

Solutions you've tried
Upgraded kernel from LTS (4.19.80-1) to latest (5.3.7.1) - not working

Relevant documentation you've consulted
https://www.qubes-os.org/doc/reporting-bugs/
https://www.qubes-os.org/doc/software-update-dom0/
https://wiki.archlinux.org/index.php/ASUS_Zenbook_Prime_UX31A#Function_keys
https://www.qubes-os.org/hcl/#asus_zenbook-ux31a_i7-3517u_ivy-bridge_hd4000 (similar device)

Related, non-duplicate issues
none

[marmarek]

Looks like asus-wmi module depends on PCI hotplug, which we intentionally disable for security reasons (make it harder to perform DMA attack by plugging in ExpressCard/Thunderbolt device). Ideally we'd block it at Xen level, but it isn't possible yet.

[qwrd]

Yes, I was beginning to wonder why the modules aren't there. I recompiled the dom0 kernel using qubes-builder setup and the modules did not appear in the directory, which was odd since they were enabled by default in config-base:

CONFIG_ASUS_WMI=m
CONFIG_ASUS_NB_WMI=m

The only way I can currently disable the touchpad is by doing "rmmod i2c-hid" (not that the touchpad works properly, I'm investigating that part too).

[janescook]

Hi,
I also tried many different ways, but no resuts... Did you find a solution ? It's really annoying to cannot use keyboard backlight... If you have a solution, please share it :)
Qubes is great !

[fepitre]

I can confirm that if we remove the security put into config-qubes for PCI hotplug, the modules are built and available. In my case, I've got my keyboard backlight working. But this was for testing purpose. I don't wont to keep it as is. I'll try to find a solution, if it's possible, to get the modules working without this CONFIG option.

[someuser7882]

Hello @marmarek and @fepitre

Thanks for the input you have provided on clarifying this issue. I'm evaluating whether disabling this security measure is worth the risk given my situation. Please see my two questions below

Looks like asus-wmi module depends on PCI hotplug, which we intentionally disable for security reasons (make it harder to perform DMA attack by plugging in ExpressCard/Thunderbolt device). Ideally we'd block it at Xen level, but it isn't possible yet.

1. My setup doesn't involve any externally-pluggable Thunderbolt or ExpressCard interfaces and I am not worried about an attacker gaining physical access to my machine. With this information, would you share the opinion that disabling this security feature doesn't increase the risk of a DMA attack on my system? Please feel free to elaborate

I can confirm that if we remove the security put into config-qubes for PCI hotplug, the modules are built and available. In my case, I've got my keyboard backlight working. But this was for testing purpose. I don't wont to keep it as is. I'll try to find a solution, if it's possible, to get the modules working without this CONFIG option.

@fepitre , would you be so kind as to providing steps on how this could be achieved? namely, what config-qubes is and where to find it. what to modify, and how to implement the modification into a working qubes system.

I know your time is valuable so I really appreciate any elaborations you could provide.

Regards,
SU

[fepitre]

@fepitre , would you be so kind as to providing steps on how this could be achieved? namely, what config-qubes is and where to find it. what to modify, and how to implement the modification into a working qubes system.

From what I remember you just need to remove this line https://github.com/QubesOS/qubes-linux-kernel/blob/master/config-qubes#L77 and then do build the kernel by yourself. You can bump the rel file https://github.com/QubesOS/qubes-linux-kernel/blob/master/rel to ensure to upgrade properly your dom0 version.

If you don't know how to build a Qubes component, you can have a look here: https://www.qubes-os.org/doc/qubes-builder/ else you can also ask here. I'm pretty sure to have written one or two times somewhere on the lists on how to build the kernel.

[someuser7882]

@fepitre, Thank you for your explanations. I can also confirm that removing that line is all what is needed to get the modules to load.

[youhitgit]

Sorry to be a pain.

Can anyone @someuser7882 @fepitre explain how to do this in a little more detail please ? I am pretty new to all this I only installed qubes yestderday and I came from windows :-|
I have some experience with linux, freebsd etc, etc.... but not much.

Do I have to build the whole OS from scratch and then do a fresh install ?

If it is just a "component" of the OS do I "make a customized build" ? do I use "pre built qubes packages" ?

The "rel" thing @fepitre mentioned and linked, seems to be completely blank ?
I assume you mentioned this to stop updates breaking the modification ?
How, what and when would I do with that ?

Again sorry for being stupid and thanks in advance to anyone who can help me.

Also @qwrd you mention the touchpad not working "properly", mine works for touch clicks and two finger scrolling BUT the 3 finger swipe for "back" and "forward" in firefox etc does not work.
Is that what you meant ? Did you find a fix ? Thank you

BTW my laptop is a Asus N56JR.
Screen brightness and volume FN's work good ! BUT keyboard backlight and touchpad disable FN's do not work, so I assume it is the same problem.

[DemiMarie]

Still an issue, though arguably a duplicate of #6620.

[github-actions]

This issue has been closed as a "duplicate." This means that another issue exists that is very similar to or subsumes this one. If any useful information on this issue is not already present on the other issue, please add it in a comment on the other issue. Here are some common cases of duplicate issues:

• The other issue is closed. The other issue being closed does not prevent this issue from duplicating it. We will examine the closed issue and, if appropriate, reopen it.
• The other issue is for a different Qubes release. We usually maintain only one issue for all affected Qubes releases.
• The other issue is very old. The mere age of an issue is not, by itself, a relevant factor when determining duplicates.

By default, the newer issue will be closed in favor of the older issue. However, we make exceptions when we determine that it would be significantly more useful to keep the newer issue open instead of the older one.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "duplicate" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.