Include udev/devd rules in Linux/FreeBSD packages using `make install`

[VannTen]

This bundle the udev / devd config files described in the rpcs3 wiki as part of the rpcs3 install on Linux and FreeBSD. Packagers using make install will end up with the udev rules in '/lib/udev/rules.d', which will cause (on most Linux distributions, which include install hooks for reloading new rules in /usr/lib/udev/rules.d) a reload of the udev rules on rpcs3 install.

The idea is to have out of the box support rather than needing manual action.

How to test this PR

[kd-11]

At the very least these new files should not live in the rpcs3 code folder. Maybe add a config/udev folder to the repo root and add them there. No idea if that will be fine with cmake pathing.

[VannTen]

Why not ? I mean, I put them here because I see that's where the RPCS3 desktop file is, which fulfill a similar purpose (integration with platform standard systems)

[Megamouse]

Because it's bloating the main directory with stuff that is very specific to the build process and irrelevant for windows users for example

[kd-11]

Btw how does this work without root access?

[kd-11]

The more I think about this the less it seems useful. The udev rules need to go into the system udev folder, not the rpcs3 install dir, or even the lib folder. By default there is no udev folder in the system lib path on linux at least for example. Distros like arch have an AUR package to work around this issue, it's simply not something we can safely do during make install.

[MSuih]

I don't think make install does anything on rpcs3 anyways, so nobody's going to run it.

We have appimages for most distros and rpcs3-git on aur for those who want to self compile. Building rpcs3 manually is something that only developers should have to do, and at that point they should know how to add udev rules (or at least know where to ask about it)

[VannTen]

I don't think make install does anything on rpcs3 anyways, so nobody's going to run it.

We have appimages for most distros and rpcs3-git on aur for those who want to self compile

The rpcs3-git PKGBUILD does use make install, and I expect anyone which would like to package rpcs3 would ?

The udev rules need to go into the system udev folder, not the rpcs3 install dir, or even the lib folder. By default there is no udev folder in the system lib path on linux at least for example.

I'm not sure I follow. The system udev folder would usually be /usr/lib/udev/rules.d (assuming a fairly standard setup with PREFIX=/usr) and instead I misunderstood something in Cmake doc (quite possible, I'm not very familiar with the tool), CMAKE_INSTALL_LIBDIR would resolve to /usr/lib in that case ?

Btw how does this work without root access?

If you mean does this work when installing without root access, no it does not, since udev config needs to be done by root. (I don't know about devd on FreeBSD)

Because it's bloating the main directory with stuff that is very specific to the build process and irrelevant for windows users for example

Well, since the block above in the CmakeList file is specific to Unix systems (desktop files and icons) so equally irrelevant to Windows build, it did not seem shocking ^^. Anyway, I don't have a problems putting this elsewhere, but where would be an acceptable location ?

[kd-11]

I'm not sure I follow. The system udev folder would usually be /usr/lib/udev/rules.d (assuming a fairly standard setup with PREFIX=/usr)

1. This folder doesn't exist by default. Default system rules are usually in /etc, at least they are on both my PCs.
2. On debian-based the libdir points to /lib/x86_64-linux-gnu

If you mean does this work when installing without root access, no it does not, since udev config needs to be done by root.

Are we really expecting users to run make install as root and installing to the system core? Normally a custom prefix like /opt is used or something in /home for security reasons as well as the fact that immutable filesystems are more common now. I'm still not convinced by the utility of this addition to cmake. We may need to do better about the udev rules, but this approach isn't solving anything. I suppose it doesn't hurt to keep the files in the repo for documentation purposes though.

but where would be an acceptable location ?

/config/udev/...

[RipleyTom]

In general I don't think rpcs3 should affect system configuration, which udev fundamentally is.

Also as it is, the rules will only work after a system reboot or the user reload the rules manually.

[VannTen]

I'm not sure I follow. The system udev folder would usually be /usr/lib/udev/rules.d (assuming a fairly standard setup with PREFIX=/usr)

1. This folder doesn't exist by default. Default system rules are usually in /etc, at least they are on both my PCs.

I think it would exist on all systemd-based distributions, I'm not sure about other udev implementations. What's your system, for curiosity's sake ? (I get this from the udev man page specifically:

Rules files

The udev rules are read from the files located in the default rules directory /lib/udev/rules.d/, the custom rules directory /etc/udev/rules.d/ and the temporary rules directory /dev/.udev/rules.d/. All rule files are sorted and processed in lexical order, regardless in which of these directories they live.

2. On debian-based the libdir points to /lib/x86_64-linux-gnu

ACK, so this should probably be more something like lib/udev/rules.d, if I understood correctly, the install prefix will automatically be prepended.

If you mean does this work when installing without root access, no it does not, since udev config needs to be done by root.

Are we really expecting users to run make install as root and installing to the system core?

No. I should have make that clearer, but this is really more intended for packagers (traditional Linux packages rather than directly for users. I've edited the description to clarify this

Normally a custom prefix like /opt is used or something in /home for security reasons as well as the fact that immutable filesystems are more common now. I'm still not convinced by the utility of this addition to cmake. We may need to do better about the udev rules, but this approach isn't solving anything. I suppose it doesn't hurt to keep the files in the repo for documentation purposes though.

The first approach I considered was instead sending a patch for the rpcs3-git AUR packages. However, I decided against it because this approach has the benefits of working for other packages (at least on systemd-based distro) which don't have to duplicate the patch. If you consider preferable though I would do that, after all that's how I use rpcs3 ^.

but where would be an acceptable location ?

/config/udev/...

:+1:

Also as it is, the rules will only work after a system reboot or the user reload the rules manually.

Linux distros usually have an install hook for reloading udev rules in /usr/lib/udev/rules.d For instance Archlinux :

[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Operation = Remove
Target = usr/lib/udev/rules.d/*

[Action]
Description = Reloading device manager configuration...
When = PostTransaction
Exec = /usr/share/libalpm/scripts/systemd-hook udev-reload

---

Other alternatives :

• recommending install of https://github.com/ValveSoftware/steam-devices to users
• making it an optional dep of the AUR packages
• wait for systemd/systemd#22681

[kd-11]

I think it would exist on all systemd-based distributions

I double-checked, you're right. I was checking the cmake lib directory (/lib/x86_64-linux-gnu) which doesn't have the udev folder.

As for the installation concerns, we can put that behind a switch for peace of mind. Something like "INSTALL_UDEV_RULES" or something that defaults to "OFF" so that the user has to request it explicitly. This way it's available to package maintainers without the risk to general tinkerers trying out linux for example.

[RipleyTom]

Someone on discord pointed out that there is already a package on the AUR for this: https://aur.archlinux.org/packages/rpcs3-udev

[VannTen]

Yes, there is.

However, it's limited to Arch and the users need to know about it. Granted, that's not a lot to ask.

[linuxkernel94]

This guy from Steam is trying to upstream the udev rules to systemd: https://github.com/systemd/systemd/issues/22681

[this-is-just-con-tribute]

why do we need these rules at all? why can't it just support controllers out of the box like games can?

[VannTen]

I addressed the comments regarding a switch (default off) and the location of the files.

(Sorry for the long time, this kinda fell off my radar :sweat_smile: )