[RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.

[Stefan Schmidt]

Hello.

On 08/22/2013 10:43 PM, Lorn Potter wrote:
> Hi,
> I was told of this thread, perhaps I can make a few comments (sorry if it
> doesn't really follow the thread)
> [no knowing much about wayland protocol/api]
>
> first thoughts:
>
> * why no timestamp info?

Arg, that is sitting uncommitted here and thus not made it into the 
patch. Each event now has
<arg name="time" type="uint" summary="Timestamp with millisecond 
granularity"/>

> * why no rate info? (not all apps need/want the same speed)

That was requested before. I left it out initially for a) simply the 
first proposal and b) not being sure all sensor subsystems offer this.

As you did qtsensor maybe you can shed some light on this. What systems 
does qtsensor support and do all of them offer rate?

> * a magnetometer is not a compass, nor does it describe motion.
>    - it seems your 'compass' is really just a magnetometer. A compass
> entails a sensor fusion of sorts to return heading information in degrees.
> It uses a magnetometer (calibrated - which mostly means hard and soft iron
> distortions removed), accelerometer (smoothed for jitter - used for
> 'leveling' the mag readings), and declination information from somewhere
> (mostly gps or a location lookup table).
> Compass could return magnetic north, true north in degrees from the y axis
> of the device.

Agreed, compass is more than just the ambient magnetic field reading so 
this should be renamed.

> Most importantly, what is the justification for sending sensor data
> through wayland?

Because of requests I heard allow clients like games to use some type of 
sensor as user input. We did not include the other sensors for exactly 
this reason. They are still available through a subsytsem on whatever 
platform you run.

For the sensors that reflect user input in terms of moving the device 
people asked for getting these through the wayland protocol. I'm not 
expecting this to be the best solution for every app but they still can 
get their informations from the subsystem.

> Another thing to consider is you might want to handle axis' rotation when
> the device is rotated.

Indeed.

> Other devices you might consider is like the leapmotion sensor.

Interesting type. But unlikely that I would work on something like this 
without actually having access for testing it. So I will concentrate on 
the things I have.

regards
Stefan Schmidt