Idea for joystick support in sandbox/SDL

[Peter Hutterer]

On Tue, Jun 21, 2016 at 11:45:02AM +0200, Bastien Nocera wrote:
> On Tue, 2016-06-21 at 10:40 +1000, Peter Hutterer wrote:
> > On Mon, Jun 20, 2016 at 05:39:25PM +0200, Bastien Nocera wrote:
> > > Hey,
> > > 
> > > I've been looking at how we can support joysticks in flatpak,
> > > inside
> > > the sandbox[1]. As udev's API is a private/system API, and not one
> > > stable enough for sandboxed applications to use, and the fact that
> > > even
> > > though they're input devices their events don't go through the
> > > compositor itself, we need to find a way to enumerate joysticks,
> > > signal
> > > additions and removals, and proxy opening them.
> > > 
> > > My idea was for the compositor offering this D-Bus API:
> > > 
> > > - Method:
> > > ao ListJoysticks()
> > > 
> > > - Signals
> > > JoystickAdded(o)
> > > JoystickRemoved(o)
> > > 
> > > And on the object path for each joystick:
> > > 
> > > - Method:
> > > fd OpenJoystick()
> > > 
> > > Signal:
> > > JoystickRemoved()
> > > 
> > > Properties:
> > > s HapticsFeatures [2]
> > > 
> > > To avoid one application taking the joystick and doing things with
> > > it
> > > (rumble to death?), we'd revoke the fd given to an application when
> > > the
> > > application loses focus.
> > > 
> > > Is this doable? Is this good API?
> > 
> > Aside from the HapticsFeatures this is a generic API that could be used for
> > other devices too, not just joysticks. So I'm wondering if it makes sense to
> > push the haptics detection to the client and make this a generic API for
> > direct device access. The Space Navigator device comes to mind here.
> 
> Extending the API to other input devices that need direct device node
> access seems like a good idea to me, and easily done with another
> property tagging the device as a joystick or "something else", but
> making this a completely generic API is a very bad idea:
> - you'd need a way to differentiate the different types of devices
> - you'd need a different policy to other device types (you don't want
> to yank a DVB adapter from a video player when it loses focus)
> - you might not have revoke support for that device type
> - you probably wouldn't want to implement the D-Bus service in the
> compositor for other device types
> 
> I agree that the API could possibly be tweaked to be slightly more
> generic to accommodate other types of devices (remove the "Joystick"
> from the method and signals, but turning it into a udev replacement is
> really not possible without dropping a lot of the functionality we'd
> want from this service.
> 
> org.freedesktop.Portal.Input
> - Method:
> ao ListDevices()
> 
> - Signals
> DeviceAdded(o objectpath, a{sv} Properties)
> DeviceRemoved(o)
> 
> And on the object path for each joystick:
> - Method:
> fd OpenDevice()
> 
> Signal:
> DeviceRemoved()
> 
> Properties:
> s DeviceType (joystick, or wheel)
> as HapticsFeatures (empty if not applicable)
> 
> We would extend the properties, and the possible "DeviceType" values
> when we add specific support (eg. accelerometer support when we get to
> that).
> 
> Better?

yep, that's pretty much what I had in mind, thanks.

I wonder if the device type should be a string array though, in the past
we've always run into the issue of at least one device needing multiple
types depending on context.

Cheers,
   Peter

> 
> > > I'd be happy working on the client-side implementation for SDL2 at
> > > least. I'll try to see whether support for SDL1 is necessary (might
> > > only be necessary for *ancient* proprietary games, like the old
> > > Loki
> > > games).
> > > 
> > > Cheers
> > > 
> > > [1]: https://github.com/flatpak/flatpak/issues/7
> > > [2]: As used in src/haptic/linux/SDL_syshaptic.c in SDL. Maybe a
> > > string
> > > list might be better, or a bitmask?