KVM Passthrough - Fixing AULA F75 (Still Broken)

My keyboard isn’t just an accessory. It’s 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.