[Scarlet-DRU] Device does not wake up/resume with KB/Mouse press |
|||||
Issue descriptionChrome Version: 71.0.3578.94 OS: 11151.59.2 What steps will reproduce the problem? Scenario 1: (1) Sign in to tablet/device (2) Connect USB keyboard & mouse to tablet using Type C adapter (used UGreen type C adapter) (3) Suspend the device using 'powerd_dbus_suspend' from crosh terminal or leave the device idle and let it suspend (4) Once device suspends ~15+ seconds, try to resume using KB/Mouse press or short press on power button Scenario 2: (1) Sign in to tablet/device (2) Connect USB keyboard, Mouse & External monitor (HDMI) to tablet using Type C adapter (used UGreen type C adapter & ASUS PB 278Q monitor and ACER 4K monitor) (3) Suspend the device using 'powerd_dbus_suspend' from crosh terminal or leave the device idle and let it suspend (4) While suspended unplug HDMI cable (External Monitor) from Type C adapter and try to resume using KB/Mouse press or short press on power button. What is the expected result? Device/Tablet should wakeup/resume with KB/mouse press or short press of power button What happens instead? Device does not wakeup/resume with keyboard/mouse press Note: (1) Device wakes up when short pressed on power button ONLY in scenario 1 (2) Scenario 2 - Internal Display backlight illuminates but screen is black with short press of power button, but wakes up when plugged back the HDMI cable to Type C adapter. Please use labels and text to provide additional information. Logs and screenshot attached. If this is a regression (i.e., worked before), please consider using the bisect tool (https://www.chromium.org/developers/bisect-builds-py) to help us identify the root cause and more rapidly triage the issue. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Dec 18
Derek can you have a look?
,
Dec 18
,
Dec 18
Can we confirm if this workflow is common enough to warrant the RBS? Also, did you bisect to confirm if it's in 11151.59.0? Thanks
,
Dec 18
Can we confirm that this worked correctly in previous versions? It should not be affected by recent FW changes
,
Dec 18
Tried 11151.59.0, the one running on scarlet stable channel. USB-KB-wake doesn't work either. At least 11151.59.2 is not any worse than current running image.
,
Dec 18
Same behavior with stable build version 11151.59.0/71.0.3578.94. Will check on M70 Stable and update the results shorlty.
,
Dec 18
Scenario 1: WAI -- USB wake up is disabled on scarlet. -- b/72676156 -- b/37724105
,
Dec 18
Don't bother testing older versions of the firmware. I know exactly what caused this. This is caused by disabling PP900_S0 during S3. Originally, we planned to detect USB input devices and not disable PP900_S0 during S3 in that case. There was also a possibility of using the EC or something to detect USB wake events. We never addressed this because it was never a high priority.
,
Dec 18
Since this isn't a new regression, and the severity is minimal, can we remove this as a release blocker?
,
Dec 18
Same behavior on M70 build 70.0.3538.110/11021.81.0
,
Dec 18
,
Dec 19
What are next steps to resolving then? I'd guess 1. Determine amount of work & feasibility of implementing smarts for keeping pp900 rail on 2. Quantify power / battery life impact. 3. Determine need for USB wake feature from the users perspective for this device. If we end up deciding not to pursue ... lets document somewhere ( go/cros-waivers ? ) |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by pgangishetty@chromium.org
, Dec 18