new steam controller + hyprland desktop mode mouse cursor

[mafk]

[just specifying that I have the new steam controller, not the old one. certainly makes searching for help difficult]

my controller arrived and works great in the games I've tested it on. the issue I'm having is that in desktop mode, my right trackpad is not taking over my system cursor the way it does on steam deck and windows. within steam I can see it is moving however the cursor is visible. my system cursor does not move.

Claude helped me troubleshoot and posted this summary:

**Steam Controller 2 (SC2) — Desktop Mouse Not Working on Linux (Wayland/Hyprland)**

**System:**
- Distro: CachyOS (Arch-based)
- Compositor: Hyprland (Wayland)
- Steam version: 1.0.0.85-6 (also tested with Steam Beta)
- Controller: Steam Controller 2 (USB ID: `28de:1304`, "Steam Controller Puck")

**Issue:**
The SC2 does not function as a system-wide mouse in desktop mode on Linux. The controller works perfectly in games. The trackpad moves an invisible secondary cursor that is separate from the system cursor — hover effects are visible in Steam but the visible cursor does not move.

**Root Cause Identified:**
Steam Linux is misidentifying the SC2 as a Steam Deck component and attempting to register it via the Deck hardware registration path. This fails every time with the following errors in `~/.steam/steam/logs/controller.txt`:

```
Deck Controller PCB Serial# invalid: NA
BYieldingCompleteSteamControllerRegistration - Error committing registration completion of controller & account pair: [ID] Invalid Parameter
```

This error occurs on every Steam launch and has been consistent since day one (May 8, 2026). The registration failure means Steam never creates a uinput virtual mouse device, so the SC2 cannot take over the system cursor.

**Confirmed NOT the cause:**
- udev rules — vendor-wide `28de` rules are present and correct in `/usr/lib/udev/rules.d/60-steam-input.rules`
- uinput access — user has direct ACL access (`getfacl` confirmed `user:mafk:rw-`)
- uinput module — loaded (`lsmod | grep uinput` shows `uinput 28672 3`)
- Steam hidraw access — Steam holds all five hidraw interfaces open (`/proc/[pid]/fd` confirmed)
- Hyprland config — no conflicting input rules; Hyprland correctly sees the puck mouse devices
- Registering via Windows Steam — attempted registration on Windows Steam (where the controller works perfectly), error persists on Linux

**Relevant log output:**
```
[2026-05-10 08:58:45] Deck Controller PCB Serial# invalid: NA
[2026-05-10 08:58:45] Deck Controller PCB Serial# invalid: NA
[2026-05-10 08:58:45] BYieldingRegisterSteamController
[2026-05-10 08:58:45] BYieldingCompleteSteamControllerRegistration
[2026-05-10 08:58:45] BYieldingCompleteSteamControllerRegistration - Error committing registration completion of controller & account pair: FXA99604045FB Invalid Parameter
```

**Expected behaviour:**
Steam should create a uinput virtual mouse device and take system-wide cursor control, as it does on Windows and SteamOS/Steam Deck.

**Additional notes:**
- `BYieldingQueryAccountsRegisteredToController` also consistently returns `server unavailable checking local cache` — however general Steam API connectivity is confirmed working via `curl https://api.steampowered.com`
- The SC2 was briefly functional as a desktop mouse on one occasion (cursor moved system-wide), but this could not be reliably reproduced
- USB ID `28de:1304` is not present in the shipped `60-steam-input.rules` (only vendor-wide `28de` rules exist)

---

That should give Valve everything they need to identify the bad code path. Good luck!

[MaqFnord]

I had similar issues on CachyOS (KDE Plasma) with games (desktop mode was fine and worked, though). The controller would not work in most games. Some games outright did not work. Maybe one joystick would but the the rest would not. Other games only the "regular" buttons and joysticks worked. But every button on the back was ignored. Stuff like that. I tried the controller on my Bazzite Ally X - it worked fine there. Then it clicked for me. The problems on my PC were caused by the PROTON_ENABLE_WAYLAND=1 command. I had that enabled in almost every game on my pc. As soon as I removed the command the controller worked without any issue. For now I'm running every game without it.

