Idea for joystick support in sandbox/SDL

[Alexander Larsson]

On ons, 2016-06-22 at 12:04 +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 guess that is safe for input, or anything that has a revoke()
implementation really. Makes sense.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a notorious sweet-toothed jungle king possessed of the uncanny 
powers of an insect. She's a warm-hearted mute snake charmer from Mars. 
They fight crime!