Re: [RFC] Add Input IOCTL for accelerometer devices

[Jonathan Cameron]

> Hi,
> 
>>>  > But then comes another question: what to do with
>>>> magnetometers, gyroscopes, etc etc ??
>>> If we make a extensible sensor driver, I think we can add these new etc
>>> sensors in the future. step by step.
>> agreed here. But we have to think that this might get extended, so we
>> should start thinking of an abstraction layer that could evolve for
>> magnetometers, gyroscopes and other sensors
> 
> Agree with you, there should be an abstraction layer.
Indeed. There is however a question of where some of this should take
place. (Pretty much userspace vs kernel space).

Getting some of the more useful information from these sensors
(particularly where multiple types are available together) will
require quite sophisticated algorithms that are not available in kernel.

An example of devices where this is true would be the new wii controller
add on (although in this case it's all handled on the remote I think).
Here multiple sensors are used in conjunction to give results that simply
can't be established with a single sensor type.  Even in cases such
as analogs adis16350 and similar IMUs there is a lot of processing to be
done off the chip it self.

Yes we can do the dumb iphone style (hideously smoothed) accelerometer
type control, but that only touches the tip of what is possible.
 
> According to this, we should collect similar functionalities in one
> module and make sub-module describing exceptions devices or ones that
> needs special handling.
Some things can be wrapped into a core subsystem driver, but a frightening
amount of this stuff is chip specific.
> But in the end for the user space apps, they should "see" an
> accelerometer in a standard way. All exceptions and pre-handling
> should be done in the abstraction layer as described.
Such an abstraction layer should exist, but shouldn't be the only way to
access these devices.  A lot of them provide weird and wonderful elements
(based on internal processing) that would lead to an obscene amount of bloat
on any attempt at a general abstraction.
> We can't bring as many full drivers as devices found, but one driver
> serving for a group and that can load submodules when necessary.
Doesn't work.  In hid you can do this because the hardware itself conforms
to a tight spec.  This simply isn't the case with the types of sensor we
are talking about here.  They structure that would be needed would be much
closer to that taken by hwmon, where every chip (or family of chips) has
to have it's own driver.   Sure it then registers certain elements with
the core, but fundamentally they aren't similar enough to share all that
much code.
> The way HID is coded in Linux is an example for that, dealing with
> many types of devices.
> It isn't perfect, but its architecture can be used for other devices.
 
> To stay with accelerometers, they are sensors, and sensors sense
> physical properties.
> Every device use its own methods but in the end they sense the same
> thing and user wait for a similar feedback.
Partly true.  There is certainly a core functionality that is shared
across some of these chips.  However take a look at the drivers in IIO
or some data sheets and you'll find a frightening variety of other stuff
in each driver.  For basic input stuff it may be fine to only support the
common elements, but that's not an option for many other applications.
You tend to have picked a chip with particular features for a reason!
> 
> I post a link describing the HID standard, you can see in page 37 to
> 39 how they define units, and exponents for sensors.
> http://www.usb.org/developers/devclass_docs/HID1_11.pdf
> 
> Also, we can't imagine all use cases and scenarios, we should bring
> useful information to userspace apps and they do what they want with
> these informations.
> KDE developers may use sensors to automatically rotate the screen
> 90°/180° if the laptop is rotated. Others will use it to play games,
> Some others will use light sensors to lighten the keyboard or to
> change the brightness of the screen,...
> 
In a previous (off list) discussion, faking HID was brought up, so I'll
summarize where we got to.

Firstly note we would be faking HID.  In it's conventional use, it would be
the sensors themselves that would provide information about their facilities
and add all the stuff that it's described in the document above.  Sadly for
these devices very few manufacturers have gone down that path.  The driver has
to know what a given chip supports, there is no query method.  It would be possible
to make this work, but it's a seriously nasty case of blugeoning data into a
format that although flexible enough, was very much designed for other things.
Feel free to try and persuade the manufacturers to conform to HID!

To keep this maintenance nightmare minimal, we'd probably have to keep pretty
much completely separate from the HID system and just rely on matching interfaces.
(worth bringing in some HID experts but that's the feeling I got from reading
the code last time round?)

This in turn means we going to generate a nasty problem with testing any userspace
developments against both conventional hid and our 'fake' hid implementation.

If we were to go this way it would have to only be one of several interfaces.
The overhead will be large, and frankly for the high performance sampling end of
things that I'm interested in (and others who are in the CC's above) this isn't
an option.  Do you want to make HID deal with hardware (or software) ring buffering
for example?  It's way out of scope.

My personal preference for this problem area would be to look at how to add some
minimal core functionality to IIO to make it provide input interfaces as well.
In a similar fashion to lm-sensors it will be possible to establish functionality
of a given device by looking at what it exports in sysfs and hence applications
(or more likely a nice userspace library) can use this to identify what sort of
data is available and do any aggregation and processing.  In a similar fashion
to lm-sensors, this library would be kept in sync with the kernel tree.

HID might be an option, but I'm yet to be convinced it would be practical.

Jonathan
--
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/