Idea for joystick support in sandbox/SDL

[Peter Hutterer]

On Mon, Jun 20, 2016 at 11:41:03PM +0200, Bastien Nocera wrote:
> 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 worth noting: the js api doesn't have revoke support like evdev does.
 
> > 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.

correct. For more detail in the archives here, this ioctl is custom-made for
things like logind which want to take away input device access without
relying on the user of the device playing nice. Any further operation after
EVIOCREVOKE gets ENODEV and the process has to re-open the fd. note that
this only works on evdev nodes.

We already use this approach in logind-enabled X servers and in Wayland.

Cheers,
   Peter

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