How to identify the primary battery (for Wine)
Benjamin Berg
benjamin at sipsolutions.net
Fri Jun 17 06:31:13 CDT 2022
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.
Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220617/7561d29f/attachment.sig>
More information about the wine-devel
mailing list