Skip to content

Add initial check for joysticks

Ludovico de Nittis requested to merge wip/denittis/t7017 into main

With this commit we start to check if the plugged joysticks are with the expected permissions.

In a canonical Steam installation we also expect to have R/W permissions in /dev/uinput with the current logged in user. So we also check the ACL of /dev/uinput to ensure that the current user, and the mask, have the read and write permissions.

joystick-uinput-issues could be considered a superset of the old can-write-uinput, so I merged them.

For the joysticks expectations I created a file in YAML with a syntax very similar to the one used for the udev rules. I added also the fields that I'm not using directly at this moment, like the mode or the environment variables, because if in the future we will switch steam-devices.git to use YAML, the structure of our joysticks.yaml could be used nearly as is.

The python script yaml-to-json.py is a copy-paste of the one in steamrt.git with just a minor adjustment (take the input file as argv instead of stdin). In meson I launch the script and put the generated joysticks.json in the expectations source directory. This is because if I just installed the generated JSON, a simple ninja -C builddir test would have failed due to the fact that G_TEST_SRCDIR is the "meson.current_source_dir" and this variable is used to search for expectations. But in the expectations source there wasn't a joystick.json file. I'm not entirely sure if there was a better way to do that.

Regarding the cache, I currently store only the joystick patterns (derived from the expectation joysticks.json) and the uinput issues because these two can be considered immutable information. I didn't include the joystick issues because it is based also on the currently plugged in devices and if a user plugs new joysticks we want to re-run the check instead of providing an old cached information.

There are nearly no tests because they are dependent to the /dev/uinput status of the testing machine. Anyway I'll double check if I can write a bunch of simple generic tests so that they'll work also in the CI. Now I added a couple of simple tests.

I left out the SDL2 checks because I'm still not sure at this moment if we can use it for some meaningful checks or not. I will try something and report back my findings.

Edited by Simon McVittie

Merge request reports

Loading