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

[Jonathan Cameron]

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/