Idea for joystick support in sandbox/SDL

[Jonas Ådahl]

On Wed, Jun 22, 2016 at 12:04:12PM +0200, Bastien Nocera wrote:
> On Tue, 2016-06-21 at 17:06 +0200, Alexander Larsson wrote:
> > On tis, 2016-06-21 at 11:45 +0200, Bastien Nocera wrote:
> > >  
> > > I agree that the API could possibly be tweaked to be slightly more
> > > generic to accommodate other types of devices (remove the
> > > "Joystick"
> > > from the method and signals, but turning it into a udev replacement
> > > is
> > > really not possible without dropping a lot of the functionality
> > > we'd
> > > want from this service.
> > 
> > I'm pretty sure we don't want to implement this *in* the compositor.
> > But having some support in the compositor for it might be nice.
> 
> Right, we'll need some help from the compositor.
> 
> >  The way
> > that the dbus filtering works in flatpak is that if you're allowed to
> > talk to a dbus well known name, you're also allowed to talk to the
> > unique client name (because many dbus users do that). This behaviour
> > is
> > shared with kdbus, and means each portal needs to be extremely
> > careful
> > about *any* input on *any* interface.
> 
> Fair enough. I'll need to split up the gnome-settings-daemon helpers
> soon then, as I allow games to talk to the screensaver fd.o API, which
> is currently implemented in gnome-settings-daemon.
> 
> > > org.freedesktop.Portal.Input
> > 
> > We generally lowercase portal: org.freedesktop.portal.Input
> > 
> > > - Method:
> > > ao ListDevices()
> > > 
> > > - Signals
> > > DeviceAdded(o objectpath, a{sv} Properties)
> > > DeviceRemoved(o)
> > 
> > If the notification has poperties, then ListDevices should maybe also
> > have that? (i.e. you combine list + signals to get an in-process up-
> > to-
> > date list).
> 
> Or no properties for either. Not sure what's best.
> 
> > > And on the object path for each joystick:
> > > - Method:
> > > fd OpenDevice()
> > > 
> > > Signal:
> > > DeviceRemoved()
> > > 
> > > Properties:
> > > s DeviceType (joystick, or wheel)
> > > as HapticsFeatures (empty if not applicable)
> > > 
> > > We would extend the properties, and the possible "DeviceType"
> > > values
> > > when we add specific support (eg. accelerometer support when we get
> > > to
> > > that).
> > > 
> > > Better?
> > 
> > One issue i have with this is the "portal" aspect.
> 
> OK. I'm not too attached to the D-Bus name, can you think of a better
> one?
> 
> >  The general theory
> > is that portals are "safe" to expose to any sandboxed app, because
> > every operation either trigger a user interface that the user is in
> > control of (and can cancel if its not expected), or the API does per-
> > app access control on each access.
> > 
> > In this case the API doesn't naturally lend itself to show a user
> > interface, which means that it should instead track per-app access to
> > various types (storing this in the flatpak permissions store
> > probably).
> > However, that means that you have to have an external tool/dialog to
> > assign permissions. We should maybe add an API call that is more
> > naturally async and can be used to show a dialog. 
> > 
> > For instance, we could add a RequestAccess(string DeviceType) call.
> 
> My idea was to avoid the access request completely, and always have the
> currently focused application be allowed to use input devices.
> 
> But I'll need a way to get the currently focused application/sandbox
> from the compositor, to offer and revoke the devices to the
> application.

I suppose it could be tied together with the application ID, i.e. if
application ID "x.y.Z" is "active" (the "active" state in xdg_shell,
"appears focused" in mutter, not sure what in X), it'll give access to
the user of this API with the same application id.

Should we consider multi seat? With multi seat, there may be more than
one "active"/"focused" applications at a time, and a
joystick/gamepad/... should probably be associated with a given seat.
Otherwise we'll (in the futur when we support multi seat properly) end
up with hacks making wild arbitrary guesses of what seat should be
considered the "driving" seat. This means we need the seat association
to be part of the API as well.

Using application ID's will tie this protocol to xdg_shell on Wayland
(and the "correct" usage of WM_CLASS in X11), but I guess that is fine.
The other option would be to make it a Wayland protocol, which would
work more naturally with things being "focused" etc, but it'd mean
mutter would need to be the one implementing this and that I suppose is
a bit annoying. And the fact that we'd need per display protocol code on
each side for that matter (not that I'm sure we need to care about
sandboxing + X11 though).

Assuming the D-Bus API is to be implemented outside of mutter, while at
the same time depending on a "focus state", how is this state supposed
to be shared with that service? Another D-Bus API broadcasting focused
application ID or something? Is the Flatpak daemon managing access to
joysticks going to be a GNOME daemon or does it need an org.freedesktop.
API?


Jonas

> 
> Cheers