Support for Automatic udev Rules Installation and Kernel Module Management Inside Flatpak

[first-storm]

Description

After packaging as a Flatpak, the tasks of setting up udev rules and blacklisting kernel modules have to be done manually. To make OpenTabletDriver more user-friendly, I propose that if the software detects it's running inside Flatpak, it should offer a diagnostic feature and run it on the first launch. I'm not familiar with C#, so I apologize for not being able to offer substantial help. Below is the pseudocode I generated with ChatGPT, which might be of assistance.

// Check if running inside Flatpak
If FLATPAK_ID exists Then
    Print "Running inside Flatpak. Proceeding with flatpak-spawn..."
    Initialize AUTH_TOOL as empty

    // Determine authorization tool to use (pkexec or kdesudo)
    If command exists on host ("pkexec") using flatpak-spawn Then
        Set AUTH_TOOL to "pkexec"
    Else If command exists on host ("kdesudo") using flatpak-spawn Then
        Set AUTH_TOOL to "kdesudo"
    Else
        Print "Neither pkexec nor kdesudo is available on the host."
        Exit with error
    End If

    // Check for existence of the udev rule
    If file "/etc/udev/rules.d/99-otd.rules" exists on host using flatpak-spawn Then
        Print "udev rule 99-otd.rules already exists."
        Exit with success
    Else
        // Write the udev rule and reload udev
        Print "Writing udev rule and reloading udev..."
        
        // Actual udev rule should replace the placeholder text below
        Using flatpak-spawn with AUTH_TOOL, write "SUBSYSTEM=='usb', ATTR{idVendor}=='****', ATTR{idProduct}=='****', MODE='0666'" to "/etc/udev/rules.d/99-otd.rules" on the host
        
        // Reload udev rules and trigger
        Using flatpak-spawn with AUTH_TOOL, execute "udevadm control --reload-rules && udevadm trigger" on the host
        Print "udev rules reloaded."
    End If
Else
    Print "Not running inside Flatpak."
End If

// Check if the script is running inside Flatpak
If FLATPAK_ID exists Then
    Print "Running inside Flatpak. Proceeding with flatpak-spawn to check kernel modules..."
    
    // Array of kernel modules to check
    kernelModules = ["wacom", "hid_uclogic"]
    loadedModules = []
    
    // Check each kernel module to see if it's loaded
    For each module in kernelModules Do
        If flatpak-spawn --host lsmod | grep module Then
            Add module to loadedModules
        End If
    Done
    
    // If any modules are loaded, proceed to unload and blacklist them
    If loadedModules is not empty Then
        For each module in loadedModules Do
            // Unload the module
            flatpak-spawn --host modprobe -r module
            
            // Add module to blacklist
            echo "blacklist module" | flatpak-spawn --host tee -a /etc/modprobe.d/blacklist-custom.conf
        Done
        
        // Determine which tool is available for regenerating initramfs
        If flatpak-spawn --host command -v update-initramfs Then
            initramfsTool = "update-initramfs"
        Else If flatpak-spawn --host command -v dracut Then
            initramfsTool = "dracut"
        Else
            Print "No known initramfs tool found."
            Exit with error
        End If
        
        // Regenerate initramfs
        flatpak-spawn --host initramfsTool -u
        
        Print "initramfs regenerated successfully."
    Else
        Print "No specified modules are loaded. No actions needed."
    End If
Else
    Print "Script is not running inside Flatpak."
End If

Although this method requires the permission --talk-name=org.freedesktop.Flatpak, I believe it's feasible, as demonstrated by the successful case of https://github.com/flathub/com.leinardi.gst. For testing software, Flatpak offers parameters to temporarily toggle permissions. Here's a reference issue for more information: flatpak/flatpak#5435.

Acknowledgements

• I have searched the existing issues and this new issue is not a duplicate of any.
• I have written a concise and meaningful title.
• I am on the latest version of OpenTabletDriver.

[gonX]

As alluded to in the original Flatpak request by @X9VoiD, this is the blocker for why Flatpak hasn't been implemented yet:

I don't think this is feasible to make it work out-of-the-box since afaik flatpak still does not have proper support for apps that require setup of some udev rules.

I see many reasons to want to fix this (including proper tablet permissions support for osu!lazer), but given OpenTabletDriver is a userspace program with plugin support (allowing for arbitrary code execution), any type of permission that requires elevation is not ideal.

While I can't speak on our developers behalf, I would really prefer that this is better handled in Flatpak, since device access is not entirely within scope of the project. We generally try to keep any platform-specific code to a minimum in the project where it's possible.

What I'm trying to say is that if a change like this were to be implemented, I think it would be wise to instead apply these concepts as widely as possible (ie. the checks should run on Linux generally, not just Flatpak). We already warn on default drivers being loaded, so any improvements to that is welcome.

