On 19/12/14(Fri) 08:04, David Higgs wrote: > Split upd_update_sensors() behavior to gather all values prior to updating > sensor contents. > > Because sensors were updated in report_ID order, it could take multiple > passes of upd_refresh() to update some sensors. Specifically, > battery-related sensors “prior” to a change in BatteryPresent would be > stale/incorrect until the 2nd call to upd_refresh(). Also, change a > confusing DPRINTF of report_ID from un-prefixed hex to decimal, to be > consistent.
What you're saying is that querying HUB_BATTERY_PRESENT after 6 sensors that depend on its value does not make sense, right? Well in this case I don't think that sensors should be queried in reportID order. I even don't think that sensors should be queried at all if we're going to discard the result anyway. It might not matter that much right now, but if the number of queried sensors grow s significantly we might end up waiting a lot of time in upd_refresh() prior to updating anything. > This fix is needed for future improvements, where output or behavior of > certain sensors depends on the current value of more than one report (e.g. > RemainingCapacity should actually depend on CapacityMode). But do you need to read the value of CapacityMode more than once, at the begging or when you modify it? Anyway, when we discussed that with Andre, I suggested to have a table containing all sensors depending on an other one. This way you can start by querying HUB_BATTERY_PRESENT and if it is present, query the others. Another advantage is that it will simplify the code because all the sensors in a table will be in the same page. Since you're doing some great job with upd(4), here's another idea. Did you consider updating the values of the sensors via an asynchronous function and a callback? This way the thread does not need to way for the previous queries. That would involve adding a new function, let's say uhidev_get_report_async() that takes a custom callback since there's no such API for the moment. Regards, Martin
