Add popular Thrustmaster HOTAS

[ivyl]

For Proton so it will expose correct mapping of axes for games.

The Proton bit to prefer hidraw has already landed in experimental:
ValveSoftware/wine@1554f4c

[kisak-valve]

Hello @ivyl, #23 (comment) is equally relevant here in as much as the devices in 60-steam-input.rules interact with Steam Input, and it's unclear if other devices should be included in that udev rule set.

[ivyl]

I'm happy to split it off into a separate file. It would be nice to have a clarification from Steam Input developers / people who ship the rules with Steam.

Proton already depends on some of those rules. We wouldn't be able to expose Sony controllers properly without it.

Just for extra context: we don't really have a way of distributing udev rules with Proton - the installation are managed by Steam and we don't do anything privileged. Plus we run inside of the SRT :-)

[smcv]

@TTimo, @slouken: this needs your policy input on what we want the scope of this repository to be, and if it includes sim controllers, whether they should be in 60-steam-input.rules or a new file.

@ivyl: regardless of whether these are in-scope or out-of-scope for steam-devices, if you or a colleague have these devices available to you, it would be useful to see steam-runtime-input-monitor or evemu-describe output for them, so that we can make sure SDL's heuristic to classify non-udev input devices is doing the right thing (similar to libsdl-org/SDL#7597 and libsdl-org/SDL#7598).

The easiest thing to convert into testevdev format is the output of evemu-describe /dev/input/eventX for each device node eventX associated with each of these devices.

Another thing that can be useful when investigating new controllers is the steam-runtime-input-monitor tool that comes with Steam, which will list all the device nodes associated with the controller (including any raw HID device nodes, accelerometers, gyros etc. that it might have). The easiest way to use that is to run

~/.steam/root/ubuntu12_32/steam-runtime/run.sh steam-runtime-input-monitor

with the device not connected, and wait for it to finish describing all your other devices (it should say {"all-for-now": true} at the end). Then connect this device, and copy/paste whatever new information is displayed after the {"all-for-now": true} marker. Press Ctrl+C to stop the input monitor when it has finished displaying the new device(s). Repeat for each device, and if they're switchable wired/Bluetooth (like Sony's official PS4/PS5 gamepads), also repeat for each mode.

[kakra]

@smcv I can create such data for VKB Gladiator NXT (left and right). But these are quite special as the software allows the HID descriptor to be reprogrammed.

[slouken]

@TTimo, @slouken: this needs your policy input on what we want the scope of this repository to be, and if it includes sim controllers, whether they should be in 60-steam-input.rules or a new file.

From my perspective, anything that can read keyboard and mouse should be able to read HID and game controller devices. It's simply not practical to keep adding individual controllers one by one.

However, since that's not the view of distribution maintainers, I will defer to @TTimo on what is appropriate for this repository. If we're going to go ahead and allow all controllers, maybe we should just add all controllers here?

[smcv]

From my perspective, anything that can read keyboard and mouse should be able to read HID and game controller devices.

Unprivileged applications can't read keyboard and mouse, though - they don't have direct evdev or raw HID access to keyboards and mice, only a mediated version of evdev access via the X11 server or Wayland compositor (which generally works if and only if the application has focus). That's been a very intentional design choice in X11 and Wayland to avoid letting unprivileged applications act as keyloggers that record the user's password and other secrets.

There have been proposals for similarly-mediated access via Wayland ("inputfd"), but those were never finished, are only for Wayland and not X11, and certainly don't expose raw HID. Until then, direct access (bypassing X11/Wayland) is all we have.

[kakra]

We could create a file 60-winehid-game-controllers.rules and put everything not covered by Steam Input but covered by winehid in winebus.sys into that file. Then distributions can decide whether they want to include that file or don't.

I'm strongly against exposing keyboard devices with hidraw as that allows keyloggers to read input bypassing X11/wayland security. We had a similar issue in xpadneo which collided with OpenRGB which unconditionally opened up hidraw world readable/writable and thus introduced a potential security-bypass issue. Now it uses a udev helper to check for supported devices before changing permissions. This is an example how we must be careful what we ship.

