- Nov 25, 2020
-
-
Simon McVittie authored
This was reported by Rémi Bernon as the initial example of SDL's non-udev code path going wrong for touchpads when the invoking user is in the input group. (packaging/libsdl2#1) Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 23, 2020
-
-
Simon McVittie authored
We only have details of the gamepad part for now. I've asked whether it also has accelerometer and touchpad device nodes like the PS4 controller did. Thanks: Sam Lantinga Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 17, 2020
-
-
Simon McVittie authored
The portal device monitor won't be able to do this, because it loses its record of which object path corresponds to which object as soon as the device is removed. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 10, 2020
-
-
Simon McVittie authored
We'll need this if the portal provides a way to open device nodes that don't exist in the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We can use this later, in diagnostic tools. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These are what we really want for SDL and Wine: they're broadly equivalent to the udev ID_INPUT_FOO properties, and identify which devices are desired at a high level. Also add test coverage for the device-type-guessing heuristic. Thanks to various people in Collabora, Codeweavers and #debian-uk for providing `sudo evemu-describe` output for their devices. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These are a useful input for guessing what an input device is. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is the official way to determine what an input device is, at the kernel level. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The name is to leave space for "type flags" (joystick, etc.) later. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Wine/Proton needs these for some of its HID functionality. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is the same approach used by SDL. It doesn't work well in most containers. To facilitate testing this, change sysroot/run-in-sysroot.py so that it doesn't share /run with the host, and signals "we're in a container" by creating /run/host. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This includes: * a public interface implemented by input device monitors * a public interface to be implemented by the input devices they signal * a mock implementation for unit-testing * a unit test for the API * a simple implementation in terms of inotify on /dev * a monitor that can print input devices in JSON format on stdout, and optionally monitor them Implementations in terms of udev, SDL, or a portal service are not yet included. Details of the devices, beyond their paths in /dev and /sys, are also not included. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-