power_manager : whitelist by default USB devices that expose an audio class |
|||
Issue descriptionRight now the power manager policy for USB devices is that we only autosuspend devices on a vid:pid whitelist. Little history here: this is because we only really trust that autosuspend is implemented properly on usb devices we have thoroughly debugged, we maintain a whitelist of devices that originally contained a list of devices that came standard on Chromebooks, Chromeboxes, Chromebits, Chrome slates, etc. Lots of random USB devices (most glaringly USB HID devices such as mice and keyboard) would miss keystrokes or button presses if we dropped into autosuspend during normal operation. In recent years, with the advent of digital USB-C audio devices such as C-to-3.5mm adapters, and USB-C digital headphones, we want to make sure that we *do* enter autosuspend with external audio devices. We started this by adding to the whitelist first party Google USB-C audio devices, and then moved on to 3rd party ones from Made for Google partners. I think it may be time to just whitelist the entire class of devices so we don't have to go through one by one. Possible side effects: Badly designed USB audio devices may misbehave. I could imagine some headphones were never tested with autosuspend, and their buttons may not work, or they may not properly wake from suspend state when asked to, but it's better to expose the bad devices and get the ecosystem on board with proper power management than to give devices a pass by leaving them on full power all the time.
,
Nov 13
Found a relevant discussion for JACK and pulseaudio: https://forum.manjaro.org/t/usb-audio-interface-not-staying-powered-on/23684/3 Audio devices will enter auto suspend with if they fall into certain category.
,
Nov 13
+achant tells me Android already does this for audio class devices.
,
Jan 15
Benson is this something you have time to implement? On side-effects would we potentially blacklist devices found to be malfunctioning after autosuspend? |
|||
►
Sign in to add a comment |
|||
Comment 1 by dgreid@chromium.org
, Nov 13