Idea for joystick support in sandbox/SDL

[Bastien Nocera]

On Mon, 2016-06-20 at 22:16 +0200, Alexander Larsson wrote:
> On mån, 2016-06-20 at 17:39 +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]
> 
> The way I understand thing there are two kinds of joystick devices,
> some supporting the "old" jsN API, and some supporting a more modern
> generic input device API. Is that true, and if so, which fd:s are
> these?

It is true, but the "new" API is around 17 years old, and the "old" API
is usually disabled (the module for it is in kernel-modules-extra in
Fedora IIRC, not installed on my machine).

In short, we don't care about the old API.

> Also, one option we considered at the hackfest was to create a fuse
> filesystem with files in them that "look like" device nodes (but are
> regular files). Operations on these then cause the same operation on
> the backing device node. That way you can emulate the ABI and run
> games
> unchanged. On the other hand, that adds a context switch to every js
> operation, which is not ideal. And also, forwarding ioctls needs
> device-type specific code.

And that won't make SDL or other apps support hotplugging, which would
be a deal-breaker for me.

> > 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.
> 
> Do we support revoke for this?

Look in the kernel log for:

commit c7dc65737c9a607d3e6f8478659876074ad129b8
Author: David Herrmann <dh.herrmann at gmail.com>
Date:   Sat Sep 7 12:23:05 2013 -0700

    Input: evdev - add EVIOCREVOKE ioctl

Reading the commit log, it seems to me it was exactly made for this
purpose.

>  Also, how would we track focus?

If the service is implemented in the compositor, is the window <->
sandbox association going to be difficult to implement?

> > Is this doable? Is this good API?
> 
> Probably doable, except maybe revoke.
> 
> > [2]: As used in src/haptic/linux/SDL_syshaptic.c in SDL. Maybe a
> > string
> > list might be better, or a bitmask?
> 
> array of strings is the more dbus/extensible thing to do.

Noted.