Re: HID Sensor support for True/Magnetic North usage attributes

From: Jonathan Cameron
Date: Sat May 24 2014 - 06:37:27 EST


On 16/05/14 18:46, Srinivas Pandruvada wrote:
On 05/13/2014 07:14 PM, Reyad Attiyat wrote:
Dear IIO/HID maintainers,

I have a device, Surface Pro, that has the hid-sensor-hub and many
sensors attached. With the help of Srinivas I was able to get them all
working except for the magnometer. It uses the hid-magn-3d driver as
it should but it does not contain an axis (X, Y, Z) usage attributes.
Instead it only has a True North usage attribute. I see two solutions
to this problem and was inquiring which one would work best?

1) Modify the hid-magn-3d driver to handle True North attribute. I
realize there might not be many devices that have this so not sure if
appropriate. I think this could be done; by passing a variable amount
of IIO Channels when setting up the hid-magn-3d driver, depending on
how many axis and/or if it find True/Magnetic North usage attribute.
I prefer this approach. The spec doesn't say whether magnetic flux for x,y or z are mandatory.
Ultimately they are used to calculate the true north. So if the hub is trying to expose true north,
we should add this attribute.

"Heading True North SV â Indicates compass true north heading is not compensated.
Default unit of measure is degrees; can be overridden using
explicit Unit and/or Unit Exponent."

Agreed. Don't worry too much about the driver naming. Plenty of convention
says that it has no real meaning other than labelling one part supported by
the driver.

Thanks,
Srinivas
2) Create a whole new driver that handles True/Magnetic North. This
would not work on my device as it is set to Compass 3D Usage
Attribute. This could be resolved by adding another quirk for the
Surface to ensure it used the new driver.
No to this one as we'll end up with lots of similar cases and far too many
similar drivers.

For both options I think we'd need a new IIO_MOD_NORTH for the
iio_chan_spec, as the current ones don't really apply. I like the
first solution as it could allow for handling of devices with only one
or two axis present. I do realize if the hid-mangn-3d driver was
changed it's name would not make sense anymore and the pattern I'm
notcing is a driver for each HID Usage.
If you are introducing a north attribute, allow for both true and magnetic
norths (only introduce the one you are using).

IIO_MOD_NORTH_TRUE
IIO_MOD_NORTH_MAGNETIC perhaps?
I see the spec also mentions compensated variants of these... If you do
include these I think
IIO_MOD_NORTH_TRUE_TILT_COMPENSATED or similar would be needed to make it
clear what was going on.

Here's a link to the hid report description with some labels for my device:
Bug 73321 Comment 7
https://bugzilla.kernel.org/show_bug.cgi?id=73321#c7

I'd be willing to work on this. Just wanted to know what would work best

Cool. I'd suggest perhaps doing the documentation first for the new ABI elements
then we can hammer that out in parallel with work on the driver.
(it's usually the harder part!)
Thank You,
Reyad Attiyat
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/