How to identify the primary battery (for Wine)

How to identify the primary battery (for Wine)

[Alex Henrie]

Hi Sebastian,

I've been working to improve battery status reporting for applications
running on Wine on Linux. However, we Wine developers are not sure
what the best way is to determine which battery is the computer's
primary battery. Could you take a look at
https://gitlab.winehq.org/wine/wine/-/merge_requests/134 and leave a
comment there or on the wine-devel mailing list?

Thanks in advance,

-Alex

Re: How to identify the primary battery (for Wine)

[Benjamin Berg]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

Hi all,

On Mon, 2022-06-13 at 19:54 -0600, Alex Henrie wrote:
> I've been working to improve battery status reporting for applications
> running on Wine on Linux. However, we Wine developers are not sure
> what the best way is to determine which battery is the computer's
> primary battery. Could you take a look at
> https://gitlab.winehq.org/wine/wine/-/merge_requests/134 and leave a
> comment there or on the wine-devel mailing list?

Wouldn't it make sense for Wine to use the UPower provided
DisplayDevice that can be queried through DBus?

Benjamin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: How to identify the primary battery (for Wine)

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

Hi Alex,

On Mon, Jun 13, 2022 at 07:54:49PM -0600, Alex Henrie wrote:
> I've been working to improve battery status reporting for applications
> running on Wine on Linux. However, we Wine developers are not sure
> what the best way is to determine which battery is the computer's
> primary battery. Could you take a look at
> https://gitlab.winehq.org/wine/wine/-/merge_requests/134 and leave a
> comment there or on the wine-devel mailing list?

/sys/class/power_supply/*/scope is set to 'Device' for all
batteries, that are not powering the main system. There can still
be multiple batteries; for example Thinkpads in the 2014-2018 era
used to have an internal and a removable battery. For a single
"X %/hours left" info the data from all 'System' level batteries
must be aggregated.

> 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.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: How to identify the primary battery (for Wine)

[Alex Henrie]

On Tue, Jun 14, 2022 at 8:17 AM Sebastian Reichel
<sebastian.reichel@collabora.com> wrote:
>
> On Mon, Jun 13, 2022 at 07:54:49PM -0600, Alex Henrie wrote:
> > I've been working to improve battery status reporting for applications
> > running on Wine on Linux. However, we Wine developers are not sure
> > what the best way is to determine which battery is the computer's
> > primary battery. Could you take a look at
> > https://gitlab.winehq.org/wine/wine/-/merge_requests/134 and leave a
> > comment there or on the wine-devel mailing list?
>
> /sys/class/power_supply/*/scope is set to 'Device' for all
> batteries, that are not powering the main system. There can still
> be multiple batteries; for example Thinkpads in the 2014-2018 era
> used to have an internal and a removable battery. For a single
> "X %/hours left" info the data from all 'System' level batteries
> must be aggregated.

Thanks Sebastian, that helps a lot! We would really need to test this
API on Windows on a laptop with two batteries to see whether Windows
aggregates the batteries or just reports the charge of the first one.
For now, I hope that not doing any aggregation in Wine is acceptable
(and I hope someone will tell me if I'm mistaken).

> 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?

-Alex

Re: How to identify the primary battery (for Wine)

[Benjamin Berg]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: How to identify the primary battery (for Wine)

[Alex Henrie]

On Fri, Jun 17, 2022 at 5:31 AM Benjamin Berg <benjamin@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@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.

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