>> I did look up the IIO API and userspace ABI and I do not see a good fit. >> However, >> 1. I may be wrong > My gut feeling is that there 'ought to be a better option'. FWIW I tend to agree. IIO is designed for input devices that feature small sample sizes with individual timestamps and relatively few configuration parameters. I don't think it's wise to continuosly add new data types. There already is a framework that covers every possible input device, and even output. It's called char driver. > [...] > If you handled this in IIO I think you'd have to have a matched chunk > of userspace code that knows rather a lot about the sensor. Normally > we'd do a our best to avoid this and as such I suspect that > these devices really deserve a more specific home. Exactly. It's great to treat all accelerometers alike, and all magnetometers alike. That's the kind of device you have in modern cell phones and supporting all chip vendors with the same interface is definitely useful. In this case, I see the thing as a custom char device, where the application knows what it gets. /alessandro -- 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
