Volume Wheel - Steelseries Keyboard

General system Kernel, boot, graphics & hardware
1

EndeavorOS running KDE Plasma 6,

I am using a Steelseries Apex Pro TKL keyboard which has a wheel for controlling volume up, down and mute. I have tried it with Kubuntu and EndeavorOS with KDE and it works out of the box with Kubuntu but it doesn’t in EndeavorOS.
For the moment I have gotten it to work using input-remapper but it is not ideal since the service uses up a fair bit of RAM for what it’s doing.

I’ve run all kinds of tests up and down (but I am very much a newbie with these kinds of things).
showkey –keycodes gives me keycodes 113 (Mute), 114 (VolDown) and 115 (VolUp) for all the volume wheel actions.

xmodmap -pke shows me that XF86AudioLowerVolume / RaiseVolume / Mute are all under the keycodes 121, 122 and 123.

These two things look identical on a live environment of Kubuntu where the volume wheel just works (both the keycodes that evtest detects and the keycodes listed in xmodmap).

When I record the actions of the volume wheel in input-remapper they get correctly identified as XF86AudioLowerVolume / RaiseVolume / Mute.

I compared the Kubuntu 60-keyboard.hwdb with EndeavorOS to see if there were any difference and there were but nothing that handles either Steelseries hardware (Steelseries not mentioned anywhere) nor in generic hardware nor anything mentioning volume or mute functions.

lsusb -v | grep -i steel properly identifies the keyboard brand and model:
Bus 001 Device 011: ID 1038:1614 SteelSeries ApS SteelSeries Apex Pro TKL idVendor 0x1038 SteelSeries ApS idProduct 0x1614 SteelSeries Apex Pro TKL iManufacturer 1 SteelSeries iProduct 2 SteelSeries Apex Pro TKL

input-remapper also identifies the keyboard.

lsusb -t gives me this info on Bus 001:
Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
|__ Port 004: Dev 002, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 005: Dev 003, If 0, Class=Wireless, Driver=btusb, 480M
|__ Port 005: Dev 003, If 1, Class=Wireless, Driver=btusb, 480M
|__ Port 005: Dev 003, If 2, Class=Wireless, Driver=btusb, 480M
|__ Port 006: Dev 004, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 002: Dev 012, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 002: Dev 012, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 004: Dev 011, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 004: Dev 011, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 004: Dev 011, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 004: Dev 011, If 3, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 004: Dev 011, If 4, Class=Human Interface Device, Driver=usbhid, 12M

I can’t find anything that distinctly differs between Kubuntu and EndeavorOS with KDE Plasma 6 that should make a difference with the keyboards functions that I know of. I have run up against a wall. It feels like it should just be fixable without having to add extra services to run seeing as it works out-of-the-box elsewhere.

2

Welcome to the EndeavourOS forum. :handshake: I hope you enjoy your time here.

As a starter, try doing a factory reset as suggested here:
https://support.steelseries.com/hc/en-us/articles/360043313811-My-keyboard-is-experiencing-software-issues

If that doesn’t fix it, they also suggest

If resetting does not resolve the issue, please ensure that your keyboard
is connected directly to a compatible USB 3.0 port on your computer.
Additionally, we recommend testing different USB ports to verify proper functionality.

Pudge

3

The keyboard works without any resetting or port swapping, just by rebooting from Endeavor into a live Kubuntu environment. So the port works as well as nothing broken with the keyboard internally software-wise.

I tried switching ports and doing the reset anyways but that did not fix it.