We can probably create a rule which identifies game controllers via udev tags - but I'm not sure if these are created from kernel knowledge (is BTN_JOYSTICK set) or if this is a hand-crafted tag in hwdb vom udev/systemd. At least some device manually add the tag by looking at PID/VID.

OTOH, wine-proton could simply look at the udev property then because it looks like it reads those anyways - and then it would at least match with these rules.

One could debate over why hidraw for game controllers is anything different than keyboard or mouse from a security perspective (especially because some can act as a keyboard or mouse in the same HID compound device). It's at least as worthy of protection maybe. So in the end, we may need a dbus daemon which could be asked for permission to access such a device, then pass back a hidraw FD, and optionally whitelist the process asking.

[smcv]

We could create a file 60-winehid-game-controllers.rules and put everything not covered by Steam Input but covered by winehid in winebus.sys into that file. Then distributions can decide whether they want to include that file or don't.

If the decision is that flight sticks, steering wheels etc. are out-of-scope for steam-devices, then a separate ruleset for those devices would make sense, yes. https://gitlab.com/jntesteves/game-devices-udev is a similar effort.

I'm strongly against exposing keyboard devices with hidraw as that allows keyloggers to read input bypassing X11/wayland security.

Sure, that was never under consideration: we should never give out direct evdev or raw HID access to keyboards and mice.

We can probably create a rule which identifies game controllers via udev tags - but I'm not sure if these are created from kernel knowledge (is BTN_JOYSTICK set) or if this is a hand-crafted tag in hwdb vom udev/systemd. At least some device manually add the tag by looking at PID/VID.

The maybe-upstreamable version of what steam-devices does is systemd/systemd#22681, but when I tried to resolve that, I got some very mixed messages (systemd/systemd#22860 (comment)). I intend to work on systemd/systemd#22860 (comment) at some point, as a step towards a more ideal solution.

One could debate over why hidraw for game controllers is anything different than keyboard or mouse from a security perspective (especially because some can act as a keyboard or mouse in the same HID compound device)

Perhaps, and that's the part of the discussion on the systemd issue that I don't currently have the skill set or bandwidth to make progress on.

[kakra]

Perhaps, and that's the part of the discussion on the systemd issue that I don't currently have the skill set or bandwidth to make progress on.

This looks like we could simply create a udev helper which looks for these exact usage pages in the descriptor, and then it would return a value for udev rules to tag it as joystick or gamepad. Based on the tag, uaccess could be added to the hidraw device. Would that help? I could work on such a thing, it's pretty straight-forward.

I'm pretty sure there's already a similar udev helper which does classify other types of devices.

[smcv]

This looks like we could simply create a udev helper which looks for these exact usage pages in the descriptor, and then it would return a value for udev rules to tag it as joystick or gamepad.

I think that would be a helpful thing to do, and I'm unlikely to get to it immediately - so if you can propose something for this, please do!

Based on the tag, uaccess could be added to the hidraw device

I think it would be best to add the tag first ("mechanism, not policy"), and then consider setting uaccess on suitably tagged hidraw devices as a follow-up, either inside or outside systemd. Otherwise, you'll get the same failure mode I got with systemd/systemd#22860, where a change that could otherwise have been uncontroversial to add tags to a class of devices gets mired in a discussion about policy where the perfect becomes the enemy of the good.

[kakra]

I think that would be a helpful thing to do, and I'm unlikely to get to it immediately - so if you can propose something for this, please do!

I'm still undecided if we should add different tags for devices that are explicitly game controllers only, and those which are game controller primarily but could also generate keyboard events (like an Xbox Elite 2 controller, or a VKB HOTAS with programmed macros). On the Linux hidraw level they will be just one device even if in evdev they would be split into two or three devices. So we'd collide with the policy "no raw access to keyboard" if we used just one tag.