High Level: "controllers" interface discussion

OK so for the Steam snap we require some udev rules to be pushed to the host. After speaking with @jdstrand it makes little sense to have them contained within each snap, soo…

Let’s talk about a controllers interface (name pending :stuck_out_tongue:) which would centralise these important udev rules. Effectively we’d want the “good” rules maintained in snapd, and having a plug in linux-steam-integration to connect to it. This would also come in useful for other games that wanted to take advantage of the steam controller, HTC vive, etc.

Additionally we’d offer a chance for centralising these fixes. Anyone following the news recently would see that Feral Interactive provided some udev rules to the latest SteamOS update to enable certain wheels. Wouldn’t it be altogether awesome if we could have that for all snaps, including LSI? :slight_smile:

Ok markety spiel over, let’s discuss how to do it.

How about we expand the joystick interface for that? I think it makes more sense (who has a joystick nowadays?) than proliferation of distinct interface types. WDYT?

Me xD

But yeah it’s likely the natural place for it.

On irc we discussed the joystick interface. It makes sense to me to put it there as well.

To me the real question is surrounding the udev rules. @ikey mentioned on IRC last week that the steam and Feral controllers need to have udev rules installed on the system in order to function. Of course, snapd has this capability since that is exactly what the modem-manager interface does via UDevPermanentSlot(), but where should the udev rules go? Should they by in UDevPermanentSlot() of the joystick interface and if so, who should slot that, steam? That seems a little awkward because why should steam slots ‘joystick’-- it should plugs ‘joystick’. The problem with the plugs side is that we only want the rules to be on the system once, not once for each snap that plugs joystick.

One thing that might work is we put the udev rules in the slot side of the joystick interface. We then create a ‘game-controllers’ snap that ‘slots: [ joystick ]’ which installs the udev rules. Steam and any other snap ‘plugs: [ joystick ]’ like normal. When the game-controllers snap is not installed, steam/etc gets the current security policy when plugging joystick, and when it is installed, it gets everything it has now plus whatever additional accesses are required to use the devices that the udev rules expose.

@niemeyer and @zyga-snapd: what do you think?

I don’t think that we should not put it on any end-user snap, such as steam.


Let’s imagine a driver snap that is allowed to ship udev rules and (confined) executable programs. You plug in some hardware and snapd hot-plug notices, ask the store, gets the driver snap and you end up with fully functional system but also with nice meta-data (icons, descriptions, etc) and a new ecosystem to fuel this.

Low hanging fruit:

Like with all the udev rules, just ship them in the system via snapd. On core systems that should be the definite way to get things going (core provides the slot, the rule is in place). On classic that’s an open question as the host may have better rules and we just cannot (easily) say.

What do you think?

I like the idea of creating an implicit core interface for this (ie, just update the joystick slot side which should put the rules in place).

@ikey brought this up in the context of Steam on classic distro, so we need to be sure to solve that case. We allow installing slot side snaps on classic now and we don’t worry about conflicting rules (though maybe we should). Perhaps it would be possible to interrogate the system to see if it has rules for the devices. If not, install the rules, if so, don’t.

I agree on everything.

The problem of querying for rules is non-trivial I’m afraid. Unless there’s a scheme where those are somehow discoverable by either talkin to udev or (sigh) parsing udev rules and guessing I’d say this is something we should be wary of.

A cheap hack is to load the udev rules from a blessed snapd directory and shipping those udev rules with the snapd package, i.e. /usr/share/snapd/udev/rules.d/joystick ?

Ha, interesting concept (perhaps not the same as what you described but hear me out):

  • you plug in a usb vendor:product device
  • snapd looks at a host database (classic) where host packaging can say “gee snapd, buzz of, I’ll do this”
  • in absence of an override (which can be a symlink of a form vendor: or vendor:product pointing to /dev/null) snapd will do whatever if finds appropriate.

What does this give us?

  • Snapd can eventually pull in certain class of drivers from the store, automatically
  • There is less feature creep for random devices (EDIT: in snapd core)
  • Classic distributions that want to control something easily can

I like the idea of masking! So for something like LSI snap, would it ship its own udev rules then or would we make that a new snap - given that it has steam controller rules and such.