-f / --follow re-prints the first result instead of re-querying the device.
initializeFeatureRequests() runs before the loop, and processFeatureRequests() only executes requests still marked FEATURE_NOT_PROCESSED:
// cli/main.cpp
if (req.should_process && req.result.status == FEATURE_NOT_PROCESSED) {
req.result = handleFeature(dev, req.cap, req.param);
}
After the first iteration every request is FEATURE_SUCCESS / FEATURE_INFO, so iterations 2..N skip handleFeature() entirely and output() prints the cached result again. Nothing in the do/while resets the status.
So headsetcontrol -f -b shows the same battery level forever. The test device hides it because it returns a constant 42%.
Present in 4.0.0 and 4.1.0.
Fix is to reset req.result.status to FEATURE_NOT_PROCESSED at the top of each iteration - but only for the requests that were genuinely processable, since handleMultiDeviceActions() deliberately sets that same status to mean "refused, multiple devices". That distinction needs a separate flag or the reset has to skip requests it neutralised.
-f/--followre-prints the first result instead of re-querying the device.initializeFeatureRequests()runs before the loop, andprocessFeatureRequests()only executes requests still markedFEATURE_NOT_PROCESSED:After the first iteration every request is
FEATURE_SUCCESS/FEATURE_INFO, so iterations 2..N skiphandleFeature()entirely andoutput()prints the cached result again. Nothing in thedo/whileresets the status.So
headsetcontrol -f -bshows the same battery level forever. The test device hides it because it returns a constant 42%.Present in 4.0.0 and 4.1.0.
Fix is to reset
req.result.statustoFEATURE_NOT_PROCESSEDat the top of each iteration - but only for the requests that were genuinely processable, sincehandleMultiDeviceActions()deliberately sets that same status to mean "refused, multiple devices". That distinction needs a separate flag or the reset has to skip requests it neutralised.