On Wed, May 27, 2020 at 09:22:24AM +0200, Krzysztof Kozlowski wrote: > On Tue, May 26, 2020 at 09:24:39PM -0400, Andrew F. Davis wrote: > > On 5/25/20 10:11 AM, Krzysztof Kozlowski wrote: > > > All battery related data could be important for user-space. For example > > > time-to-full could be shown to user on the screen or health could be > > > monitored for any issues. Instead of comparing few selected old/new > > > values, just check if anything changed in the cache. > > > > > > > > > At least some value will change every time we poll the battery, are we > > okay with having power_supply_changed() called every time? > > Hi, > > Let me give few arguments: > 1. "Every time" means still once per poll interval or in case of many > get_property() calls, once per 5 seconds. In first case, if users > sets polling every 1 second, I expect he knows what he wants. I2C > will be busy anyway so uevents should not matter that much. > In second case, called through get_property(), once per 5 seconds is > not that frequent. > > 2. Different drivers do it differently. Many chargers notify about > everything. Most fuel gauges only on status or capacity change (although > I am not sure if they measure more) but few FG send uevents about > everything (max17042_battery, sbs-battery, s3c_adc_battery). > > 3. If drivers does not send notifications on changed properties of > battery, then basically the user-space has to poll every time for all > data which is not being a trigger. The overhead for system would be > the same, I guess. >
And one more: 4. I actually needed for my project. I have a user-space which previously was polling the battery status but I converted it to udev events. The voltage, current and temperature are important for me as well so I need all uevents. Best regards, Krzysztof
