On Tue, 2022-06-14 at 09:17 -0600, Alex Henrie wrote:
On Tue, Jun 14, 2022 at 8:17 AM Sebastian Reichel sebastian.reichel@collabora.com wrote:
On Tue, Jun 14, 2022 at 2:05 AM Benjamin Berg benjamin@sipsolutions.net wrote:
Wouldn't it make sense for Wine to use the UPower provided DisplayDevice that can be queried through DBus?
UPower does the required data aggregation for the 'DisplayDevice'. I don't know enough about the Wine codebase to recommend for or against using UPower.
I also don't know if D-Bus would be a good choice here. It would certainly be a bigger change than the patch that I've proposed. What are the advantages and disadvantages of querying the battery through D-Bus, besides it doing battery aggregation for us?
Well, depends on what you need, it will: 1. Calculate a energy/power values if the HW reports charge/current 2. Try to generate a proper state (charging/discharging, etc.) if the hardware does not provide it 3. Aggregate multiple batteries
Actually, I think using UPower likely fixes bugs: * You are currently not supporting modern hardware that reports energy/power values (rather than charge/current). * You are only reading one battery * You are not estimating a rate if the HW does not provide one (and not smoothing it which might be desirable).
And, well, it should be easy. You can just query properties on a fixed DBus path. And if it fails, just assume you don't have a battery.
Benjamin