Hi, (I will leave the ACPI related questions for Rafael, but can try to help with some of the questions) On Thu, Feb 24, 2022 at 10:53:32AM -0600, Carl Edquist wrote: > My thoughts about this though - > > I did not really expect to get this interface back after I read the commit > message for its removal. I admire your fidelity to the linux user promise, > but I don't want to create trouble for you guys either. > > I am happy to put in the legwork to get wmpower working using whatever the > blessed replacement is for the acpi procfs power stuff. Maybe you can help > shed some light on the sysfs interface for me. FWIW the power-supply sysfs API exists since quite some time now (4a11b59d8283 from 2007), so it's not particularly new ;) > I started exploring a bit under /sys/class/power_supply, looking for > replacements for the "present rate" and "last full/remaining capacity" items > under /proc/acpi/battery. Curiously I have two lenovo ThinkPads, a T510 and > a T540p, and one of them has current_now & charge_full/_now, and the other > has power_now & energy_full/_now. Are these the only two possibilities for > rate & capacity? Or are there other potentially others? That is because the power-supply subsystem passes through the data provided by the hardware without unit conversion. So one of the battery fuel gauges in your laptops provides its numbers in Wh and one provides it in Ah. In (non ACPI) embedded systems you might also get neither of them. The units for the sysfs files are fixed, so a system reporting Ah provides current_now/charge_now files and Wh based systems provide power_now/energy_now files. > I guess the convenient thing about the /proc/acpi/battery interfaces is that > it automatically presents the right info for rate & capacity. > > (I felt like I was losing my mind for a bit when I saw the units presented > as "mAh" in one after I was sure I had read "mWh" before... But reading your > patch helped give me a better clue about what was going on there.) The files in /sys/class/power_supply always report almost all values in µ units (i.e. µA, µV, µAh, µW, ...), one value per file and with fixed units. Documentation can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-class-power > I'm also curious, is the "BAT[0-*]" pattern for battery names consistent, or > are there other possibilities? I had suspected "AC" was the standard > power_supply name for the main AC power, but that turned out not to be the > case on another (HP) laptop that I took a look at. Which leads me to > suspect that "BATX" is not necessarily standard either. The subsystem does not have any name constraints. But you can find the device type via the 'type' file and non-system level devices (e.g. battery of a game controller) set the 'scope' property to "Device". > I'm also thinking to enumerate batteries & AC power supplies via > /sys/bus/acpi/drivers/{ac,battery} rather than /sys/class/power_supply, as > surprisingly even a USB-C stick can show up under power_supply, and it's not > obvious if there's a clean way to sort out what's what then. USB-C is kind of tricky with the option to reverse power-flow in many cases (e.g. laptop can charge a power bank or power bank can charge a laptop using the same connector). In general you definetly can get non-ACPI power-supply devices, e.g. batteries from wireless keyboards. Also some devices have broken ACPI battery handling, so the ACPI driver is blacklisted and native hardware drivers are used instead. In that case you will not find anything power related in /sys/bus/acpi. -- Sebastian > I say all this of course as a laptop end-user, and even with the kernel > source docs in front of me I seem to be feeling my way around in the dark. I > don't know much about the linux acpi internals, and I did not learn about > the acpi procfs power interface being deprecated until after wmpower stopped > working for me this month :) > > It seems like part of the difficulty is that there is not much of a feedback > loop for end users to realize that they are using deprecated procfs > interfaces, whether directly in custom battery scripts that scrape > /proc/acpi/battery, or unwittingly through other programs they happen to use > (in this case wmpower). There are no warnings until it's too late. > > And even taking a look at what happened the first time it was removed [1], > it seems the conclusion was "some people are still using programs that rely > on the interface, so we'll add it back" ... But it's not obvious if any > effort was made to contact maintainers with a little nudge, to let them know > that it's (still) deprecated and what the replacement interface is. > > Not sure what the general solution is there, but in any case I'll cheerfully > fix up wmpower. > > > Thanks again and sorry for the long mail :) > > Carl > > > [1] https://lkml.org/lkml/2014/4/21/152 > CC [M] drivers/acpi/ac.o > In file included from ./include/linux/kernel.h:29, > from drivers/acpi/ac.c:11: > drivers/acpi/ac.c: In function 'acpi_ac_add_fs': > drivers/acpi/ac.c:182:29: error: expected ')' before 'PREFIX' > 182 | printk(KERN_WARNING PREFIX "Deprecated procfs I/F for AC is loaded," > | ^~~~~~ > ./include/linux/printk.h:418:25: note: in definition of macro 'printk_index_wra' > 418 | _p_func(_fmt, ##__VA_ARGS__); \ > | ^~~~ > drivers/acpi/ac.c:182:9: note: in expansion of macro 'printk' > 182 | printk(KERN_WARNING PREFIX "Deprecated procfs I/F for AC is loaded," > | ^~~~~~ > ./include/linux/printk.h:418:24: note: to match this '(' > 418 | _p_func(_fmt, ##__VA_ARGS__); \ > | ^ > ./include/linux/printk.h:446:26: note: in expansion of macro 'printk_index_wrap' > 446 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__) > | ^~~~~~~~~~~~~~~~~ > drivers/acpi/ac.c:182:9: note: in expansion of macro 'printk' > 182 | printk(KERN_WARNING PREFIX "Deprecated procfs I/F for AC is loaded," > | ^~~~~~
Attachment:
signature.asc
Description: PGP signature
