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

[Lorn Potter]

sorry took so long. forgot to hit send...


On 24/08/2013, at 1:04 AM, Stefan Schmidt <s.schmidt at samsung.com> wrote:

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

QtSensors supports different rates, if two processes request different rates, the hardware runs at fastest rate, and is downsampled for slower.
Some sensors only fire off if an event is triggered (proximity).
As well, not all hardware support the same rates. Some support a range of rates, some support only certain rates.

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

Lorn Potter
QtSensors/QtSensorGestures/QtSystemInfo
llornkcor technologies / Jolla Mobile