- cross-posted to:
- linuxfurs@pawb.social
- cross-posted to:
- linuxfurs@pawb.social
(not really pipewire itself but an interaction with wireplumber/libcamera/the kernel, but pipewire is what triggers the problem)
As seen in https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2669 and https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4115
The camera’s /dev/video file is kept open (without streaming), sadly causing the camera to be powered on what looks to be most devices. For some reason, this completely nullifies the soc power management on modern laptops and can result in increases from 3W to 8W at idle!
On Intel laptops it’s a bit easier to debug because you can see the Cstates in powertop not going low but it also wrecks AMD ones. Some laptops can reach lower cstates, but the camera module wastes a few W anyway.
I can’t believe this shipped in Ubuntu, Fedora etc without anyone noticing, and for so long. This bug is quite literally wasting GWh of power and destroys the user experience of distros in laptops.
If you have a laptop with a switch that detaches the camera from the usb bus you are probably out of the water, just plug it when you use it and the problem is sidestepped. Removing uvcvideo and modprobing it on demand can also work. Disabling the camera in Lenovo’s UEFI is what I did for a year until I finally found the issue on the tracker. Some laptops also seem to not be affected, but for me it happens to every machine I’ve tested.
Thanks to this comment for another workaround that tells wireplumber to ignore cameras. ~/.config/wireplumber/wireplumber.conf.d/10-disable-camera.conf
wireplumber.profiles = { main = { monitor.libcamera = disabled } }
Software that only captures cameras using pipewire is rare and this hasn’t given me any problem. This should probably be shipped by distros while the problem is sorted out.
Note that most laptops will have other problems stopping them from reaching deep cstates, borked pcie sd card readers, ancient ethernet nics that don’t support pcie sleep properly, outdated nvme firwmare… those are separate issues that most of the time can also be tackled with some dose of tlp, but it’s all for nothing if the usb camera is keeping the soc awake!
Meanwhile in Fedora KDE, I have the opposite problem… The system straight up ignores my monitor sleep settings, and something as quick as grabbing a water and coming back to everything in sleep mode on a desktop is kinda a problem when I am relying on the system not going sleep due to a running task.
Same here. I have a 2021 dell xps
Interesting… I’ve never had this issue in Fedora KDE, which I run on my PC, but exactly the same thing happens on my wife’s PC and the HTPC which both run Xubuntu. Tried setting screen saver, power save options and eventually even uninstalling the screensaver completely. At least in my case it’s caused by Xorg DPMS if I remember correctly. Fixed it a while ago but then it came back on one of the computers at some point. Check out https://wiki.archlinux.org/title/Display_Power_Management_Signaling if it could be the same for you.
Sleep mode seems to be working well for me on fedora atomic with kde (aurora).
Deep sleep works well and can stay sleeping for days.
Normally sleep rules are working well. The do not sleep toggle in the power menu also works to prevent it from sleeping.
Only thing that doesn’t work is flatpak apps can’t prevent the system from sleeping, so watching a video, using Handbrake to encode etc will all just allow it to sleep if there is no physical input.
I have a 2018 dell xps
Have you looked into the “Activity” settings within system settings already? When you click on the default activity there you should see the option “Automatically shutting down or sleeping”. I’m sure you already tinkered with the energy system-settings.
Easy fix if nothing works. Find the specific pipewire-version that causes the webcam bug, compile and install it, possibly render your sound settings partially defunct on the way and hook up a webcam. Thank me later.