Paul de Weerd <we...@weirdnet.nl> wrote: > On Tue, Aug 25, 2020 at 09:27:20PM +0200, Mark Kettenis wrote: > | > I've dug out my stash of weird usb devices and found another sensor (a > | > uthum(4), with only temperature support). I have a few other sensors > | > in live machines too (acpitz(4), cpu(4), admtemp(4), it(4), maybe some > | > more) that I could look into. > | > > | > Is there any interest in adding support for setting the tv member for > | > non-time sensitive sensors? Or should I drop this quest? > | > | I don't understand the point. None of the sensor drivers set that > | member except the timedelta sensors. I don't think adding code to do > | so to all sensor drivers makes sense. > > I'm inspecting it to only register "new" samples (even if the value > itself doesn't change). My logic is that if the tv member has > changed, then the sensor value has been updated, so there's new > "data". The fact that it's the same temperature / humidity / other > sensed value can also be interesting. > > But if that doesn't make sense, then I can drop the patches and just > do periodic sampling at the same interval the kernel uses (which I've > not found yet, it seems that at least ugold(4) just sends data > periodically (every ~6 seconds) which the kernel then presents to > userland through sysctl).
What you are doing wasn't the purpose of the time field. It was added only for time sensors, and it looks like someone added it to other sensors. And now it must suddenly be for all of them?? Collecting the microtime on every sensor read, on every time through the processing loop, is not free.
