I think I can add fixes over the next 2-3 days and include them in letux-6.1-rc7.
Failed to enable upper threshold 1149: -16 Failed to enable lower threshold 922: -16
Same for me, unfortunately. And also no time for working on the AESS subsystem driver.that I'm not gonna have time to work on this for at least a couple more days. Maybe not until after Christmas. Quite swamped with other commitments right now.
I think I've found the root cause of that bug: we both acceptAnd I have seen a strange bug in the kernel driver (it stops accepting changes for the threshold values) which deserves more research.
0as a valid threshold value and test
thres != 0to see if a channel is configured. Hence, if a threshold value is set to
0we no longer detect the channel as configured I'm working on a fix now. Not sure which is best, though:
0as an invalid threshold value and return
0as a perfectly valid value and leave it up to userspace to not shoot itself in the foot.
0makes sense for upper threshold but make little sense for lower thresholds. I'm leaning towards the latter, and fix the volume wheel daemon with this knowledge in mind. I even have a unittest for it already!
0value can be reported and a threshold value set so low that it never triggers the ADC interrupt. Reading the ADC value manually will at this point show
0, so I'm thinking of implementing a small timer that gets reset every time the program is woken up by the kernel. If the timer triggers, read the value 1 more time and then disable the it. This would mean that every wakeup from the kernel will always trigger at most 1 more wakeup by the timer some time later. I think that would be okay
10mV. Everything (both calculated threshold and ADC readings) below this level will get clamped to