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

[Benjamin Berg]

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

[Sebastian Reichel]

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

[Alex Henrie]

On Tue, Jun 14, 2022 at 8:17 AM Sebastian Reichel
 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  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

[Stefan Dösinger]

> Am 14.06.2022 um 18:17 schrieb Alex Henrie :
>
> 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.

I sort of have one like that, but I am not sure if I still have the batteries. It is a 2003 Acer Travelmate 800, and it had a main battery and the CD drive was replaceable with a secondary battery. I used to have both batteries, but I think I disposed of them after they were unable to hold any charge at all.

Plus, the laptop came with Windows XP; I once had Windows 7 running on it though. And it is in my home in Vienna, and I won't get there any time soon.

The Windows battery tray showed one aggregate of both batteries, but when clicking on it it would you could see the state of both batteries separately.

(I took Linux-pm out of CC for my reply because it is Wine/Windows specific)

[Benjamin Berg]

On Tue, 2022-06-14 at 09:17 -0600, Alex Henrie wrote:
> On Tue, Jun 14, 2022 at 8:17 AM Sebastian Reichel
>  wrote:
> > On Tue, Jun 14, 2022 at 2:05 AM Benjamin Berg  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

[Alex Henrie]

On Fri, Jun 17, 2022 at 5:31 AM Benjamin Berg  wrote:
> On Tue, 2022-06-14 at 09:17 -0600, Alex Henrie wrote:
> > On Tue, Jun 14, 2022 at 8:17 AM Sebastian Reichel
> >  wrote:
> > > On Tue, Jun 14, 2022 at 2:05 AM Benjamin Berg  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:
> - Calculate a energy/power values if the HW reports charge/current
> - Try to generate a proper state (charging/discharging, etc.) if the
> hardware does not provide it
> - 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