r/archlinux • u/eXSiR80 • 4h ago

SUPPORT MSI FORGE GK600 TKL Wireless freezes on 2.4 GHz

Hi everyone,

Trying to diagnose a strange issue with my MSI FORGE GK600 TKL WIRELESS keyboard on Arch Linux.

The keyboard works perfectly over USB-C and Bluetooth, but when connected through its 2.4 GHz USB dongle, it occasionally completely stops responding while Steam Input / Xbox controller support is being used. At least I suspected this because during gameplay this happens.

Unplugging and reconnecting the keyboard dongle immediately restores functionality.

System

  • Arch Linux
  • Kernel: zen
  • Desktop: KDE Plasma
  • Motherboard: MSI MPG B550 GAMING PLUS
  • CPU: AMD Ryzen 7 5700X
  • GPU: AMD Radeon RX 9070 XT
  • Keyboard: MSI FORGE GK600 TKL WIRELESS
  • Keyboard USB VID:PID: 0db0:8a8f
  • Keyboard/receiver revision reported by udev: 0138
  • Steam with Steam Input / Xbox controller support (both disabled / enabled)

Behavior

The issue only happens when the keyboard is connected using its 2.4 GHz receiver. When it freezes, unplugging and reconnecting the receiver fixes the keyboard immediately. There are no obvious USB/xHCI errors in the kernel log at the moment of the freeze. The kernel still appears to know that the USB device exists.

When I physically reconnect the dongle, the kernel reports normal USB enumeration:

usb 1-5: New USB device found, idVendor=0db0, idProduct=8a8f
usb 1-5: Product: MSI FORGE GK600 TKL WIRELESS

The receiver is handled by usbhid / hid-generic.

HID layout

The receiver exposes several different HID/input devices rather than just a keyboard.

From /proc/bus/input/devices:

MSI FORGE GK600 TKL WIRELESS Keyboard
MSI FORGE GK600 TKL WIRELESS Mouse
MSI FORGE GK600 TKL WIRELESS Consumer Control
MSI FORGE GK600 TKL WIRELESS System Control
MSI FORGE GK600 TKL WIRELESS Keyboard
MSI FORGE GK600 TKL WIRELESS System Multi Axis
MSI FORGE GK600 TKL WIRELESS ABS input

The interesting one is:

N: Name="MSI FORGE GK600 TKL WIRELESS System Multi Axis"
H: Handlers=event9 js0

So the keyboard receiver exposes a joystick device:

/dev/input/js0

Its input capabilities are reported as:

ATTRS{capabilities/abs}=="3"
ATTRS{capabilities/ev}=="1f"
ATTRS{capabilities/key}=="1 0 0 0 0"
ATTRS{capabilities/rel}=="80"

and:

ATTRS{id/vendor}=="0db0"
ATTRS{id/product}=="8a8f"
ATTRS{name}=="MSI FORGE GK600 TKL WIRELESS System Multi Axis"

The corresponding USB interface is:

bInterfaceNumber = 02
bInterfaceClass  = 03
bInterfaceSubClass = 00
bInterfaceProtocol = 00

The receiver itself exposes five USB interfaces.

Second test: disable both js0 and the corresponding event device (by AI)

I temporarily disabled access to the joystick node and event device:

/dev/input/js0
/dev/input/event9

sudo chmod 000 /dev/input/js0
sudo chmod 000 /dev/input/event9

This is currently the most promising workaround.

Obviously event9 is not a stable device number, so I created a udev rule based on the actual input device identity instead.

udev workaround

/etc/udev/rules.d/99-msi-gk600-no-joystick.rules

# MSI FORGE GK600 TKL WIRELESS
# Prevent Steam Input from accessing the System Multi Axis input collection.

SUBSYSTEM=="input", KERNEL=="event*", \
ATTRS{name}=="MSI FORGE GK600 TKL WIRELESS System Multi Axis", \
ATTRS{id/vendor}=="0db0", \
ATTRS{id/product}=="8a8f", \
MODE:="0000"

SUBSYSTEM=="input", KERNEL=="js*", \
ATTRS{name}=="MSI FORGE GK600 TKL WIRELESS System Multi Axis", \
ATTRS{id/vendor}=="0db0", \
ATTRS{id/product}=="8a8f", \
MODE:="0000"

Reload:

sudo udevadm control --reload-rules

After triggering the rule:

stat -c '%a %n' /dev/input/event9 /dev/input/js0

returns:

0 /dev/input/event9
0 /dev/input/js0

So both the evdev and legacy joystick nodes belonging to the keyboard's System Multi Axis collection are now inaccessible from userspace.

hidraw investigation

The receiver also creates several hidraw devices:

hidraw3 - Keyboard
hidraw4 - Mouse
hidraw5 - composite HID interface
hidraw6 - generic HID
hidraw7 - generic HID

I checked them while Steam was running:

sudo fuser -v /dev/hidraw3 /dev/hidraw4 /dev/hidraw5 /dev/hidraw6 /dev/hidraw7

and:

sudo lsof /dev/hidraw3 /dev/hidraw4 /dev/hidraw5 /dev/hidraw6 /dev/hidraw7

Neither showed Steam keeping any of these devices continuously open. Of course, this does not rule out Steam opening them briefly during HID/controller enumeration.

Current hypothesis

My current theory is:

GK600 2.4 GHz receiver
       |
       +-- Keyboard
       +-- Mouse
       +-- Consumer Control
       +-- System Control
       +-- Keyboard
       |
       +-- System Multi Axis
               |
               +-- /dev/input/eventX
               +-- /dev/input/jsX
                        |
                        +-- Steam Input scans it
                                |
                                +-- receiver/HID state gets stuck

The fact that:

  1. USB-C works
  2. Bluetooth works
  3. only the 2.4 GHz dongle freezes
  4. the receiver exposes a fake/extra joystick-like device
  5. the problem correlates with Steam Input/Xbox controller support
  6. reconnecting the receiver immediately restores the keyboard

makes me suspect either:

  • a firmware bug in the GK600 2.4 GHz receiver,
  • an unusual/broken HID descriptor,
  • or an interaction between Steam Input's device enumeration and this System Multi Axis HID collection.

I do not currently think this is a general keyboard, RF, or basic USB/xHCI problem.

As a note, this keyboard is working perfectly on Windows 11 and situation is Linux spesific not only for Archlinux.

Questions

Has anyone seen something similar with:

  • MSI FORGE GK600 TKL WIRELESS,
  • another wireless keyboard exposing a System Multi Axis / joystick device,
  • Steam Input freezing a composite USB HID receiver,
  • or Steam probing a keyboard's fake joystick interface?
  • or anyone who faced problems like this?
  • or any other reason or solution for that matter?

PS : Powered by AI.

• Upvotes

56% Upvoted

1 comment sorted by

•

u/TargetAlternative693 3h ago

that receiver adding a fake joystick is proper weird, like the keyboard is cosplaying as a gamepad for no reason. never seen a keyboard do that but I had a mouse once with some extra hid junk and steam kept trying to read it as controller until i blocked the node

your udev rule is the cleanest way to handle it, nice work tracking down which device was the culprit. if the firmware is buggy enough that steam just poking the wrong endpoint freezes the whole receiver, maybe try blacklisting the hidraw node too if it still acts up