[RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Stefan Schmidt
s.schmidt at samsung.com
Fri Aug 23 07:46:01 PDT 2013
Hello.
On 08/22/2013 04:07 PM, Jason Ekstrand wrote:
> Stefan,
> Thanks for working on this!
You can thank me once I get this into a state where it gets accepted. ;)
> As one general comment (protocol comments below), we need to make sure
> that "normal" values are somewhere around 1 to 1000. The wl_fixed type
> provides 24 bits of integer and 8 bits of fractional precision. The
> units used below seemed reasonable to me. That said, I'm not 100% sure
> how this relates to the real world so it's worth a check.
We should be fine but I made a node to check on this.
>
> On Thu, Aug 22, 2013 at 4:45 AM, Stefan Schmidt <s.schmidt at samsung.com
> <mailto:s.schmidt at samsung.com>> wrote:
>
> Hello.
>
>
> On 08/22/2013 09:46 AM, Stefan Schmidt wrote:
>
> Treating some specific sensors as input devices. In particular
> adding support for wl_compass, wl_gyroscope and wl_accelerometer
> here.
>
> Using these sensor as input for apps and games. Not covering any
> background apps or services with this protocol.
>
> We have requests to start and stop sensor event receiving as well as
> events to receive the different axis values for these sensors.
>
> V2:
> o Add units to event arguments
> o Define coordinate system
> o Be more verbose on security policy in compositor and add error
> event
>
>
> One thing I'm still missing is a way to handle more than one sensor
> per type for the future. Input devices like the wii-remote with
> nunchuk comes to mind. Having two separate accelerometers which
> still would be a the same seat but could not be aggregated.
>
>
> Yes, this is kind of an issue. There was some work recently on adding
> gamepad support and that faced similar issues. For reference, see
> http://lists.freedesktop.org/archives/wayland-devel/2013-May/009043.html
> and the ~42 replies.
Will go through this when I'm back from vacation. Thanks for pointing it
out.
>
> One option we have been pondering about was adding a simple uid when
> doing the get_compass, etc calls and re-use this uid later in the
> motion events to identify the correct sensor. When the compositor
> adds the various sensors clients would get a event for each and
> could keep track on how many compass sensors there are for example
> and call get_compass accordingly if it is interested in all of them.
>
>
> I don't know that there's any real benifit to having some uid traveling
> along with them rather than just getting multiple protocol objects.
> Protocol objects are cheap and libwayland will sort out the id for you.
> For instance, you could have an event get_compass to which the
> compositor replies with a series of compas events each of which contains
> a new wl_compass instance.
That could fit my needs.
>
> Its a corner case but I want this proposal to at least allow for
> such things in the future.
>
> Anyone having a better/different idea on this?
>
> regards
> Stefan Schmidt
>
> PS: I'm on vacation next week. Will reply to review and comments the
> week after.
>
>
> Signed-off-by: Stefan Schmidt <s.schmidt at samsung.com
> <mailto:s.schmidt at samsung.com>>
> ---
> protocol/wayland.xml | 175
> ++++++++++++++++++++++++++++++__++++++++++++++++++++
> 1 file changed, 175 insertions(+)
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index d7bbbb9..e35413c 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1251,6 +1251,9 @@
> <entry name="pointer" value="1" summary="The seat has
> pointer
> devices"/>
> <entry name="keyboard" value="2" summary="The seat has
> one or more
> keyboards"/>
> <entry name="touch" value="4" summary="The seat has touch
> devices"/>
> + <entry name="compass" value="8" summary="The seat has compass
> devices"/>
> + <entry name="gyroscope" value="16" summary="The seat has
> gyroscope
> devices"/>
> + <entry name="accelerometer" value="32" summary="The seat has
> accelerometer devices"/>
> </enum>
>
> <event name="capabilities">
> @@ -1297,6 +1300,63 @@
>
> <!-- Version 2 of additions -->
>
> + <request name="get_compass" since="2">
> + <description summary="return compass object">
> + The ID provided will be initialized to the wl_compass
> interface
> + for this seat.
> +
> + This request only takes effect if the seat has the compass
> + capability. If the seat has the capability but no object is
> + received it could be that the compositor security
> policy has
> + denied the sensor access for the client. In case of a
> security
> + policy error an error event will be send.
> + </description>
> + <arg name="id" type="new_id" interface="wl_compass"/>
> + </request>
> +
> + <request name="get_gyroscope" since="2">
> + <description summary="return gyroscope object">
> + The ID provided will be initialized to the wl_gyroscope
> interface
> + for this seat.
> +
> + This request only takes effect if the seat has the
> gyroscope
> + capability. If the seat has the capability but no object is
> + received it could be that the compositor security
> policy has
> + denied the sensor access for the client. In case of a
> security
> + policy error an error event will be send.
> + </description>
> + <arg name="id" type="new_id" interface="wl_gyroscope"/>
> + </request>
> +
> + <request name="get_accelerometer" since="2">
> + <description summary="return accelerometer object">
> + The ID provided will be initialized to the wl_accelerometer
> interface
> + for this seat.
> +
> + This request only takes effect if the seat has the
> accelerometer
> + capability. If the seat has the capability but no object is
> + received it could be that the compositor security
> policy has
> + denied the sensor access for the client. In case of a
> security
> + policy error an error event will be send.
> + </description>
> + <arg name="id" type="new_id" interface="wl_accelerometer"/>
> + </request>
> +
> + <event name="error">
> + <description summary="fatal error event">
> + The error event is sent out when a fatal (non-recoverable)
> + error has occurred. The object_id argument is the object
> + where the error occurred, most often in response to a
> request
> + to that object. The code identifies the error and is
> defined
> + by the object interface. As such, each interface
> defines its
> + own set of error codes. The message is an brief description
> + of the error, for (debugging) convenience.
> + </description>
> + <arg name="object_id" type="object"/>
> + <arg name="code" type="uint"/>
> + <arg name="message" type="string"/>
> + </event>
>
>
> I'm confused by what you're intending here with aditional security
> policy. If a client isn't allowed to access a compass, why even
> advertise it? Are you going to advertise it now and then revoke
> priviledges later? How will that work if the client already has access
> to it?
The problem I see is that we might want to decide access on a client
basis. And not only having the compositor to advertise it for all or
none. This might be a implementation detail in the end for the
implementing compositor. Not sure yet. I added the security statements
because people asked about it.
The general idea is to have the compositor decide which clients gets
access. Could be all, some smack rule, based on random PIDs or something
else ;)
While the compositor can decide that it would need to know which clients
wants the access. Thus I kept the get_sensor calls.
> Also, requests don't "return" anything. It only appears that way in the
> case of requests that contain a new_id argument. However, once a new_id
> is sent to the compositor, the object is created and now exists. In
> other words wl_seat_get_compass will *always* return a non-null proxy.
> I suppose the compositor could respond with an error event and destroy
> the object but I'm still not seeing why that's needed. Also, would it
> be better to have a security_error event in wl_compass,
> wl_acceleromiter, etc. than in wl_seat?
It should. It really boils down to how we can advertise this to allow
access on client basis but only deliver a proper object to work on when
the compositor decides its a valid client.
> One more note before I move on. It looks like you copied the error
> event from wl_display and put it here. In the case of wl_display a
> "fatal error" means the compositor cuts its connection to the client
> and, in most cases, the client dies. I don't think that's what you want
> for a "security error".
Good point. Needs to get fixed when we keep this error event.
> +
> <event name="name" since="2">
> <description summary="unique identifier for this seat">
> In a multiseat configuration this can be used by the
> client to
> help
> @@ -1605,6 +1665,121 @@
> </event>
> </interface>
>
> + <interface name="wl_compass" version="2">
> + <description summary="compass sensor device">
> + The wl_compass interface represents a compass
> + associated with a seat.
> + </description>
> +
> + <request name="start">
> + <description summary="Start receiving events">
> + Sent to enable event receiving for the compass sensor.
> + </description>
> + </request>
> +
> + <request name="stop">
> + <description summary="Stop receiving events">
> + Sent to disable event receiving for the compass sensor.
> +
> + It stops event reporting to this client. Other clients
> might still
> + receive events.
> + </description>
> + </request>
> +
> + <event name="motion">
> + <description summary="Motion event coming from the
> compass sensor">
> + Updated sensor data available from compass
> +
> + Measurement of the ambient magnetic field in the X, Y
> and Z axis.
> +
> + Coordinate system (device in portrait mode with screen
> facing
> upwards):
> + X axis goes from the left to the right side of the device
> + Y axis goes from the bottom of the screen to the top
> + Z axis goes from the back of the screen to the front of
> the screen
> + </description>
> + <arg name="x" type="fixed" summary="x-axis in micro Tesla
> (uT)"/>
> + <arg name="y" type="fixed" summary="y-axis in micro Tesla
> (uT)"/>
> + <arg name="z" type="fixed" summary="z-axis in micro Tesla
> (uT)"/>
> + </event>
> + </interface>
>
>
> Um... How do I know that the device *has* a "portrait mode" and does
> portrait mode make sense? This seems to implicitly imply phone/tablet.
I was pondering over this for a while. Call it normal mode of operation?
What would be the way to describe it on a laptop or even a desktop system?
The definition of a generic way to describe the coordinate system for
all type of devices gives me a headache. Not even thinking about not yet
invented devices. :)
> Also, assuming you have a portrait mode, is that a reasonable default?
> Say, for example, that someone wants to make a simple compass app. How
> do they make sure it's pointing in the right direction. If they just
> blindly draw in x and y they may get messed up by the default of the
> compositor being landscape. How do we deal with this?
>
> I think part of the problem here is that a compass seems to be tied ti a
> particular display or wl_output. If this is the case, we should
> explicitly correlate the two so that the geometry transform from the
> corresponding output can be used to figure out the coordinate system.
> Otherwise, I don't see how a wl_compass can be meaningful.
Lorn already wrote that it might should renamed to magnetometer or such
as a "compass sensor" would need to aggregate its information from
different things.
This also reveals a problem with the current proposal. Where to put the
abstraction and what level would be right on a wayland protocol level. I
have no definitive answer to that yet.
regards
Stefan Schmidt
More information about the wayland-devel
mailing list