On 03/11/14 23:01, Bastien Nocera wrote: > On Wed, 2014-10-29 at 19:30 +0100, Lars-Peter Clausen wrote: >> On 10/29/2014 06:47 PM, Bastien Nocera wrote: >>> On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote: >>>> On 10/29/2014 06:33 PM, Bastien Nocera wrote: >>>>> On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote: >>>>>> On 10/29/2014 03:30 PM, Bastien Nocera wrote: >>>>>>> Hey, >>>>>>> >>>>>>> I've posted this a couple of days ago: >>>>>>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html >>>>>>> along with a mail to LKML: >>>>>>> http://thread.gmane.org/gmane.linux.kernel/1810083 >>>>>>> >>>>>>> I've recently added to my list an item about IIO: >>>>>>> https://wiki.gnome.org/BastienNocera/KernelWishlist >>>>>>> >>>>>>> Are there any plans for a better API for the IIO subsystem? The API >>>>>>> might be good enough to drive from shell scripts, or helpers that only >>>>>>> need to work with one variant of a device, but my attempts at trying to >>>>>>> use the IIO subsystem to provide an accelerometer to do automatic >>>>>>> display rotation[1] showed that the API is really cumbersome. >>>>>>> >>>>>>> The code I wrote spends most of its time creating sysfs paths, reading >>>>>>> values in different formats, and mangling filenames[2]. >>>>>>> >>>>>>> Is an ioctl-based API planned? Something where I could get/set >>>>>>> structures to gather metadata about the device, and set it up easily, so >>>>>>> reading data from it is easier? >>>>>> >>>>>> No, unfortunately not and I'm not sure if such a ABI would be accepted if >>>>>> proposed. >>>>> >>>>> Why not? >>>> >>>> Because it means there will be ambiguity in the API on how to do things. >>>> Which is typically not a desired property. >>>> >>>>> >>>>>> But checkout libiio[1][2], it hides the details of the sysfs file manipulation. >>>>> >>>>> I'm not sure that's any better unfortunately. I've certainly tried to do >>>>> that already in my code, but that doesn't change that the user-space API >>>>> is barely usable. >>>> >>>> It's not completely unusable ;) >>> >>> In the end, you prefer the "self-documenting" of using sysfs files, >>> rather than an API which you can document in a header file? >> >> If it was for me we'd be using a state-full IOCTL ABI rather than a >> stateless sysfs ABI. I'm definitely not happy with the current interface, >> but it's the interface we have. But the problem with userspace ABI (in >> comparison to in-kernel API) is that we can just change things at random, >> but we have to stick with the existing interface. >> >> The sysfs ABI is not meant to be self documenting and it is not >> undocumented. The documentation for the different attributes can be found in >> Documentation/ABI/testing/sysfs-bus-iio[1]. > > That's useful if a bit terse. Thanks though. > >>> I don't understand that. My questions on this very mailing-list, and >>> comments that were made to users of my code[1] clearly show that the >>> existing API is anything but "not ambiguous". >> >> That bug report sounds like bugs in the driver. > > Not really. Some drivers need the "in_accel_hysteresis" set, some don't > have that sysfs file, for example. > >>> I've used the Bluetooth, input, rfkill, and inotify APIs as provided >>> directly by the Linux kernel (not through a layer) and they're of better >>> quality than the IIO one. >>> >>> I just don't see how one could support a class of IIO sensors with the >>> existing API. >> >> I can understand your frustration. A API that is not usable in a generic way >> is not really useful. So we should try to fix that, but we are bound by the >> framework itself and can't just throw everything away. >> >> So lets start by trying to identify what is missing. Which information do >> you think could be provided by using a IOCTL interface which you need or >> want which is not provided by the current sysfs interface or can not be >> provided by the current sysfs interface. > > (pseudo code ahead) > > First, being able to cut down on the string manipulation would be great. > So instead of doing: > accel_x_path = build_filename (sysfs_path, "in_accel_x_raw"); > accel_y_path = build_filename (sysfs_path, "in_accel_y_raw"); > accel_z_path = build_filename (sysfs_path, "in_accel_z_raw"); > if (exists(accel_x_path) && exists(accel_y_path) && exists(accel_z_path)) { > // We have an accelerometer > do_something(); > } > free(..x); > free(..y); > free(..z); > free(sysfs_path); > > I could query for the device's capabilities: > fd = open ("/dev/iio0"); > ioctl(fd, IIO_GET_CAPS, &caps); > if (caps.channels & (IIO_CAP_ACCEL_X | IIO_CAP_ACCEL_Y | IIO_CAP_ACCEL_Z)) { > // We have an accelerometer > do_something(); > } > > Note that, from the data given, I don't know how to make out whether > something is an accelerometer, or a quartenion sensor, or which one we > should prefer on specific machines. > > This would also be stateful, so that 1) enabling the various channels, > 2) changing the hysteresis would be reset when the fd is closed. That > would cut down on the power consumption when unused, or when the service > that uses that data crashes. > > Finally, there's some documentation, and it's not quite finished, or > there's something fishy on this device: > $ ls /sys//devices/platform/80860F41:04/i2c-12/i2c-SMO8500:00/iio:device0/events > in_accel_x_thresh_thresh_en in_accel_x_thresh_thresh_value > in_accel_y_thresh_thresh_period in_accel_z_thresh_thresh_en > in_accel_z_thresh_thresh_value > in_accel_x_thresh_thresh_period in_accel_y_thresh_thresh_en > in_accel_y_thresh_thresh_value in_accel_z_thresh_thresh_period Hi Bastien, I'll catch up with this thread properly (probably tomorrow) but in the meantime I would imagine this is perhaps a weird and wonderful symptom of: https://lkml.org/lkml/2014/10/10/249 Due to some personal stuff I'm running about 10 days behind with patches - catch up soon. Jonathan > > Reading this is like singing Kool & the Gang with a lisp. > > It's also very unclear to me when to use triggers, if there are any, > when there a scan_elements sub-directory, and when not, when there is an > events sub-directory, and when not, and whether properties (the various > sysfs files) are readable, writable or both. > > I've had the experience of 2 accelerometer devices, one in the Yoga 13, > using the hid-sensor* family of accelerometers, and one in the Onda > v975w with the kxcj9 1013 variant. The first has triggers, and > scan_elements. The second has events with "super-thresh" filenames. > > So I'm really a bit lost. > > Cheers > > -- > 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-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
