Idea for joystick support in sandbox/SDL

[Bastien Nocera]

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?

> > 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?