KVM Passthrough - Fixing AULA F75 (Still Broken)

My keyboard is my primary tool. I rely almost entirely on keyboard commands and shortcuts and rarely touch the mouse, so every key matters. When my AULA F75 developed a bizarre problem with one of its main keys, it became an emergency. The right arrow key was misbehaving, acting as a toggle for Fn or WIN Lock.

I tried everything the internet suggested. Factory resets, deep cleaning the board, and even swapping the switches. Nothing worked. My last desperate option was reinstalling the firmware, but the utility for that only runs on Windows.

I refused to install Windows natively for one task, so I kept the whole thing inside my Linux environment with a Windows guest VM on KVM/QEMU.

The core problem

For the manufacturer’s flashing utility to work, Windows had to see the keyboard as a real USB device, not a virtual one. The difficult part was setting up reliable USB passthrough, also called usb-hostdev passthrough, and assigning the AULA F75’s USB ID to the Windows guest. A firmware flash resets the device and puts it into bootloader mode, where it appears with a different ID. Standard KVM passthrough doesn’t handle that change well.

A persistent XML configuration wasn’t enough because the new ID was unfamiliar. As soon as the keyboard entered bootloader mode, the Linux host claimed it again.

Bootloader hot-plug

First, I identified the two IDs that mattered: the normal ID and the bootloader ID. I used lsusb -t to capture the USB topology, then noted how it changed when the flasher initialized. I created a minimal XML file for the bootloader ID (0603:1020 in the example below).

<hostdev mode='subsystem' type='usb'>
  <source>
    <vendor id='0x0603'/>
    <product id='0x1020'/>
  </source>
</hostdev>

I started the VM with the keyboard passed through under its normal ID. Then I opened the Windows flasher. Its status changed to “Waiting…”, which meant the keyboard had switched IDs.

I immediately ran attach-device with the --current flag so the change would apply to the running VM:

virsh attach-device win10 --file usb.xml --current

It worked! virsh hot-plugged the bootloader ID into the Windows guest. The Windows utility picked up the new connection, cleared the “Waiting…” message, and finished the firmware update with a PASS status.

Still broken..

Even after the firmware update, the rogue right arrow key was still misbehaving 😂. That confirmed the firmware wasn’t the cause. The problem is probably physical damage on the PCB, maybe a broken circuit trace or a faulty diode.

The arrow key is still broken, but I did learn how libvirt handles a USB device that changes identity while a VM is running. That ended up being the useful part of the experiment.