On Sun, 1 Aug 2021 20:20:07 -0600 Morgan Hager <morgan.hager1@xxxxxxxxx> wrote: > 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 I'd be wary. ACPI supports a lot of events that never get used by anyone so also good to point to a known platform that does notify on _ALR changing. > 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? For things like this, we can potentially use the rather vague event type of IIO_EV_TYPE_CHANGE. It's not ideal, but you would then use that in conjunction with a sysfs file to get the data. The event telling you to read the file. The reason it's not ideal is that the reponse table doesn't really sound much like a channel to me and we can only associate events with a channel. Very nature of events in IIO is to that they are slim, so we don't carry data in them anyway (beyond that the really basic types). One other thing to take into account here. If you define new ABI for _ALR it will probably not be supported by standard userspace as there is no generally accepted way of providing conversion curves. The ACPI spec is clearly trying to solve that problem but I fear most light sensors won't be on ACPI platforms any time soon. Much of the maths needed for light sensors involves fusing multiple different sensing element whereas I don't the ACPI approach supports this. So, what we normally do (hideous though it is) is to do the maths in kernel so that we can provide a _PROCESSED value that userspace can directly use. It's a pain to do the fixed point maths but the advantage is no special userspace code is needed. If you got that way, then the updates of _ALR will be entirely hidden in the driver and no userspace interface is needed. Thanks, Jonathan > > Thank you for your input, > Morgan Hager
