Idea for joystick support in sandbox/SDL

[Peter Hutterer]

On Tue, Jun 21, 2016 at 09:14:00AM +0200, Alexander Larsson wrote:
> On tis, 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.
> 
> Kinda like a org.freedesktop.MiniUdevWithOpen?

yeah, pretty much. the main question remaining here would be how to
distinguish what application is allowed to open which device, e.g. joystick
vs space navigator vs remote control etc.

Cheers,
   Peter