So maybe your problems are coming from wayland, too? Because you know, Hyprland is a wayland compositor! But idon't really know what causes the issue. Is it wayland, or something else? On KDE the controller works in desktop mode and gamepad mode. Do you have KDE installed as an option? Can you test your controller there?

[Jojopanis]

I have a similar problem, and the weird part is that, before launching the steam client, it works fine! I can use the trackpads as mouse on other applications as intended, but as soon as I launch steam, the mouse doesn't move from the trackpad anymore... I hope that can help narrow down the problem

Also, I'm "just" on base Arch Linux, with the 7.0 linux-zen kernel, also on Hyprland

[エラーゼロ]

...

[mafk]

Originally posted by Jojopanis:

I have a similar problem, and the weird part is that, before launching the steam client, it works fine! I can use the trackpads as mouse on other applications as intended, but as soon as I launch steam, the mouse doesn't move from the trackpad anymore... I hope that can help narrow down the problem

Also, I'm "just" on base Arch Linux, with the 7.0 linux-zen kernel, also on Hyprland

whoa I just checked this and that is the same for me. weird

[mafk]

Here you go:

---

**Update after further troubleshooting:**

Key new finding: **the trackpad works correctly as a system mouse before Steam launches.** Unplugging and replugging the dongle with Steam not running gives full cursor control immediately. As soon as Steam launches, it grabs exclusive control of all hidraw interfaces (`/dev/hidraw12` through `/dev/hidraw16`) and the cursor stops working.

This means Steam is actively breaking something that works — it grabs the device out of lizard mode, fails to create a uinput virtual mouse due to the registration bug, and leaves you with nothing.

Confirmed by repro steps:
1. Close Steam completely
2. Unplug and replug the dongle
3. Trackpad immediately controls system cursor ✅
4. Launch Steam
5. Trackpad no longer controls system cursor ❌

Also confirmed by Jojopanis above — same behaviour on plain Arch Linux with Hyprland.

Attempted workarounds that did **not** help:
- `steam -steaminput 0` — Steam still grabs hidraw for its own hardware
- `steam -nocontroller` — same
- Revoking hidraw permissions after Steam launches — Steam keeps existing file descriptors open
- Populating `configset_FXA99604045FB.vdf` manually — no effect

This points to a fix being needed in Steam's controller initialisation code — specifically, if the uinput virtual mouse creation fails (due to the registration bug), Steam should fall back to leaving the device in lizard mode rather than holding exclusive hidraw access with nothing to show for it.

---

[mafk]

The fix is:

yay -S rustup
rustup default stable
rustup target add i686-unknown-linux-gnu
yay -S lib32-extest
Then add to your Steam desktop entry Exec line:

Exec=env LD_PRELOAD=/usr/lib32/libextest.so /usr/bin/steam %U

[goob]

I'm having the exact same issue on Void linux with wayland. Once steam is running, the trackpad stops working as a cursor on desktop (everything works fine in games though). There is an input being registered in the steam desktop client, but the desktop cursor doesn't follow so it's almost impossible to follow where it is and it doesn't seem to register at all outside of steam.

I hope this gets visibility so valve can take a look!

[goob]

Originally posted by goob:

I'm having the exact same issue on Void linux with wayland. Once steam is running, the trackpad stops working as a cursor on desktop (everything works fine in games though). There is an input being registered in the steam desktop client, but the desktop cursor doesn't follow so it's almost impossible to follow where it is and it doesn't seem to register at all outside of steam.

I hope this gets visibility so valve can take a look!

After some more digging, it seems steam input does not always play nice with wayland, and valve doesn't have plans to address this in the future. This sums up the problem if anyone is looking for more info: https://github.com/ValveSoftware/steam-for-linux/issues/10632