> Date: Tue, 25 Aug 2020 21:33:32 +0200 > From: Paul de Weerd <we...@weirdnet.nl> > > Hi Mark, > > Thanks for your reply. > > 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).
Correct, most sensors are simply sampled periodically.
