How to identify the primary battery (for Wine)

[Alex Henrie]

On Fri, Jun 17, 2022 at 5:31 AM Benjamin Berg <benjamin at sipsolutions.net> wrote:
>
> 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 at collabora.com> wrote:
> > > On Tue, Jun 14, 2022 at 2:05 AM Benjamin Berg <benjamin at 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.

Thanks for the information! It looks like we're sticking with reading
from /sys directly for now, but it's good to know what we can get over
D-Bus for if we have more problems in the future.

-Alex