Idea for joystick support in sandbox/SDL

Peter Hutterer peter.hutterer at who-t.net
Tue Jun 21 00:40:02 UTC 2016


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.

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?



More information about the xdg-app mailing list