setting QAccelerometer rate has no effect
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
platform-api |
New
|
Undecided
|
Unassigned | ||
qtubuntu-sensors |
New
|
Undecided
|
Unassigned |
Bug Description
First example here tries to set it to 100 Hz, second to 5Hz
(the timestamp issue may effect this issue)
phablet@
(check:
(main:134) - choosing "core.accelerom
Acceleration: -1.6 x 6.3 y 7.5 z m/s^21414975702
Acceleration: -1.6 x 6.4 y 7.5 z m/s^21414975702
Acceleration: -1.5 x 6.3 y 7.5 z m/s^21414975702
Acceleration: -1.6 x 6.4 y 7.5 z m/s^21414975702
Acceleration: -1.6 x 6.4 y 7.5 z m/s^21414975702
Acceleration: -1.6 x 6.3 y 7.5 z m/s^21414975702
phablet@
(check:
(main:134) - choosing "core.accelerom
Acceleration: -1.6 x 6.3 y 7.5 z m/s^21414975695
Acceleration: -1.6 x 6.3 y 7.5 z m/s^21414975695
Acceleration: -1.6 x 6.3 y 7.5 z m/s^21414975695
Acceleration: -1.6 x 6.3 y 7.5 z m/s^21414975695
Acceleration: -1.6 x 6.3 y 7.5 z m/s^21414975695
Acceleration: -1.6 x 6.4 y 7.5 z m/s^21414975695
Acceleration: -1.6 x 6.3 y 7.5 z m/s^21414975695
Acceleration: -1.6 x 6.3 y 7.6 z m/s^21414975695
Looking at the code, there are a few things that need fixing to fix this.
1) qtubuntu-sensors backend does not check what the data rate has been set before starting the sensor.
2) platform-api does not arbitrate fastest data rate request and down sample to other slower data rate requests.
If it is platform policy that sensor data rates are not guaranteed (this is allowed by QtSensors API docs) then #2 does not need fixing. But fixing #1 without fixing #2 is problematic, as clients can change the rate of all clients sensors of a particular type when they do.