KVM Passthrough - Fixing AULA F75 (Still Broken)

My keyboard isn’t just an accessory, it’s my primary tool. As a user who relies almost entirely on keyboard commands and shortcuts, rarely touching the mouse, every single key is vital! So, when my AULA F75 keyboard developed a bizarre bug on a core key, it became an emergency, the right arrow key was malfunctioning, 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. The reality was that my last, desperate attempt had to be a firmware re-installation, a process annoyingly locked behind a Windows-only utility.

Since I absolutely refused to install Windows natively just for one need, my solution had to be contained within my Linux environment, a Windows guest VM on KVM/QEMU.

The core problem

For the manufacturer’s flash utility to work, the keyboard needed to be seen as a native device, not a virtual one. The real battle was getting a reliable USB passthrough (or usb-hostdev passthrough) set up to dedicate the AULA F75’s USB ID directly to the Windows guest as any firmware flash requires the device to reset and enter a bootloader mode. This process is fatal to standard KVM passthrough.

Standard persistent XML configuration was not enough against this dynamic identity change because the new ID was unfamiliar, and the Linux host quickly claimed the device.

Bootloader hot-plug

I first had to identify the two critical IDs, the normal ID and the bootloader ID using lsusb -t to capture the topology, noting the shift when the flasher was initialized. I then created a minimal XML file specifically for the target 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 initially passed through using its normal ID. Then started the Windows flasher app, the flasher status changed to “Waiting…” (signaling the ID shift).

I immediately executed the attach-device command using the --current flag to apply the change to the running domain:

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

It worked! The virsh command successfully utilized its hotplug capability to inject the bootloader ID into the Windows guest. The Windows utility grabbed the new connection, cleared that “Waiting…” status, and the firmware process finished with a successful PASS status.

The final verdict

Despite the successful firmware update, the rogue right arrow key was still misbehaving 😂. This confirmed that the root cause was not firmware, but likely physical hardware damage on the PCB. Maybe be a broken circuit trace or faulty diode.

But the real win is that I discovered libvirt’s cool feature for handling dynamic USB changes, which is far more valuable takeaway than a working arrow key!