Add joystick access to the sandbox

[alexlarsson]

From @hadess on April 29, 2016 10:31

As done in this patch:

0001-Add-support-for-accessing-joysticks.txt

Copied from original issue: alexlarsson/xdg-app#149

[alexlarsson]

From @hadess on May 4, 2016 23:19

I looked at the new bubblewrap-using code. Does:

        add_args (argv_array,
                  "--dev-bind", "/dev/input/js0", "/dev/input/js0",
                  NULL);

work if the device in question appears after the application has started? For joysticks, we really want to be able to use them even if the app is already started.

[alexlarsson]

No. In fact, there is no great way to handle that at all, because to create bind mount such as those you need increased privileges, which we have only on startup.
The nicest approach is if we could grant access to an entier directory with only those devices, because then it could later be changed on the host side.

[alexlarsson]

From @hadess on May 12, 2016 16:35

Good thing is that SDL, I'm guessing the primary "legacy" user for this feature, uses udev to discover devices, so we could put it anywhere we wanted in the /dev tree.

We do compile SDL with udev support in the fd.o framework, right?

[alexlarsson]

No, we don't have udev in the runtime, because it needs the database created by udevd, and the udev people (kay) said it is not ABI stable across different versions.

[alexlarsson]

From @hadess on May 12, 2016 17:21

Then that means we can't implement this feature without patching ugly things into SDL :(

[alexlarsson]

From @hadess on May 12, 2016 17:26

Is it feasible to have the whole of /dev/input exported, even if devices other than the joysticks we want to access will be there, but protected through permissions?

This wouldn't fix hotplugging though.

[matthiasclasen]

Is this taken care of with the new wayland protocol that is being discussed ?

[hadess]

Is this taken care of with the new wayland protocol that is being discussed ?

Yes, though there is a long tail of X11 games that'd want joystick support out there. We can revisit whether a better solution that at least allows hotplug can be made to work for X11.

[prcastro]

Any news on this? I am playing a Flatpak + Wine game (Cuphead) and the lack of joystick seems to be one of the only issues with this approach. This prevents DRM free distributors (like Humble Bundle and GOG) to even think about distributing games using flatpak.

[hadess]

It would eventually be fixed by a new Wayland protocol. I don't have any news on this though, best look at the wayland-devel list for updates.

[prcastro]

If the protocol you mentioned was inputfd, it hasn't seen activity since March. What confuses me a little is that keyboard and mice work very well, even inside the sandbox. Does wayland protocol for them already exists? I tought Wayland compositor sent input to the client, no matter the source.

[hadess]

If the protocol you mentioned was inputfd, it hasn't seen activity since March.

It is inputfd.

Does wayland protocol for them already exists?

Yes, those are baked into the first set of protocols that Wayland used. They were later extended with touchscreen and drawing tablets support, which are, again, similar but different enough to warrant additional layers.

[prcastro]

Thanks for the explanation. BTW I was wrong. There is a RFC v3 of inputfd from August, with discussions about it going into September. So it's only two/three months without an update.

[prcastro]

After inputfd is implemented, XWayland clients could use joystick input? If not, how could games relying on X (e.g. all of them) use joysticks?

[TingPing]

We've been using --device=all in some packages atm which is obviously far from ideal so even a basic x11 solution would be valuable.

[Isakku]

Hi there!
Look at the ammount of emulators already Flatpakd!

https://tingping.github.io/2017/10/31/flatpaked-emulators.html

Oh but without proper joystick support they are completely useless!
We indeed need full blown joystick support!
I think there should be an option to be enabled that allows a less strict sandboxing so we can get those gaming emulators working properly. (joystick, read only access to other places such as the media folder, etc.)

[TingPing]

Oh but without proper joystick support they are completely useless!

No most of them just give full device access and they work fine. (It may be missing from one but I suggest opening an issue against that package on https://github.com/flathub )

[hadess]

No most of them just give full device access and they work fine.

As long as the joysticks are already turned on/plugged in when you start the emulators. Anyway, we're retreading old ground here.

[Isakku]

As long as the joysticks are already turned on/plugged in when you start the emulators. Anyway, we're retreading old ground here.

Uhm no. I have installed PCSX2 and I can't get the joysticks to be recognized.

[TingPing]

@Isakku As I said to report an issue... but here you go: flathub/net.pcsx2.PCSX2@1c94762

[aperezdc]

Hi there! I am currently in the process of having gamepad support in WebKitGTK enabled by default and we would prefer to see some solution for this that does not involve --device=all. Is there some way we could help?

(FTR, we have a related WebKit bug for tracking this.)

[hholst80]

I was going to play a game with my son and we spent a good 10 minutes trying to figure out why the joystick did not work. dmesg printed out all fine the gamepad was detected all good. The Gnome desktop didn't really have a tool to test the joystick but I had a non flatpak game and there the joystick worked just fine. So I searched on github and I found this issue.. From 2016, that had a workaround.

I think it is quite reasonable that a flatpak game has the same access to game controllers as the user has because games is a really good use-case for flatpaks. It's like the steam of OSS and a great way to get users of flatpak. I don't need flatpaks at all for most of my own tooling but the games, there I kinda see the point of the paks'.

I hope you can give this some new priory and consider the video game aspects of flatpak. There joysticks are really important feature, as important as sound and 3d acceleration, both works with flatpak already.

[hadess]

I hope you can give this some new priory and consider the video game aspects of flatpak. There joysticks are really important feature, as important as sound and 3d acceleration, both works with flatpak already.

File a bug against the game in question, it should use --device=all until something else comes along.

There's js-test if you want to test your hardware by the way.

[please-be-nice]

has anything changed that would finally allow hotswapping with flatpaks or is it still at an impasse?

[smcv]

Either --device=input (new in the 1.15.x development branch, I'm not sure whether it exists in a release yet) or --device=all gives you access to /dev/input/, including any evdev joysticks that were accessible to you outside the sandbox.

--device=all also gives you raw HID access to any HID joysticks that were accessible to you outside the sandbox. This requires special udev rules on the host system.

Hotplugging joysticks requires using a library or game engine that will detect that it's inside a Flatpak sandbox and monitor /sys and /dev directly, instead of relying on libudev. Recent-ish versions of SDL, libmanette and Proton are known to be able to do this.

If your library or game engine relies on libudev, then it cannot work reliably with hotplug inside a Flatpak sandbox: this is a udev limitation, and Flatpak cannot fix it. The solution is to do what SDL does: use libudev when not in a sandbox, but fall back to using inotify to monitor /dev directly when a Flatpak or Steam Linux Runtime sandbox is detected.

[hfiguiere]

I think it's done with #5481