PSA: wireplumber / pipewire substantially draining battery life on laptops

Operating Systems & Open Source Linux
, ,
1

[While running Arch Linux - EndeavourOS actually on a Lenovo Z16 gen 1 AMD 6950H laptop. Note, Intel laptops can be affected.]

The problem

Thanks to the reddit poster p4block on r/linux for bringing it to my attention. There are two bugs filed on pipewire as yet unresolved.

Currently wireplumber / pipewire hold open the /dev/videoX device handles for all webcams, blocking the camera, USB hardware, and the CPU hardware from sleeping and the CPU from reaching deeper sleep states.

I was able to extend my battery life by approximately 30-40%!

Am I affected?

To check use powertop. If it shows your webcams to be 100% active despite no programs open, and not streaming video, and no camera activity light this may be affecting you.

Another way is to test each camera device file with fuser to see if any program/process has opened it. (Replace video0 with all of your webcams, my Z16 has two, the IR one, and the visible light one):

$ fuser /dev/video0

/dev/video0:             2473

$ ps 2473
    PID TTY      STAT   TIME COMMAND
   2473 ?        S<sl   4:37 /usr/bin/pipewire

NOTE: You may see wireplumber holding the camera device file open in more modern versions

Workaround until a proper fix

[While this workaround affects pipewire, it typically does not matter as most software does not use pipewire to access the camera.]

The workaround from Romeo Valentin here worked for me to cut power consumption by >3W when the laptop is not asleep, generally from 10W → 6W. That is almost a 40% increase in battery life.

The temporary fix is to create these directories and file in your home directory and restart wireplumber

$ mkdir -p ~/.config/wireplumber/wireplumber.conf.d
$ nano ~/.config/wireplumber/wireplumber.conf.d/10-disable-camera.conf

Paste:

wireplumber.profiles = {
  main = {
    monitor.libcamera = disabled
  }
}

then restart wireplumber:

$ systemctl --user restart wireplumber.service

Then check with powertop or the fuser test. It should show the cameras asleep after a minute or so.

3 Likes
2

Lotta cause for concern here from a security standpoint. Would like to see who pushed the code that causes this and if they happen to have an account with OPM.

2 Likes
3

It’s an interesting question: how much of the camera is on? All of it? The camera light doesn’t go on, but sadly that led is triggered by software/firmware in many cases, not hardware.

If it was just the USB bus to the SoC then where is all that power going? Is the camera sensor active and scanning, but the data black holed in the camera, which is why the LED stays off?

Pity my screen is glued together as this would be an easy one to probe with an oscilloscope to at least get some clue.

4

I once saw an attack where /dev/null was redirected to a log file. The attack was to go after the clipboard buffer hoping contents were dumped to /dev/null when overwritten and not just freed (it doesn’t) but the other things being dumped were of value. Not a feasible attack as it generated a TON of unusable traffic and regex parsers ran against /dev/null ate CPU like mad, but still nifty.

1 Like