Skip to content

Using udev rules #200

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Anti-Ultimate opened this issue Mar 15, 2017 · 5 comments
Open

Using udev rules #200

Anti-Ultimate opened this issue Mar 15, 2017 · 5 comments

Comments

@Anti-Ultimate
Copy link

The Dolphin Emulator AppImage needs a udev rule to access the GC - Adapter.
I was also creating a Steam AppImage, and Steam needs udev rules to access the Steam Controller, HTC Vive, and several other devices.

@probonopd
Copy link
Member

Hi @Anti-Ultimate how is this related to AppImage? Remember, AppImage is just a self-mounting filesystem that executes whatever payload you put in there.

@Anti-Ultimate
Copy link
Author

Because some Applications require udev access for specific devices, e.g. Dolphin needs udev access for GC - Adapter and controllers in general (in their case it works far better than SDL2). It installed a udev rule, and now the application/the user can access said device.

If a package is installed onto the system, the corresponding udev rules gets put in /usr/lib/udev/rules.d, which gets loaded during install.

However, AppImages are generally executed without root access, so udev rules cannot be loaded. AppRun could be extended so it searches for udev rules in the AppImage and asks the user (via Zenity or whatever), if he wants to enable them.

@probonopd
Copy link
Member

In this case it is up to the payload application (or a custom AppRun script) to acquire administrative rights, and copy the needed files to /usr/lib/udev/rules.d. AppImage is really just a self-mounting container format, all the logic lives inside the AppImage - it is what you put inside.

@probonopd
Copy link
Member

The Etcher AppImage, for example, also acquires administrative rights to write to /dev/sdX.

@probonopd
Copy link
Member

I've spelled out a possible approach here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants