Re: Handling Controllers with Acc/Gyro/Mag via HID system

Re: Handling Controllers with Acc/Gyro/Mag via HID system

[simon]

> Hi all,
> I'm in the process of fixing the HID descriptor for the PS3 Move
Controller. which has a particularly convoluted layout for it's
> Accelormeters, Gyros and Magnetometers involving 2 sets of data per output
> report.
> https://github.com/nitsch/moveonpc/wiki/Input-report

> The plan is/was to massage the HID descriptor so the first set of
Accels/Gyro/Mag appear in a set a axis, as a simple way of getting to
this
> data.

[snip]

> Given that more controllers are coming with 'motion' controls, is there a
> framework in place for unifying support?

A little more poking around has got me looking at the IIO subsystem, which
seems to be everything Accel/Gyro/Mag...

I note that there are a few 'HID'ish things there too, although I'm not
sure whether they are useful to us, or just intended for connecting motion
devices via the HID bus and then onto IIO.
--
drivers/iio/accel/hid-sensor-accel-3d.c
drivers/iio/gyro/hid-sensor-gyro-3d.c
drivers/iio/magnetometer/hid-sensor-magn-3d.c
drivers/iio/orientation/hid-sensor-rotation.c
--

Does the idea of the drivers for the HID (gaming) controllers opening up a
connection to IIO system and pushing the Accel/Gyro/Mag values there
(rather than exposing them on the joystick interface) make sense?

Are there any examples of other devices doing this, so I can re-use the code?
Simon.

Re: Handling Controllers with Acc/Gyro/Mag via HID system

[Bastien Nocera]

On Mon, 2015-06-08 at 22:38 -0400, simon-wM4F9T/ekXmXDw4h08c5KA@public.gmane.org wrote:
> > 
> > Hi all,
> > I'm in the process of fixing the HID descriptor for the PS3 Move
> Controller. which has a particularly convoluted layout for it's
> > Accelormeters, Gyros and Magnetometers involving 2 sets of data per 
> > output
> > report.
> > https://github.com/nitsch/moveonpc/wiki/Input-report
> 
> > The plan is/was to massage the HID descriptor so the first set of
> Accels/Gyro/Mag appear in a set a axis, as a simple way of getting to
> this
> > data.
> 
> [snip]
> 
> > Given that more controllers are coming with 'motion' controls, is 
> > there a
> > framework in place for unifying support?
> 
> A little more poking around has got me looking at the IIO subsystem, 
> which
> seems to be everything Accel/Gyro/Mag...

The IIO subsystem's user-space API is awful, and root only. I said as
much here:
http://thread.gmane.org/gmane.linux.kernel.iio/14421

> I note that there are a few 'HID'ish things there too, although I'm 
> not
> sure whether they are useful to us, or just intended for connecting 
> motion
> devices via the HID bus and then onto IIO.
> --
> drivers/iio/accel/hid-sensor-accel-3d.c
> drivers/iio/gyro/hid-sensor-gyro-3d.c
> drivers/iio/magnetometer/hid-sensor-magn-3d.c
> drivers/iio/orientation/hid-sensor-rotation.c
> --
> 
> Does the idea of the drivers for the HID (gaming) controllers opening 
> up a
> connection to IIO system and pushing the Accel/Gyro/Mag values there
> (rather than exposing them on the joystick interface) make sense?
> 
> Are there any examples of other devices doing this, so I can re-use 
> the code?

I wrote this for accelerometers that are in tablets/convertibles:
https://github.com/hadess/iio-sensor-proxy/

Re: Handling Controllers with Acc/Gyro/Mag via HID system

[simon-wM4F9T/ekXmXDw4h08c5KA]

> The IIO subsystem's user-space API is awful, and root only. I said as
> much here:
> http://thread.gmane.org/gmane.linux.kernel.iio/14421

Just getting started with this idea, and found this which might waylay
some of the pain....
https://github.com/analogdevicesinc/libiio


> I wrote this for accelerometers that are in tablets/convertibles:
> https://github.com/hadess/iio-sensor-proxy/

Thanks I'll check it out. Thinking more of a AHRS rather than 'just'
rotating the screen. ;-)
Simon

Handling Controllers with Acc/Gyro/Mag via HID system

[simon]

Hi all,
I'm in the process of fixing the HID descriptor for the PS3 Move
Controller. which has a particularly convoluted layout for it's
Accelormeters, Gyros and Magnetometers involving 2 sets of data per output
report.

https://github.com/nitsch/moveonpc/wiki/Input-report

The plan is/was to massage the HID descriptor so the first set of
Accels/Gyro/Mag appear in a set a axis, as a simple way of getting to this
data.

The Magnetometers are only 12 bits, and if 'we' want the HID system to be
able to process these as an axis the data needs to be shuffled. Previously
for the Sony SixAxis Accels was done in 'sony_raw_event'.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-sony.c?id=refs/tags/v4.1-rc7#n1035


My reshuffle would be:
---
                /* Need to fix order and shared nibble of 12bit Temp/Mags */
                /* 8e 4. .. .. .. .. -> Temp = 0x08E4 */
                /* .. .1 51 .. .. .. -> MagX = 0x0151 */
                /* .. .. .. 02 1. .. -> MagZ = 0x0021 */
                /* .. .. .. .. .2 98 -> MagY = 0x0298 */

                __u8 tmp;
                tmp = rd[38];
                rd[38] = (((rd[37] & 0xF0) >> 4) | ((rd[39] & 0x0F) << 4));
                rd[37] = (((tmp & 0xF0) >> 4) | ((rd[37] & 0x0F) << 4));
                rd[39] = (((rd[39] & 0xF0) >> 4) | ((tmp & 0x0F) << 4));

                tmp = rd[41];
                rd[41] = (((rd[40] & 0xF0) >> 4) | ((rd[42] & 0x0F) << 4));
                rd[40] = (((tmp & 0xF0) >> 4) | ((rd[40] & 0x0F) << 4));
                rd[42] = (((rd[42] & 0xF0) >> 4) | ((tmp & 0x0F) << 4));
---

This works, however I have noticed that this affects/reshuffles the output
of '/dev/hidraw0', which would 'corrupt' the data going into the existing
user-mode drivers (such as psmoveapi).

Is there a 'better' place/way to reshuffle this data, or is this just how
it needs to be?

Given that more controllers are coming with 'motion' controls, is there a
framework in place for unifying support?

Cheers,
Simon.

Re: Handling Controllers with Acc/Gyro/Mag via HID system

[Frank Praznik]

On 6/8/2015 11:41, simon@mungewell.org wrote:
> Hi all,
> I'm in the process of fixing the HID descriptor for the PS3 Move
> Controller. which has a particularly convoluted layout for it's
> Accelormeters, Gyros and Magnetometers involving 2 sets of data per output
> report.
>
> https://github.com/nitsch/moveonpc/wiki/Input-report
>
> The plan is/was to massage the HID descriptor so the first set of
> Accels/Gyro/Mag appear in a set a axis, as a simple way of getting to this
> data.
>
> The Magnetometers are only 12 bits, and if 'we' want the HID system to be
> able to process these as an axis the data needs to be shuffled. Previously
> for the Sony SixAxis Accels was done in 'sony_raw_event'.
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-sony.c?id=refs/tags/v4.1-rc7#n1035
>
>
> My reshuffle would be:
> ---
>                  /* Need to fix order and shared nibble of 12bit Temp/Mags */
>                  /* 8e 4. .. .. .. .. -> Temp = 0x08E4 */
>                  /* .. .1 51 .. .. .. -> MagX = 0x0151 */
>                  /* .. .. .. 02 1. .. -> MagZ = 0x0021 */
>                  /* .. .. .. .. .2 98 -> MagY = 0x0298 */
>
>                  __u8 tmp;
>                  tmp = rd[38];
>                  rd[38] = (((rd[37] & 0xF0) >> 4) | ((rd[39] & 0x0F) << 4));
>                  rd[37] = (((tmp & 0xF0) >> 4) | ((rd[37] & 0x0F) << 4));
>                  rd[39] = (((rd[39] & 0xF0) >> 4) | ((tmp & 0x0F) << 4));
>
>                  tmp = rd[41];
>                  rd[41] = (((rd[40] & 0xF0) >> 4) | ((rd[42] & 0x0F) << 4));
>                  rd[40] = (((tmp & 0xF0) >> 4) | ((rd[40] & 0x0F) << 4));
>                  rd[42] = (((rd[42] & 0xF0) >> 4) | ((tmp & 0x0F) << 4));
> ---
>
> This works, however I have noticed that this affects/reshuffles the output
> of '/dev/hidraw0', which would 'corrupt' the data going into the existing
> user-mode drivers (such as psmoveapi).
>
> Is there a 'better' place/way to reshuffle this data, or is this just how
> it needs to be?
>
> Given that more controllers are coming with 'motion' controls, is there a
> framework in place for unifying support?
>
> Cheers,
> Simon.
>

Hmm, perhaps remove the mappings for the motion controls in the HID 
descriptor and add the motion axis flags in the input device creation 
callback as is currently done with the touchpad axes on the DS4.  Then 
you can parse the motion data and fire off motion events manually in the 
raw event function (again, same as the touch events on the DS4) and the 
raw data in the packet will pass through unchanged for userspace drivers.

Regards,
Frank