Lemmy.World

166,306 readers
7,276 users here now

The World's Internet Frontpage Lemmy.World is a general-purpose Lemmy instance of various topics, for the entire world to use.

Be polite and follow the rules โš– https://legal.lemmy.world/tos

Get started

See the Getting Started Guide

Donations ๐Ÿ’—

If you would like to make a donation to support the cost of running this platform, please do so at the following donation URLs.

If you can, please use / switch to Ko-Fi, it has the lowest fees for us

Ko-Fi (Donate)

Bunq (Donate)

Open Collective backers and sponsors

Patreon

Liberapay patrons

GitHub Sponsors

Join the team ๐Ÿ˜Ž

Check out our team page to join

Questions / Issues

More Lemmy.World

Follow us for server news ๐Ÿ˜

Mastodon Follow

Chat ๐Ÿ—จ

Discord

Matrix

Alternative UIs

Monitoring / Stats ๐ŸŒ

Service Status ๐Ÿ”ฅ

https://status.lemmy.world

Mozilla HTTP Observatory Grade

Lemmy.World is part of the FediHosting Foundation

founded 1 year ago
ADMINS
1
 
 

cross-posted from: https://lemmy.blahaj.zone/post/15137437

(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!

2
 
 

(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!

view more: next โ€บ