How to identify the primary battery (for Wine)
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
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
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
On Tue, Jun 14, 2022 at 8:17 AM Sebastian Reichel <sebastian.reichel(a)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(a)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
Am 14.06.2022 um 18:17 schrieb Alex Henrie <alexhenrie24(a)gmail.com>:
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)
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(a)collabora.com> wrote:
On Tue, Jun 14, 2022 at 2:05 AM Benjamin Berg <benjamin(a)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
On Fri, Jun 17, 2022 at 5:31 AM Benjamin Berg <benjamin(a)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(a)collabora.com> wrote:
On Tue, Jun 14, 2022 at 2:05 AM Benjamin Berg <benjamin(a)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
participants (4)
-
Alex Henrie -
Benjamin Berg -
Sebastian Reichel -
Stefan Dösinger