I was thinking of extending the acpi-als driver to support reading the colour temperature, chromaticity, polling interval, and response table, but there's a problem with doing the response table through IIO; the table is variable-length, but it seems that IIO channels only support fixed-length samples (and the ACPI spec also does include a provision for an event to be sent if the response table changes, so it would be good to expose that to userspace rather than only allowing reading the table from a file). As an alternative approach, I have written a driver for personal use which is not at all based on IIO and instead conveys events through the ACPI netlink socket and readings directly through sysfs nodes, at https://github.com/goose121/als_bus; this works fairly well, but it seems that the driver was specifically migrated from something similar to the IIO framework so that it would be compatible with other light sensors, and it seems inelegant to use a completely different interface for one property of a device. Does anyone know of an elegant way these events could be exposed to userspace, preferably one which would fit into the current framework of the driver? Thank you for your input, Morgan Hager
