[RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Jason Ekstrand
jason at jlekstrand.net
Thu Aug 22 08:07:15 PDT 2013
Stefan,
Thanks for working on this!
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.
On Thu, Aug 22, 2013 at 4:45 AM, Stefan Schmidt <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.htmland
the ~42 replies.
>
> 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.
>
> 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>
>> ---
>> 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?
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?
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".
> +
>> <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.
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.
> +
>> + <interface name="wl_gyroscope" version="2">
>> + <description summary="gyroscope sensor device">
>> + The wl_gyroscope interface represents a gyroscope
>> + associated with a seat.
>> + </description>
>> +
>> + <request name="start">
>> + <description summary="Start receiving events">
>> + Sent to enable event receiving for the gyroscope sensor.
>> + </description>
>> + </request>
>> +
>> + <request name="stop">
>> + <description summary="Stop receiving events">
>> + Sent to disable event receiving for the gyroscope 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 gyroscope
>> sensor">
>> + Updated sensor data available from gyroscope
>> +
>> + Measurement of the rate of rotation around X, Y and Z axis in
>> degree per second.
>> + Values are observed in positive notation in the counter-clockwise
>> direction.
>> +
>> + Coordinate system (device in portrait mode with screen facing
>> upwards):
>> + X axis goes from the left to the right side of the device (Pitch)
>> + Y axis goes from the bottom of the screen to the top (Roll)
>> + Z axis goes from the back of the screen to the front of the screen
>> (Azimuth/Yaw)
>> + </description>
>> + <arg name="x" type="fixed" summary="x-axis in degree per second"/>
>> + <arg name="y" type="fixed" summary="y-axis in degree per second"/>
>> + <arg name="z" type="fixed" summary="z-axis in degree per second"/>
>> + </event>
>> + </interface>
>>
>
Same coordinate space issues as above.
I'm not particularly familiar with gyroscopes so maybe this isn't an issue,
but what order are you applying your rotations? When defining a rotational
position there are 3 matrices that you can multiply in 6 different ways and
each one yields different results. Is this not the case with rotational
velocity or do we need to be more specific?
> +
>> + <interface name="wl_accelerometer" version="2">
>> + <description summary="accelerometer sensor device">
>> + The wl_accelerometer interface represents a accelerometer
>> + associated with a seat.
>> + </description>
>> +
>> + <request name="start">
>> + <description summary="Start receiving events">
>> + Sent to enable event receiving for the accelerometer sensor.
>> + </description>
>> + </request>
>> +
>> + <request name="stop">
>> + <description summary="Stop receiving events">
>> + Sent to disable event receiving for the accelerometer 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 accelerometer
>> sensor">
>> + Updated sensor data available from accelerometer
>> +
>> + Measurement of the acceleration of G on the axis in m/s^2.
>> +
>> + 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 G in m/s^2"/>
>> + <arg name="y" type="fixed" summary="y-axis G in m/s^2"/>
>> + <arg name="z" type="fixed" summary="z-axis G in m/s^2"/>
>> + </event>
>> + </interface>
>> +
>> <interface name="wl_output" version="2">
>> <description summary="compositor output region">
>> An output describes part of the compositor geometry. The
>>
>>
> ______________________________**_________________
> wayland-devel mailing list
> wayland-devel at lists.**freedesktop.org<wayland-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/wayland-devel<http://lists.freedesktop.org/mailman/listinfo/wayland-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130822/840e0cb2/attachment-0001.html>
More information about the wayland-devel
mailing list