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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>>
---
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
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
