Hacker News Reader

Comment by nextos | Hacker News Reader

Is it all Intel? That's excellent!

I presume you can get every component into powersaving states (which you can monitor with powertop).

Tricky question, do you get battery discharge events via ACPI (run acpid, and unplug)? That's the gold standard for uber good Linux support, and allows for neat udev rules to be written.

What material are keycaps made of?

View on HN

> 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.

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!

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.

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.

Reply on news.ycombinator.com