Idea for joystick support in sandbox/SDL

[Bastien Nocera]

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.

Cheers