However, copying a file to a (mostly) system folder (/etc) will leave the system in a surprising state when the Flatpak is uninstalled. I would really like to avoid this approach. Instead, the package manager should handle this, or Flatpak should have better support for direct device access.

The best compromise I can come up with is a separately shipped system package that includes udev rules and/or the module blacklist files. Shipping udev rules would definitely allow us to solve the osu!lazer issue. Seeing what other direct-access Flatpak (any other driver, really, including Steam) does should be worthwhile.

Sorry if this isn't the response you were hoping for. But as mentioned, solving this is necessary for the Flatpak package to be submitted, hence why nobody had submitted a Flatpak package before now.

[first-storm]

As alluded to in the original Flatpak request by @X9VoiD, this is the blocker for why Flatpak hasn't been implemented yet:

I don't think this is feasible to make it work out-of-the-box since afaik flatpak still does not have proper support for apps that require setup of some udev rules.

I see many reasons to want to fix this (including proper tablet permissions support for osu!lazer), but given OpenTabletDriver is a userspace program with plugin support (allowing for arbitrary code execution), any type of permission that requires elevation is not ideal.

While I can't speak on our developers behalf, I would really prefer that this is better handled in Flatpak, since device access is not entirely within scope of the project. We generally try to keep any platform-specific code to a minimum in the project where it's possible.

What I'm trying to say is that if a change like this were to be implemented, I think it would be wise to instead apply these concepts as widely as possible (ie. the checks should run on Linux generally, not just Flatpak). We already warn on default drivers being loaded, so any improvements to that is welcome.

However, copying a file to a (mostly) system folder (/etc) will leave the system in a surprising state when the Flatpak is uninstalled. I would really like to avoid this approach. Instead, the package manager should handle this, or Flatpak should have better support for direct device access.

The best compromise I can come up with is a separately shipped system package that includes udev rules and/or the module blacklist files. Shipping udev rules would definitely allow us to solve the osu!lazer issue. Seeing what other direct-access Flatpak (any other driver, really, including Steam) does should be worthwhile.

Sorry if this isn't the response you were hoping for. But as mentioned, solving this is necessary for the Flatpak package to be submitted, hence why nobody had submitted a Flatpak package before now.

I have already submitted a package to Flathub. Indeed, as you mentioned, this does cause issues when the Flatpak package is uninstalled. That's why I believe this action should be included in the setup wizard or as a feature. We need to make sure the user is aware they have performed this operation. Additionally, I think there should be a feature within the software to reverse this change. You suggested that this check should not be limited to Flatpak. However, if the installation is not done via Flatpak, actions like blacklisting kernel modules are automatically handled by the package manager, making such manual operations unnecessary.

[first-storm]

flathub/flathub#5082

[first-storm]

Or at least, when access to the device is blocked and the software is running under Flatpak, inform the user about what the problem is and the corresponding solutions, because this is a widespread issue rather than an isolated case. Automatically informing the user about what happened would greatly improve usability.

[X9VoiD]

A separate system package is best to provide the rules and the blacklist. That also takes care of if the system is FHS or non-FHS compliant. On the UI side, it should tell and guide users (to the website, or built-in troubleshooting) when the system is in an unexpected state for OpenTabletDriver to run normally.

[first-storm]

A separate system package is best to provide the rules and the blacklist. That also takes care of if the system is FHS or non-FHS compliant. On the UI side, it should tell and guide users (to the website, or built-in troubleshooting) when the system is in an unexpected state for OpenTabletDriver to run normally.

This is also a viable solution, identifying the issue and offering a URL that outlines a resolution method. However, if providing a system package, it might be more efficient to install OpenTabletDriver directly through the system package manager. Thus, it may be beneficial to present a webpage guiding users on manually installing udev rules and blacklisting kernel modules upon detecting the problem, or alternatively, offering a script for automatic installation.

[Beryesa]

Wouldn't just the flatpak-spawn --host modprobe -r ... part be enough, without the blacklisting
So when OTD runs, unload other drivers but when it exits, reload the kernelModules= back, eventually making sure some driver is always loaded.
Instead of leaving the user in confusion and/or placing permanent files on the system.

-> Reminder for --talk-name=org.freedesktop.Flatpak

[first-storm]

Wouldn't just the flatpak-spawn --host modprobe -r ... part be enough, without the blacklisting
So when OTD runs, unload other drivers but when it exits, reload the kernelModules= back, eventually making sure some driver is always loaded.
Instead of leaving the user in confusion and/or placing permanent files on the system.

-> Reminder for --talk-name=org.freedesktop.Flatpak

good idea