(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!
that is such a bad response, mindboggling.
Hey not a problem dino, I get it your post is quite helpful.
Now jog my memory, how did you help the person asking if they’re affected by this bug or not?
The 13 others that have a problem with my question also chose to not offer anything useful for ops question.
First problem is, how would you know if your battery life has been halved? Are you keeping track of how long your battery lasts on a daily basis?
Pipewire is not an app, it’s a system service. It’s not like people are going to say, “i’m gonna install pipewire” and then go install pipewire and also happen to have stats from before and after that installation.
Most people who have pipewire have it either by having it already installed as part of the initial installation or part of some larger update, but in either case, they probably aren’t particularly aware of it, especially as long as things are functional.
To answer the question whether it affects one’s system requires a different strategy than and likely a little bit of research.
Thank you for the reply. You are correct, I understand it’s a system service and something that people wouldn’t really notice if it’s been updated or maybe their distro has recently migrated over from pulse audio. Hell maybe even unknowingly following some random guide while trying to do something or fix something. All that we know from OP is that they are asking how to tell if they are affected.
My question was as basic and as generic as it could be. Has your battery life been quite poor as of late? As in have you had to plug in your system more throughout the day?
Regardless of technical experience or aptitude most people would notice a change in the norm of using something they use daily. If they don’t, there wouldn’t be any questions and it would be the normal day to day.
Now my thought process was to see what they said, yes or no for the battery life. And then to get more info to put together something they could follow and either confirm impact from the bug or not.