Idea for joystick support in sandbox/SDL

[Alexander Larsson]

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. 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.

> 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).

> 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. 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.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a suicidal ninja rock star with acid for blood. She's a warm-hearted 
red-headed single mother from beyond the grave. They fight crime!