From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: Support for multiple batteries Date: Sat, 13 Jun 2020 12:48:24 +0100 Message-ID: <874krfnq47.fsf@tcd.ie> References: <87tuzhy49m.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="57621"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 13 13:49:12 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jk4et-000EtR-7V for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 13:49:11 +0200 Original-Received: from localhost ([::1]:48708 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jk4es-0003JW-7N for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 07:49:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42718) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jk4eF-0001or-Nd for emacs-devel@gnu.org; Sat, 13 Jun 2020 07:48:31 -0400 Original-Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:51332) by eggs.gnu.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jk4eD-0000x4-AR for emacs-devel@gnu.org; Sat, 13 Jun 2020 07:48:31 -0400 Original-Received: by mail-wm1-x32c.google.com with SMTP id b82so1681392wmb.1 for ; Sat, 13 Jun 2020 04:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=tnT2nxhU6Z6ljN17BjFrWsC5pfEOEmGZKfwgwlkprJ8=; b=ule9/z1DXzvH3dqLSojYPgavRC7cCE5WmdiMW8HMyyabyY2J85KhMNOSnQKHYo8rr3 o/FQvlcOXaO7sNXQ+d8FRcL/F/+UgbrykB8uVgJGbo38IM8AlzB2Le64vTixkIrDG7/x 1iLqqaDm67hYggVcBQtrZnpFNHV1kQenQbrNreN7hBzE8FrBJkJyhUu93a4+oTqTFsG6 25YTBUnErZj6znRqtvvDDllfOgMba37CWURmCK2UmQbY/VZvb75BKWt7NSW7wxTD89PR gMXKsHGDlrF9Io9GGxNhTwwoZL3tPX+NRHMZc/Zb/gJZGLhFz8MYHJyEFC1uybuKXXzu BuvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=tnT2nxhU6Z6ljN17BjFrWsC5pfEOEmGZKfwgwlkprJ8=; b=f5UnNuz9YfHGg75zXIu5S2WjNju+/1OBNt1wHjymeYtDvjDC6H6xp9Nl/Zjss0DcIC ufNACILLc8/oI0aG3ALKBstalcSbAWo7r0NuWXqnLxChFHfftDPUVRcauhVI/ybNFTPM U6TR/r8vCapRwcDMBhqW5IPpiEAfH3Ale53rlM38hxuln7RRMkFL2qtIzjCwu3mzNTC5 guObTbzEFKP8qQ14FeeC1slEPP6isTwFNlmidvojV8uEUjFIFPLC9CB7yqx1evR460CB RDy7JpGURFcVCC8IE8sFrnMPapilYJzT/XQBVntc5915Et7m1oAzSX4feq/1+m8XU6Dc GdmQ== X-Gm-Message-State: AOAM532DZDrmg8l3nb/b79fqebdv1LEfeLrRywPvmpTUE9mzPMSU+9Fp 9/hoaOmGsQWasM/lcz63xFvXl0vd8XQ= X-Google-Smtp-Source: ABdhPJydtlffsAyCCW8oFX5zQWmsY+mxRPakMeQJAcOgg3Ira4I3GLlU4DHw+8ttlmQzowsNAJCklA== X-Received: by 2002:a1c:3c08:: with SMTP id j8mr3583329wma.158.1592048906784; Sat, 13 Jun 2020 04:48:26 -0700 (PDT) Original-Received: from localhost ([2a02:8084:20e2:c380:1f68:7ff5:120d:64e]) by smtp.gmail.com with ESMTPSA id 67sm15173507wrk.49.2020.06.13.04.48.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Jun 2020 04:48:26 -0700 (PDT) In-Reply-To: (Richard Stallman's message of "Sat, 13 Jun 2020 00:02:41 -0400") Received-SPF: none client-ip=2a00:1450:4864:20::32c; envelope-from=contovob@tcd.ie; helo=mail-wm1-x32c.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252158 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > AFAICT only two battery status backends currently support multiple > > sources of information: battery-linux-sysfs and battery-linux-proc-acpi, > > for Linux sysfs and ACPI support, respectively. > > Could you clear up for me what "currently" means in this context? I > don't know what code was changed in January or so -- only that the > change led to incorrect reports, on a Thinkpad T400s with two > batteries inserted. The battery.el package provides a user option battery-status-function which determines how to query the system for information on its power sources. When battery.el is loaded, it checks for the availability of various system features in order to set the user option to the most sensible default out of a known set of possible values. Each of these values is a function (a "backend") which returns an alist of all relevant battery information, such as load, time to discharge, etc. Emacs 26.1[1] introduced a new possible value for battery-status-function, namely battery-upower, which gets its information from a UPower[2] D-Bus service (daemon) running on the system[3]. This backend was disabled by default, i.e. in order to use it, a user would have to manually set battery-status-function to battery-upower. In early February[4], the battery-upower code was improved and battery-status-function was changed to default to battery-upower if the system provides a UPower service. This can be perceived as a regression on multi-battery systems because battery-upower currently assumes a single battery, whereas the previous defaults of battery-status-function on modern GNU/Linux systems (battery-linux-sysfs and battery-linux-proc-acpi) support multiple batteries. The patch in [5] adds support for multiple batteries to battery-upower as well, so that it can remain the default backend when applicable. [1]: * lisp/battery.el: Add 'battery-upower' -- very fast battery status. 05a969265c 2016-12-02 12:17:38 +0200 https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=05a969265cabdf361492ed471f1a8dc369840401 [2]: https://upower.freedesktop.org/ [3]: https://www.freedesktop.org/wiki/Software/dbus/ [4]: Make 'M-x battery RET' work out-of-box for UPower users. d8f4317f03 2020-02-06 09:13:19 -0500 https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d8f4317f03be69cfaf6a60bda228996590fd92b5 [5]: https://debbugs.gnu.org/39491#55 > > The way they handle multiple batteries is by merging multiple data into > > a single report. > > I am not sure what that means, concretely. The current multi-battery-aware backends, battery-linux-sysfs (which uses the /sys/class/power_supply filesystem) and battery-linux-proc-acpi (which uses the /proc/acpi filesystem), iterate over each battery file, collecting and summing various relevant data, and then return them as aggregate values. For example, they sum the current energy and energy-when-full of each battery, and divide the former by the latter to get the combined load percentage. > Is this what you mean by "proper" support, > > Proper support means at least giving a good estimate for how long > before the machine runs out of energy, and a good estimate of the > actual fraction of maximum charge the batteries can hold. The code > from last October could do that. > > When I type M-x battery in the version as of October 2, > it displays something like > > Power BAT, battery Discharging (98.1% load, remaining time 4:04) > > where the numbers depend on the energy capacity of each battery and > the current charge of each battery, as well as the actual current or > power. > > That is what I think is crucial for M-x battery. In that case I think the patch in https://debbugs.gnu.org/39491#55 fixes the regression you observed by making the new default backend, battery-upower, behave like the other multi-battery-aware backends in this regard. BTW, the reason battery-upower makes sense as a default is because the UPower standard provides a uniform interface[6] over various system interfaces such as the /sys/class/power_supply filesystem, and it also supports asynchronous battery status change notifications which can be used by battery.el to update its mode line string without polling. [6]: https://xkcd.com/927/ HTH, -- Basil