2 ms·

> Is it all Intel? That's excellent! Yes. > Tricky question, do you get battery discharge events via ACPI (run acpid, and unplug)? I got this: $ acpi // p

by eustar 10y ago

> Is it all Intel? That's excellent! Yes. > Tricky question, do you get battery discharge events via ACPI (run acpid, and unplug)? I got this: $ acpi // plugged in Battery 0: Unknown, 100% $ acpi // unplugged Battery 0: Discharging, 99%, 83:38:49 remaining > What material are keycaps made of? Plastic. Edit: Just saw that you meant acpid. With acpid nothing happened: $ acpi $ acpi -f // to run in foreground $ Is this normal? I checked also the dir where acpid should save its event file (/proc/acpi/events) but there was nothing. However, suspend on lid close and wakeup on lid open works very good and fast (much faster than with the prior windows installation, tried with i3). I don't know if this is related to the acpi events.

nextos 10y ago
Thanks for checking this. Very few laptops support this, and its badly documented. But it's IMHO the difference between good and superb Linux support. Run sudo acpid, will start the daemon in the background. Then run acpi_listen. It will block waiting for events. E.g. if you press media keys, un/plug the adapter, etc you should start seeing events. One per line. Just leave it running on battery for a while. Hopefully it has events at 1% or 5% discharge intervals. Or at least for critical battery levels, when you cross the 10% or 5% level. Emergency thresholds can be usually controlled through a variable in sysfs. These events are needed to write udev rules that get fired by the kernel. Thanks!
- eustar 10y ago
  Ok, thanks for the instructions! It seems to work, this time I did 'sudo acpid' and 'acpi_listen' gave me following output (scroll the code field below to the right in case my comments there are hidden): // Notebook was at the beginning unplugged $ acpi_listen ^[[14~^[[15~^[[20~ac_adapter ACPI0003:00 00000000 00000001 // I pressed three media keys and plugged in the power adapter battery PNP0C0A:00 00000080 00000001 battery PNP0C0A:00 00000081 00000001 processor LNXCPU:00 00000080 00000005 processor LNXCPU:01 00000080 00000005 processor LNXCPU:02 00000080 00000005 processor LNXCPU:03 00000080 00000005 processor LNXCPU:00 00000081 00000000 processor LNXCPU:01 00000081 00000000 processor LNXCPU:02 00000081 00000000 processor LNXCPU:03 00000081 00000000 ac_adapter ACPI0003:00 00000000 00000000 // unplugged the power adapter again battery PNP0C0A:00 00000080 00000001 battery PNP0C0A:00 00000081 00000001 processor LNXCPU:00 00000081 00000000 processor LNXCPU:01 00000081 00000000 processor LNXCPU:02 00000081 00000000 processor LNXCPU:03 00000081 00000000 ^C I'll try this at lower battery levels again tomorrow (since the battery is charged now). But it seems that the system emits charge and discharge acpi events.
  - nextos 10y ago
    Great! It'd be superb to confirm the laptop ACPI emits discharge events every once in a while, or when a threshold level is reached. Then you can write really neat udev rules. Plug n unplug events are more common. Battery ones are quite infrequent.

by eustar 10y ago

nextos 10y ago

Thanks for checking this. Very few laptops support this, and its badly documented. But it's IMHO the difference between good and superb Linux support. Run sudo acpid, will start the daemon in the background. Then run acpi_listen. It will block waiting for events. E.g. if you press media keys, un/plug the adapter, etc you should start seeing events. One per line. Just leave it running on battery for a while. Hopefully it has events at 1% or 5% discharge intervals. Or at least for critical battery levels, when you cross the 10% or 5% level. Emergency thresholds can be usually controlled through a variable in sysfs. These events are needed to write udev rules that get fired by the kernel. Thanks!

eustar 10y ago
Ok, thanks for the instructions! It seems to work, this time I did 'sudo acpid' and 'acpi_listen' gave me following output (scroll the code field below to the right in case my comments there are hidden): // Notebook was at the beginning unplugged $ acpi_listen ^[[14~^[[15~^[[20~ac_adapter ACPI0003:00 00000000 00000001 // I pressed three media keys and plugged in the power adapter battery PNP0C0A:00 00000080 00000001 battery PNP0C0A:00 00000081 00000001 processor LNXCPU:00 00000080 00000005 processor LNXCPU:01 00000080 00000005 processor LNXCPU:02 00000080 00000005 processor LNXCPU:03 00000080 00000005 processor LNXCPU:00 00000081 00000000 processor LNXCPU:01 00000081 00000000 processor LNXCPU:02 00000081 00000000 processor LNXCPU:03 00000081 00000000 ac_adapter ACPI0003:00 00000000 00000000 // unplugged the power adapter again battery PNP0C0A:00 00000080 00000001 battery PNP0C0A:00 00000081 00000001 processor LNXCPU:00 00000081 00000000 processor LNXCPU:01 00000081 00000000 processor LNXCPU:02 00000081 00000000 processor LNXCPU:03 00000081 00000000 ^C I'll try this at lower battery levels again tomorrow (since the battery is charged now). But it seems that the system emits charge and discharge acpi events.
- nextos 10y ago
  Great! It'd be superb to confirm the laptop ACPI emits discharge events every once in a while, or when a threshold level is reached. Then you can write really neat udev rules. Plug n unplug events are more common. Battery ones are quite infrequent.