Hi, Most of the items in the Android HAL are indeed already supported in IIO (in some cases accommodated with minor conversions in the HAL layer) as you mention. There is hardware(/firmware) that does all of the stuff in the Android HAL, including gravity, step detector, and step counter. For example you can find almost all of these implemented in the Nexus 5. The point of having these in hardware and not in userspace is to avoid keeping the core processor awake, thus saving power. Regarding the sensors defined in the HID Sensor usage document: Do you consider biometric sensors out of scope? These are not implemented in software due to the fact that they need to also be available during sleep state, and therefore should not keep the host processor awake. Regarding the custom sensor - we don't need this for obfuscating data, we actually want this for a true "custom" sensor - a programmable sensor. Many of the sensors listed in both the Android HAL and in the HID usage document are actually virtual fusion sensors derived from other sensors' data via some algorithm. The point of having these virtual sensors implemented in hardware/firmware is to minimize the core processor wake time and to save power. Supporting a "custom" programmable sensor would enable application developers to load such a virtual sensor into the hardware on the fly, and have that sensor readily available to the application without the need to provide a driver. Best regards, Yoav Haimovich -----Original Message----- From: Jonathan Cameron [mailto:jic23@xxxxxxxxxx] Sent: Saturday, November 23, 2013 14:50 To: Haimovich, Yoav; Yuniverg, Michael; linux-iio@xxxxxxxxxxxxxxx Cc: Drubin, Daniel Subject: Re: IIO devices flexibility On 11/14/13 07:50, Haimovich, Yoav wrote: > Hi, > Hi, Firstly, sorry for the slow reply! Been an interesting couple of weeks. Anyhow, > The sensors we would like to add are the ones supported by Android KitKat and are found at: > http://source.android.com/devices/reference/sensors_8h_source.html The bit about virtual sensors is interesting but I guess you'll do this in userspace. Any application of transforms to the axes of the data should probably be done in userspace so I'll just ignore that. To make life easier for others who wish to join this thread, I'll list them all and give my opinions on them. Acceleration - Sensible choice to use SI units. (present in IIO) Geomagnetic field - (present in IIO) Orientation - Euler angles - I think, it's been a while... Conversion isn't horendous from quaternions which we already have a proposal for. If hardware spits out Euler angles, then we can certainly add an appropriate interface for them. Gyroscope - (present in IIO) light - (present in IIO) There definition is rather limiting as doesn't include different frequencies. Lux is a measure of illuminance so I guess they care only about human perception of light intensity. (which makes sense) presure (present in IIO) different units but I guess that isn't a problem? temp (present, but deprecated) proximity (present in IIO though I don't think we have anything yet that gives a clean measurement) gravity - Not present in IIO. I haven't yet seen this implemented on a device, but easy enough to add if there is hardware doing this. (I know some high end IMUs do this but even then you often get a better result doing it in software) rotation vector - (proposed, but not yet present). I've been promising to propose how to handle this as a single 'measurement' as the individual elements have no meaning on their own). Keep not getting around to it :( relative humidity - (proposed and the first driver is just waiting for some device tree name changes) ambient temperature - Hmm. I wonder how best to provide the meta data to distinguish this from any other temperature sensor. Otherwise, supported. magnetic-filed uncalibrated - just a different use of meta data found in sysfs. game-rotation-vector - This is just a conventional drifting gyroscope (rather than the rate sensors that mems gyros are). Again we may want metadata to make it clear that some hardware is doing this in a random basis. gyroscope-uncalibrated - we don't have explicity way so separately outputing the drift estimate, but would be easy enough to add (as an additional channel). signficant motion - IIO event. step detector - either an IIO event, or in userspace. step counter - interesting - would be easy to implement an event counter if this is of sufficient use. I'm guessing some hardware provides this on device. Would become an additional property of the event in question. > > And also the sensors that are defined in the HID Sensor usage document: > http://www.usb.org/developers/hidpage/HUTRR39b.pdf; > For this one some stuff is obviously not within the scope of IIO. Biometric (out of scope - or processed in userspace from an IIO device). Electrical : Available in IIO though we have no indunctance or resistance types yet or period (though that might be established from frequency.) I don't think we have any frequency measuring devices yet, but we do have output ones so the interface is fairly well defined. Wind direction, wind speed. These are just orientation and velocity sensors (possibly with explicity meta data ) Light - present in IIO though might need an additional modifier for consumer infrared. Location - probably not in scope. Mechanical - likely to be userspace computed values from IIO sensor rather than directly provided. Not a problem to add this if desired though. Motion - Accel, gyro covered. Speedometer not, and motion detector is likely to be an IIO event on a particular device. Orientation - Compass and inclinometer covered. Distance not yet, but easy addition when first device driver is proposed. scanner - out of scope. time - partly covered, though we could definitely improve our handling of this when it is a timestamp for some other data. Direct use as rtc etc is out of scope of IIO. Custom devices. These exist for anything that is out of scope of the parts defined by this spec. THat doesn't mean they can't have a definition in IIO. I am not really interested in providing a 'custom' interface. It should always be possible to identify what is being measured and provide a real interface. One stated use in the spec is to obfiscate data. As per other linux userspace interfaces, we are very much against any attempt to pass undocumented binary streams out of the kernel to close source binaries. Hence I'll ignore that usage and assume it is just for stuff that no one has thought of yet! Hence in conclusion. If you have something that falls into the HID specs 'custom' category then just 'make up an interface' for it and propose it as an addition to IIO. I don't see anything in either of these documents (that lies within the vaguely defined scope of IIO) that will cause any real trouble to add support for. Looking forward to lots of 'interesting' drivers ;) Jonathan > The latter document also includes a definition of the custom sensor we would like to support. > > Best regards, > Yoav Haimovich > > -----Original Message----- > From: Jonathan Cameron [mailto:jic23@xxxxxxxxxx] > Sent: Wednesday, November 06, 2013 19:27 > To: Yuniverg, Michael; Jonathan Cameron; linux-iio@xxxxxxxxxxxxxxx > Cc: Drubin, Daniel; Haimovich, Yoav > Subject: Re: IIO devices flexibility > > > > "Yuniverg, Michael" <michael.yuniverg@xxxxxxxxx> wrote: >> Hello Jonathan, guys >> >> We are using iio now for 4 standard sensors and we are rather >> satisfied with its execution and robustness. >> Now implementing new sensors we came across a limitation - >> >> -- >> static const char * const iio_chan_type_name_spec[] = { >> [IIO_VOLTAGE] = "voltage", [IIO_CURRENT] = "current", [IIO_POWER] = >> "power", [IIO_ACCEL] = "accel", [IIO_ANGL_VEL] = "anglvel", >> [IIO_MAGN] = "magn", [IIO_LIGHT] = "illuminance", [IIO_INTENSITY] = >> "intensity", [IIO_PROXIMITY] = "proximity", [IIO_TEMP] = "temp", >> [IIO_INCLI] = "incli", [IIO_ROT] = "rot", [IIO_ANGL] = "angl", >> [IIO_TIMESTAMP] = "timestamp", [IIO_CAPACITANCE] = "capacitance", >> [IIO_ALTVOLTAGE] = "altvoltage", [IIO_CCT] = "cct", [IIO_PRESSURE] >> = "pressure", >> -- >> >> To our understanding, that means these are only data channels we have. >> We need however new channels and even more - custom/generic channels >> including some proprietary info Does that fit your vision of IIO? > > These channel types get added whenever a new device needs one. > > Hence feel free to propose additions to the list above along with an example device that needs it. There are a couple more under review at the moment. One of these is particularly interesting in that it presents a quaternion which will need some additional core support. > > As for proprietary info and custom/generic channels... Could you give some examples of what you have in mind? > > Thanks > > Jonathan >> >> Thanks, Michael >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ��.n��������+%������w��{.n�����{��(��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
