Dear Ben,
quoted text
>> In particular, what I think would be worthy would be:
>> * Up to 3 pre-defined axes (X, Y, Z) - that's provided by your current  
>> version of industrialio
>> * If the accelerometer is soldered on the computer, define once for all  
>> to which _physical_ movement corresponds which axis (eg: a laptop on its  
>> normal position going up has axis Z increasing).
>> * Free fall event. Either it's hardware detected, or the accelerometer  
>> infrastructure will detect it in software.
>> * For each axis, what is the maximum and minimum bound and the unit -  
>> Probably worthy for the whole ADC infrastructure
>> * Joystick emulation (calibrated so that when the computer is not  
>> moving, all the values are at 0). All the current drivers have it.
> 
> I think if we're trying to make something that will cover a number
> of device classes, we need to be more like HID and have a system
> that reports and possibly records the following:
Ok, this is the key disagreement at the moment on the approach to be
taken here.  I'd again argue that the purpose of events in this subsys
are very different from what you describing.  Events tend to indicate
that something has happened (eg. the Free fall even mentioned above),
not that the current value of something is x.  It may be that we
will have devices that do indeed act closer to you conventional
user interface device and provide (x moved to 103 etc).  If we
do then this may all need rethinking.
 
quoted text
> 1) What data is possible to be returned from each event, with the
>    units, magnitude and any scale applied by the device sending.
> 
> 2) Each event should be able to report a number of items, so that
>    if the sensor reports X/Y/Z in one go, there is just a single
>    event containing those values.
Agreed.
 
quoted text
> 3) A well defined set of information that can be read (like #1)
>    that can provide details of the device and how it relates to
>    the environment it is in.
Indeed, this is crucial and probably forms the next element of the
code to be written.  At the moment I'm inclined to go with an approach
similar to the input subsystem with it's proc interface that provides
a nice machine readable description of device functionality.

Anyone have any other suggestions on how this can be sensibly achieved?

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