EDTracker USB analog joystick is not detected (as a controller) #8443
Comments
|
It might be useful to use Unplug the EDTracker, then run You'll get lots of JSON describing your other input devices, which you can ignore, followed by Plug in your EDTracker, and you should see some more JSON appear. Press Ctrl+C to exit from the
This is unusual. What you would normally see, for a HID gamepad like a Playstation or Switch controller or a HID non-gamepad game controller like a flight stick or steering wheel, is three device nodes:
Steam uses SDL, which I think only looks at Similarly, Proton only uses
I would recommend removing these attempted workarounds before using The thing you are probably missing is access to the raw HID device node, which normally comes from rules like this one (which happens to be for a PS5 gamepad): Raw HID device nodes don't get
Not necessarily! If you have asked Steam to remap controls via Generic Gamepad Configuration Support, then yes, Steam needs to recognise it; but if you are letting the game use the game controller directly, then all that should matter is whether Proton recognises it as a game controller and has sufficient permissions to do what it needs to do. The controller-remapping features in Steam are mainly (only?) intended for gamepads that have the same general layout and functionality as an Xbox/Playstation/Switch controller, and I don't think they are generally useful for non-gamepad devices like flight sticks and steering wheels. |
Sorry, I had to manually type that & somehow got it wrong. As you'd expect, it was actually: You can see it correctly stated later where I copied & pasted: KERNEL=="js0"
Done!
Thanks for your explanation. I didn't realise it would have a "/dev/hidrawZ" device (in addition to the one I mentioned). The "steam-devices" udev stuff makes more sense now (and also explains why my changes didn't help).
Thanks, this is what I got: I didn't see anything there saying if it has suitable read/write access, but I think it doesn't?: I could make some guesses as what udev rules to add, but will wait to hear your recommendations on what I should try...
OK, although if Steam & Proton both require a "/dev/hidrawZ" device(??), then Steam seeing the controller must be a good start. But I will also make sure to test whether a Proton game sees the EDTracker, even if Steam still doesn't. |
|
Blind guess: |
|
ValveSoftware/Proton#5126 (comment) could be important here as well since the device has no buttons. |
|
You said:
but according to the The older A more commonly-seen example is a Playstation controller (specifically, PS3 Sixaxis or newer), which is reported with two |
That looks appropriate. |
|
You'll probably also want a rule to give you access to the This is because systemd/udev automatically puts |
|
Many thanks for the replies. Although I need to do more testing, I am very happy to report that the following udev rule allows a Proton 7.0-1 game to detect/use the EDTracker: Steam still does NOT recognise it as a controller, but that's not a problem since I don't need to remap it (remapping wouldn't make much sense). The above rule isn't ideal, because the Vendor/Product codes are a bit generic, and according to this just identify it as an Arduino Leonardo, which I think is just a generic microcrontroller. (Which isn't too surprising, since that's what the EDTracker basically was before it's firmware was flashed.) However, I don't see any way to limit a "hidraw" udev rule to just the EDTracker, unless it's possible for it to match against part of it's "usb_device_ancestor"? The following rule probably would work (I never tested it with Proton just Steam), but it seems even less desirable, if I understand correctly what it's doing: I think it's giving uaccess to all hidraw devices, which doesn't sound very secure. So I'm not sure why Steam's official "steam-devices" package does something similar for "PowerA Wireless Controller for Nintendo Switch" devices. |
This genuinely isn't a "controller" in the sense that Steam means, and neither are flight sticks or steering wheels, so I think this device is out-of-scope for Steam. The game controllers that Steam wants to deal with are specifically the ones that look like a gamepad (Xbox, Playstation, Switch and so on). Everything else should just be opened and used by the game as-is.
I don't think there's necessarily any good solution for that. udev can only identify devices with the information that the kernel makes available to it, so if a consumer-facing product is using the USB ID of a generic microcontroller (because it's based on a generic microcontroller and hasn't swapped the USB ID to one that is more narrowly-scoped), then there isn't a whole lot we can do about that.
You can use values in a udev rule that match against either the device itself, or exactly one ancestor (but you can't match against values from more than one ancestor in the same rule). See udev(7) for details, and use So you might be able to use:
to get a closer match?
It's entirely possible that that rule is wrong: its submitter probably only tested that it did give access to the Switch-clone controller, and probably didn't test that it didn't give access to other HID devices. |
I think it's probably OK, because it's matching on the input (evdev) device node, which for your device is and then using which after collapsing the or in other words, "every raw HID device belonging to the same USB device as this specific evdev node". |
|
@smcv
Thanks. Using that I was able to devise this improved rule, which should be specific to the EDTracker: I've tested this as working, and even rebooted to be doubly sure. It seems to work great with Elite Dangerous running under Proton 7.0-1. I'm using a wildcard for the product name, as there might be other variations/versions ("EDTracker2" certainly suggests that). @kisak-valve There were a lot of EDTracker users for Elite Dangerous a few years ago (see this mamoth 249 page forum thread from 2014 to 2018, never mind other & more recent threads), and it would be a shame if any of them trying to convert to Linux found their beloved EDTracker doesn't work. (I personally can't play Elite Dangerous without mine.) Also, although the main website is now down, it seems it's still possible to buy a new EDTracker (which I hadn't realised myself, so I'm going to buy a backup one in case mine ever dies). |
|
My understanding is that this device does not match the intent for Steam Input and the controller re-mapping it provides, so it's not a good match for the steam-devices udev set. |
|
If you want this device to be supported by default, udev upstream (i.e. systemd) might be a better place to send udev rules (and indeed steam-devices has an issue open at the moment asking for some or all of its udev rules to be upstreamed into systemd). |
|
It's a real shame to hear that Valve has zero interest in seeing non-gamepad controllers working on Linux. Hopefully that changes when/if Linux gaming becomes more popular. |
|
I suspect this may be going off-topic and/or not the appropriate place, in which case I'm sorry, please delete this comment. |
systemd is the upstream project that maintains udev, and the udev "hwdb" which provides a centralized cross-distro repository of device quirks. udev rules for gaming input devices are not specific to Steam: any open-source flight simulator or driving game can potentially benefit from more direct access to gaming input devices, and so can upstream Wine (the version from your OS that is not part of Proton). Over in https://github.com/ValveSoftware/steam-devices where Steam's udev rules for gamepads and VR devices are maintained, we've had a request to send them upstream to systemd, and I think for many of our rules, that would make sense. Having similar udev rules alongside those for non-gamepad devices like flight sticks and your headtracker would also make sense for the platform as a whole, just not really for Steam. Please don't interpret this as thinking that non-gamepads are not something that should work on Linux. They should - but Steam shouldn't have to do anything Steam-specific for that to happen, because the right place to make changes is in lower layers. On Windows or macOS, there's no opportunity to change the lower layers unless you are Microsoft or Apple, so we get "the platform problem": if a higher layer like Steam doesn't like a decision made by a lower "platform" layer, the only option is to work around it. On Linux, it's possible to contribute changes to the lower layers directly, so it makes sense for changes to be targeted to happen in the place that will benefit the most people with the least ongoing maintenance work (which is why the Steam Deck and Proton have resulted in changes to several lower layers, including SDL and the Linux kernel). The Steam Input mechanism that is part of the Steam client is intended to remap gamepad-style game controllers (Steam Controller, Xbox, Playstation, Switch, and generic PC gamepads) so that their input can be fed into older games that expect a keyboard/mouse and do not natively support a gamepad (for example Half-Life used to be in this category, although I think recent builds might have gained native gamepad support). Flight sticks, steering wheels and accelerometers are out-of-scope for this: they're not gamepads, and are not particularly useful for Steam to remap. If a game natively supports these controllers, it can open and use them as-is; if a game doesn't support these controllers, pretending they're a keyboard wouldn't work very well, because they're too different. |
|
I've opened systemd/systemd#22681 to start the process of trying to get this into systemd, and mentioned your EDTracker there as one of the use-cases. |
ID_INPUT_JOYSTICK refers to "joysticks", which for historical reasons is the name given by the Linux kernel and udev to most game-oriented input devices, including flight sticks, gamepads, steering wheels and so on (but not accelerometers or gyroscopes that have axes but no buttons, even if they are part of a gamepad with motion controls such as a PS3/PS4/PS5 controller). My intention is for ID_GAME_CONTROLLER to be a generalization of this, applying to anything that a gamer would think of as a dedicated gaming controller, for example: * all "joysticks", including gamepads, steering wheels and so on * the accelerometer that provides motion controls in a PS3/PS4/PS5 controller, which is part of the same HID device but exposed as a separate evdev device node by the Linux kernel (see systemd#17691) * the EDTracker, which is an Arduino-based accelerometer designed to be used for head tracking by Elite:Dangerous players (see ValveSoftware/steam-for-linux#8443) However, ID_GAME_CONTROLLER should not include accelerometers used to detect the orientation of a laptop/tablet, because those are not really a gaming device (admittedly people have sometimes hooked up older Thinkpads' HDAPS accelerometers to control games by tilting the laptop, but that seems like something that's reasonable to have to configure for yourself). I've named this without the INPUT_ prefix with the intention that it can be applied to both evdev devices and hidraw devices (systemd#22681). Signed-off-by: Simon McVittie <[email protected]>
|
In case anyone wants to get an EDTracker working with Linux these days & finds this bug report, the above UDev rule no-longer works. I had to add a second line to my This means that when I run i.e. The While I was investigating this, I discovered it's possible to get OpenTrack to work with Steam games - and this helped me debug the issues quicker, as I could check whether or not OpenTrack saw it (as a USB joystick), without needing to fully start Elite Dangerous. |
Your system information
Please describe your issue in as much detail as possible:
The EDTracker USB analog joystick (*) is not detected as a controller by Steam, even though the "jstest-gtk" program sees it just fine, and Steam does detect a generic USB gamepad I have. (* EDTracker is actually a head tracker, but to a computer it just looks like a USB 3-axis analog joystick, and so should work with anything that supports a USB analog joystick.)
The "jstest-gtk" program sees it is connected & reports:
EDIT: I got the above Device wrong, it actually says
/dev/input/js0As far as I can tell (see Additional Information below) Steam is not even trying to treat it as a potential joystick/controller.
Steps for reproducing this issue:
Additional Information
I checked "~/.steam/debian-installation/error.log", and nothing is reported when connecting the EDTracker (but I do see "Local Device Found" etc when connecting a generic USB gamepad).
I do have the "steam-devices" package installed:
You can see that EDTracker is recognised as a "USB HID v1.01 Joystick" device:
I'm hoping this might help:
I have tried adding all sorts of udev rules to "/etc/udev/rules.d/60-local.rules" without any improvement (in rough order of increasing desperation):
Of course I did run "udevadm control --reload" afterwards, and have verified it is actually being triggered when I connected the EDTracker.
I should mention that I'm assuming the controller needs to be recognised by Steam, before it will show-up in games running under Proton (e.g. Elite Dangerous).
The text was updated successfully, but these errors were encountered: