FlatPak

[mm12]

Since this is specifically for the Deck, and the Deck only officially supports FlatPak installs, I think it would be a good idea to support them.

[kmicki]

That's a very good idea. I am going to look into that eventually.

Does anybody know if flatpak supports running as a background service/daemon, with low-level access to USB devices and ability to host a UDP server?

[hotburger]

The background service and server are definitely possible but the usb access is probably not.

[kmicki]

Steam Link is distributed by flatpak and it passes the control of Steam Deck controls entirely to the host, so I think USB access has to be also possible somehow.

[streetpea]

You may have already figured this out but you can use --device=all in your yaml or json file when building the flatpak to do this (see the flatpak docs for more info). This passes the entire /dev directory to the flatpak application. The permissions are those of the user, so whatever the user can access in the /dev directory on their system, the flatpak app should be able to access, including usb. You have to use all for now as there isn't a specific usb option as you can see from the flatpak issue here

Additional Note:

Steam Deck has a udev rule for usb/hidraw access by the deck user (given the user is physically logged in). You can see it when logged into a Steam Deck with:

cat /lib/udev/rules.d/70-steam-jupiter-input.rules

as the following:

# USB devices
SUBSYSTEM=="usb", TAG+="uaccess"

# HID devices over hidraw
KERNEL=="hidraw*", TAG+="uaccess"

# Steam Controller udev write access

However, it looks like you aren't reading via the usb or hidraw interfaces and are instead reading the /dev/usb/hiddevX file where X is the device corresponding to the Steam Deck. In this case, you need elevated permissions which it seems like you set up with a group that you add the Steam Deck user to in your install script. As long as this is done, you should be able to use --device=all for the flatpak and usb direct access should work.

You can see example manifests on flathub using --device=all such as the manifests for the citra and yuzu emulators.

[kmicki]

@streetpea thank you for the write-up.

I've read up on udev a little and it looks like the rule:

SUBSYSTEM=="usb", TAG+="uaccess"

should allow access to all usb/hiddev* also but it doesn't. Any idea why that might be? I'm not even sure if those actually allow access to hidraw, I will check that when I have a chance.

The rule applied to group usbaccess by sdgyrodsu install script is actually more restrictive (as it is only for a specific device, not entire usb subsystem) and it works that way.

Maybe there's some ACL configuration that allows only steam process to access those or something?

[streetpea]

@kmicki it probably has to do with another rule interfering then. Anyway, you can tell it's not getting applied properly if you look at the extended permissions (acls) with getfacl (note: the extended attributes denoted by a + in ls -l which are added by the +=uaccess udev rule)... for usb you get

getfacl /dev/usb/*

USB Output:

getfacl: Removing leading '/' from absolute path names
# file: dev/usb/hiddev0
# owner: root
# group: root
user::rw-
group::---
other::---

For hidraw devices you get

getfacl /dev/hidraw*

Hidraw Output:

getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw0
# owner: root
# group: root
user::rw-
user:deck:rw-
group::---
mask::rw-
other::---

# file: dev/hidraw1
# owner: root
# group: root
user::rw-
user:deck:rw-
group::---
mask::rw-
other::---

# file: dev/hidraw2
# owner: root
# group: root
user::rw-
user:deck:rw-
group::---
mask::rw-
other::---

# file: dev/hidraw3
# owner: root
# group: root
user::rw-
user:deck:rw-
group::---
mask::rw-
other::---

# file: dev/hidraw4
# owner: root
# group: root
user::rw-
user:deck:rw-
group::---
mask::rw-
other::---

As you can see, the deck user has rw to hidraw devices but only the root user (file owner) has rw to the usb device so it looks like the +=uaccess for the usb devices isn't going through (probably because there is another rule taking precedence)

[kmicki]

After more analysis I think uaccess (ACL) just doesn't work the same as rules for users/groups.

AFAIR I tried to access the device using hidapi but it failed because it was already used by Steam (hence getting data via hiddev*).

I noticed that Steam Link is able to get data from the device simultaneously with Steam so it has to be possible somehow using files that are accessible to deck user by default. It would be great if root access was not necessary for installation.

[streetpea]

I am able to get access using hidapi with hidraw interface without requiring root to install extra udev rules. Here is a link to the place in my project (Chiaki4deck) where I do this: https://github.com/streetpea/chiaki4deck/blob/cfc982a622b592c07eea4a27aacb97a00bc71642/steamdeck_native/src/sdeck.c#L153. I link to hidapi using the hidraw instead of the libusb interface here: https://github.com/streetpea/chiaki4deck/blob/cfc982a622b592c07eea4a27aacb97a00bc71642/steamdeck_native/CMakeLists.txt#L16. If you have any questions lmk.

[kmicki]

@streetpea Thank you. It was very helpful. I will switch to using hidapi-hidraw in the next release. This will bring it closer to creating a Flatpak.

[streetpea]

@kmicki Awesome, if you haven't already made progress on a flatpak build I can test one out for you if you want.

[Lazorne]

I don't know if we can help you or advice you on this.
We have talked a bit to the Vita3K team about building flatpaks as they don't have one either.

But if you want you can join our Discord and we can add you to the 🚧-open-development channel if you are open for discussion.

That goes for the both of you :) @streetpea @kmicki

As we got the biggest manifest on flathub.

//RetroDECK Team