Idea for joystick support in sandbox/SDL

[Jasper St. Pierre]

It seems like a shame to me if apps can't use udev from inside a
flatpak. Is there really no hope of stabilizing that API/ABI?

On Mon, Jun 20, 2016 at 2:41 PM, Bastien Nocera <hadess at hadess.net> 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, 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.
> _______________________________________________
> xdg-app mailing list
> xdg-app at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg-app



-- 
  Jasper