[PATCH 1/2] HID: sony: Adjust value range for motion sensors

[PATCH 1/2] HID: sony: Adjust value range for motion sensors

[Roderick Colenbrander]

From: Roderick Colenbrander <roderick.colenbrander@sony.com>

The motion sensor values are 16-bit, so make the value range match.
It is hard to reach the upper values, but they can be reached. At
least the current accelerometer value of 8192 is very easy to pass.

It is still not nice that the motion sensors live in no man's land
in between ABS_MISC and ABS_MT_SLOT, but that's something for another
time, which the proposed ABS_ACCEL_*/ABS_GYRO_* were meant for.

Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
---
 drivers/hid/hid-sony.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 2387aaf..c9916cc 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -405,14 +405,14 @@ static u8 dualshock4_usb_rdesc[] = {
 	0x19, 0x40,         /*      Usage Minimum (40h),            */
 	0x29, 0x42,         /*      Usage Maximum (42h),            */
 	0x16, 0x00, 0x80,   /*      Logical Minimum (-32768),       */
-	0x26, 0x00, 0x7F,   /*      Logical Maximum (32767),        */
+	0x26, 0xFF, 0x7F,   /*      Logical Maximum (32767),        */
 	0x75, 0x10,         /*      Report Size (16),               */
 	0x95, 0x03,         /*      Report Count (3),               */
 	0x81, 0x02,         /*      Input (Variable),               */
 	0x19, 0x43,         /*      Usage Minimum (43h),            */
 	0x29, 0x45,         /*      Usage Maximum (45h),            */
-	0x16, 0x00, 0xE0,   /*      Logical Minimum (-8192),        */
-	0x26, 0xFF, 0x1F,   /*      Logical Maximum (8191),         */
+	0x16, 0x00, 0x80,   /*      Logical Minimum (-32768),       */
+	0x26, 0xFF, 0x7F,   /*      Logical Maximum (32767),        */
 	0x95, 0x03,         /*      Report Count (3),               */
 	0x81, 0x02,         /*      Input (Variable),               */
 	0x06, 0x00, 0xFF,   /*      Usage Page (FF00h),             */
@@ -714,14 +714,14 @@ static u8 dualshock4_bt_rdesc[] = {
 	0x19, 0x40,         /*      Usage Minimum (40h),            */
 	0x29, 0x42,         /*      Usage Maximum (42h),            */
 	0x16, 0x00, 0x80,   /*      Logical Minimum (-32768),       */
-	0x26, 0x00, 0x7F,   /*      Logical Maximum (32767),        */
+	0x26, 0xFF, 0x7F,   /*      Logical Maximum (32767),        */
 	0x75, 0x10,         /*      Report Size (16),               */
 	0x95, 0x03,         /*      Report Count (3),               */
 	0x81, 0x02,         /*      Input (Variable),               */
 	0x19, 0x43,         /*      Usage Minimum (43h),            */
 	0x29, 0x45,         /*      Usage Maximum (45h),            */
-	0x16, 0x00, 0xE0,   /*      Logical Minimum (-8192),        */
-	0x26, 0xFF, 0x1F,   /*      Logical Maximum (8191),         */
+	0x16, 0x00, 0x80,   /*      Logical Minimum (-32768),       */
+	0x26, 0xFF, 0x7F,   /*      Logical Maximum (32767),        */
 	0x95, 0x03,         /*      Report Count (3),               */
 	0x81, 0x02,         /*      Input (Variable),               */
 	0x06, 0x00, 0xFF,   /*      Usage Page (FF00h),             */
-- 
2.7.4

Re: [PATCH 1/2] HID: sony: Adjust value range for motion sensors

[Frank Praznik]

> The motion sensor values are 16-bit, so make the value range match.
> It is hard to reach the upper values, but they can be reached. At
> least the current accelerometer value of 8192 is very easy to pass.
> 
> 

Are the gyro values intended to be scaled in any way?  The current min/max values were based on the observed maximum extents of the controller at rest.  With this change the controller at rest will never appear to be turned more than 22.5 degrees in any direction to an application which assumes that the logical extents represent the device at 90 degrees.

Re: [PATCH 1/2] HID: sony: Adjust value range for motion sensors

[Simon Wood]

On Thu, October 6, 2016 8:27 am, Frank Praznik wrote:
>

>> The motion sensor values are 16-bit, so make the value range match.
>> It is hard to reach the upper values, but they can be reached. At
>> least the current accelerometer value of 8192 is very easy to pass.
>>
>>
>
> Are the gyro values intended to be scaled in any way?  The current
> min/max values were based on the observed maximum extents of the
> controller at rest.  With this change the controller at rest will never
> appear to be turned more than 22.5 degrees in any direction to an
> application which assumes that the logical extents represent the device
> at 90 degrees.

Don't forget that the _gyro_ values are a 'rate of turn' ie. 'degrees per
second'.

Since we're asking questions, I'd love to know more about the time
stamping of the accel/gyro data as this could improve AHRS/Kalman
performance significantly.

In the Move we get two sets of accel/gyro data, what's that about?
Simon

Re: [PATCH 1/2] HID: sony: Adjust value range for motion sensors

[Roderick Colenbrander]

On Thu, Oct 6, 2016 at 8:16 AM, Simon Wood <simon@mungewell.org> wrote:
> On Thu, October 6, 2016 8:27 am, Frank Praznik wrote:
>>
>
>>> The motion sensor values are 16-bit, so make the value range match.
>>> It is hard to reach the upper values, but they can be reached. At
>>> least the current accelerometer value of 8192 is very easy to pass.
>>>
>>>
>>
>> Are the gyro values intended to be scaled in any way?  The current
>> min/max values were based on the observed maximum extents of the
>> controller at rest.  With this change the controller at rest will never
>> appear to be turned more than 22.5 degrees in any direction to an
>> application which assumes that the logical extents represent the device
>> at 90 degrees.
>
> Don't forget that the _gyro_ values are a 'rate of turn' ie. 'degrees per
> second'.
>
> Since we're asking questions, I'd love to know more about the time
> stamping of the accel/gyro data as this could improve AHRS/Kalman
> performance significantly.
>
> In the Move we get two sets of accel/gyro data, what's that about?
> Simon
>

The 8192 value range was for the accelerometer, not the gyroscope. The
accelerometer returns force or acceleration, while the gyro as Simon
said gives degrees per second.

I understand why someone at first glance would think it was a gyro,
because it kind of gives an angle. What you see is just the constant
offset from the force of gravity. When you rotate the device, it will
just move to another axes. If you were to do some vector math, the
combined vector should stay constant for slow movements (the
gravitation offset should then be dominant over the dynamic data). You
could use this to basically calibrate the device, if you normalize to
this constant offset.

If you really want to measure orientation, you need to look at the
gyro which is the first 3 axes. However you need to integrate the
values over time to get an angle. You could for example rotate the
device, while collection values to get a sense of the value range. The
total sum would equal 360 degrees. Again this is a kind of userspace
type of calibration.

There is a proper way to calibrate the device, but I can't share any
on that right now. It needs more work to get additional sensor axes in
evdev. It needs more than 16-bit precision (due to precision reasons
related to multiplication and adding of an offset).

I can't say anything about Move, because I'm not familiar with it and
can't disclose anything. I would say pay close attention to the report
data, what you want to know is probably hidden in there.