System exits docked mode and tries to suspend when using Cable Matters USB-C adaptor |
|||
Issue descriptionFrom http://feedback/#/Report/85040533043 (eve 64.0.3282.134 beta): "1. I docked my Pixelbook to power, display, keyboard, and trackpad using this device: http://a.co/0amLp13 2. I closed the Pixelbook and used it with the external display/input devices. 3. I set go/keepawake to keep the system awake (sunset icon). 4. I locked my screen and went to lunch. 5. I came back and pressed a bunch of keys on the external keyboard. Nothing happened, indicating that the system was asleep. 6. I had to open up the Pixelbook to wake it, after which I filed this report." I think that is when the screen was locked: [0208/114447:INFO:daemon.cc(1436)] Received updated external policy: ac_dim=30s ac_screen_off=40s ac_lock=50s ac_idle_warn=0s ac_idle=30m battery_dim=30s battery_screen_off=40s battery_lock=50s battery_idle_warn=0s battery_idle=6m30s ac_idle=suspend battery_idle=suspend lid_closed=suspend system_wake_lock=1 use_audio=1 use_video=1 presentation_factor=2.0 user_activity_factor=2.0 wait_for_initial_user_activity=0 force_nonzero_brightness_for_user_activity=1 (Prefs, extension) [0208/114447:INFO:state_controller.cc(833)] Updated settings: dim=1m screen_off=1m10s lock=1m20s idle_warn=0s idle=30m30s (suspend) lid_closed=n o-op use_audio=1 use_video=1 [0208/114447:INFO:state_controller.cc(845)] Wake locks: system ... [0208/114546:INFO:state_controller.cc(89)] Dimming screen after 1m [0208/114556:INFO:state_controller.cc(89)] Turning screen off after 1m10s ... [0208/114606:INFO:state_controller.cc(89)] Locking screen after 1m20s That's all as expected, but this is weird: [0208/120105:INFO:activity_logger.cc(20)] User activity reported [0208/120105:INFO:state_controller.cc(96)] Undimming screen [0208/120105:INFO:state_controller.cc(96)] Turning screen on [0208/120105:INFO:display_power_setter.cc(81)] Asking DisplayService to turn internal display off and external displays on [0208/120105:INFO:audio_client.cc(125)] Updated audio devices: headphones unplugged, HDMI active [0208/120105:INFO:daemon.cc(1418)] Chrome is using presentation display mode [0208/120106:INFO:audio_client.cc(125)] Updated audio devices: headphones unplugged, HDMI inactive [0208/120106:INFO:daemon.cc(1418)] Chrome is using normal display mode [0208/120106:INFO:state_controller.cc(833)] Updated settings: dim=1m screen_off=1m10s lock=1m20s idle_warn=0s idle=30m30s (suspend) lid_closed=suspend use_audio=1 use_video=1 [0208/120106:INFO:state_controller.cc(845)] Wake locks: system [0208/120106:INFO:state_controller.cc(941)] Turning panel on after leaving docked mode [0208/120106:INFO:display_power_setter.cc(81)] Asking DisplayService to turn all displays on [0208/120107:INFO:internal_backlight_controller.cc(677)] Setting brightness to 35440 (75%) over 0 ms [0208/120107:INFO:keyboard_backlight_controller.cc(519)] Setting brightness to 60 (60%) over 0 ms [0208/120107:INFO:state_controller.cc(988)] Ready to perform lid-closed action (suspend) [0208/120107:INFO:suspender.cc(383)] Starting request 75235344 [0208/120107:INFO:daemon.cc(595)] Reading wakeup count from /sys/power/wakeup_count [0208/120107:INFO:daemon.cc(599)] Read wakeup count 30 [0208/120107:INFO:internal_backlight_controller.cc(677)] Setting brightness to 0 (0%) over 0 ms [0208/120107:INFO:internal_backlight_controller.cc(693)] Setting resume brightness to 35440 (75%) [0208/120107:INFO:keyboard_backlight_controller.cc(519)] Setting brightness to 0 (0%) over 0 ms [0208/120107:INFO:suspend_delay_controller.cc(137)] Announcing suspend request 75235344 with 3 pending delay(s) and 0 outstanding delay(s) from previous request [0208/120107:INFO:input_device_controller.cc(292)] Configuring devices for mode "closed" The Keep Awake extension was still working as expected (per "Wake locks: system"), and it looks like powerd did the right thing as well. The problem is the "Chrome is using normal display mode" line. Chrome reported that it no longer had an external display connected, so powerd left docked mode and tried to suspend immediately due to the lid being closed. After powerd finished reconfiguring input devices, Chrome reported that the external display was connected again: [0208/120107:INFO:daemon.cc(1418)] Chrome is using normal display mode [0208/120107:INFO:suspend_delay_controller.cc(86)] Got notification that delay 75235330 (shill) is ready for suspend request 75235344 from :1.12 [0208/120107:INFO:suspend_delay_controller.cc(86)] Got notification that delay 75235331 (trunksd) is ready for suspend request 75235344 from :1.22 [0208/120108:INFO:daemon.cc(1418)] Chrome is using presentation display mode [0208/120108:INFO:state_controller.cc(833)] Updated settings: dim=1m screen_off=1m10s lock=1m20s idle_warn=0s idle=30m30s (suspend) lid_closed=no-op use_audio=1 use_video=1 [0208/120108:INFO:state_controller.cc(845)] Wake locks: system [0208/120108:INFO:state_controller.cc(941)] Turning panel off after entering docked mode [0208/120108:INFO:internal_backlight_controller.cc(693)] Setting resume brightness to 35440 (75%) [0208/120108:INFO:state_controller.cc(988)] Ready to perform lid-closed action (no-op) [0208/120108:INFO:input_device_controller.cc(292)] Configuring devices for mode "docked" Before Chrome reported that it was ready for suspend, the lid was opened, so the suspend request was aborted: [0208/120116:INFO:daemon.cc(515)] Lid opened [0208/120116:INFO:suspender.cc(345)] Aborting request in response to user activity [0208/120116:INFO:suspender.cc(414)] Finishing request 75235344 unsuccessfully [0208/120116:INFO:display_power_setter.cc(81)] Asking DisplayService to turn internal display off and external displays on [0208/120118:INFO:state_controller.cc(941)] Turning panel on after leaving docked mode [0208/120118:INFO:display_power_setter.cc(81)] Asking DisplayService to turn all displays on My guess would be that when user activity started, there was a race where Chrome briefly didn't see the external display and reconfigured to a single display as a result, and things went south from there. I believe this has been seen before.
,
Feb 9 2018
Thanks, more feedback reports usually help. :-) I think that http://b/71051757 is the bug I was thinking of tracking the same issue.
,
Feb 13 2018
who can we assign this bug to?
,
Feb 13 2018
Weidongg, can you please take a look?
,
Feb 21 2018
We recently have a fix for related issue ( issue 790720 ). I could not repro this on ToT build. Steps: With "Keep awake" extension disabled: 1. Lock the screen, wait for 5 minutes. The device is suspended. 2. Tap on the external keyboard, the device resumes. With "Keep awake" extension enabled: 1. Lock the screen, wait for 5 minutes, the device is still awake.
,
May 10 2018
Found an other feedback report with the same behavior. https://listnr.corp.google.com/report/85425988899
,
Oct 26
I think that http://b/118421985 is another instance of this happening. I'm not sure if the same adapter was being used there. Weidong, can you make another attempt to repro this? It sounds like it's happening frequently for dmargolis@, so maybe he can help.
,
Oct 29
yeah, quite frequently. Let me know if you need anything. May be a good chance to visit ZRH. ;)
,
Oct 29
Sorry for the delay, most of bandwidth is occupied with app list issues. I investigated a bit, and still cannot repro it with the following setup: 1. Connect eve to an external display and an external keyboard (without a hub). 2. Set go/keepawake to keep the system awake (sunset icon). 3. Dock the eve by closing lid. 4. Lock the screen by pressing Search+L key. 5. The external display turns black after about 1 min. 6. I keep waiting for >20mins. 7. Hit the keyboard. 8. The lock screen shows up on external display. I think either it is fixed on ToT, or it's caused by the hub. I will request two hubs (https://mystuff.corp.google.com/stuff/items/574 and https://mystuff.corp.google.com/stuff/items/1647) and test with it.
,
Nov 1
I just got the hub https://mystuff.corp.google.com/stuff/items/1647 and tested with ToT eve: 1. Connect eve to hub which connects to display (HDMI) and external keyboard. 2. Enter dock mode and go to lock screen, wait for 20min until display goes to sleep. 3. Tap keyboard and wait for <10s, the display resumes into lock screen. I think it might be fixed in ToT, or the hub issue?
,
Nov 1
That's not the hub I am using, FWIW. I am using https://www.amazon.com/Cable-Matters-Multiport-DisplayPort-Ethernet/dp/B06Y5N3YCD/ref=sr_1_9?s=electronics&ie=UTF8&qid=1541111251&sr=1-9&keywords=cable+matters+usb-c+hub .
,
Nov 2
Thanks for sharing the info, I requested it in guts ticket. Hopefully will get it in a few days.
,
Nov 2
If guts does not get you the right hub, please just purchase one and expense it.
,
Nov 5
abodenha@google.com: There is a flaw to that approach. With the CableMatters hub in particular, our USB-C team has actually worked directly with them and found a number of serious bugs in *their* firmware. In negotiating with them to get a hub that can be put onto go/stuff here, we've actually mandated that they reflash the hubs with updated firmware. The ones you can go out on Amazon and buy are very likely woefully out of date with respect to firmware (at least 6 firmware revisions I've seen). And unless you've got a spare Windows PC you have laying around with administrator privileges, we won't be reflashing any one you buy from Amazon.
,
Nov 6
Mine was purchased from Amazon. It's not in stock in ZRH. Is the point that there's no bug in ChromeOS, but rather, CableMatters has a bug? If so...what do we expect customers to do? Is this fundamentally unfixable in ChromeOS, or more a case of adhering to the standard? And, how can I get a hub with updated firmware? Are CableMatters selling them externally, or only on go/stuff in MTV? :)
,
Nov 6
dmargolis: We haven't had the time to completely debug the problem. It's not to say that there is no bug in Chrome OS. We just don't have the data right now to say one way or another, so anything we discuss at this point is purely speculative. What do we expect customers to do? Complain to the hub vendor, if the hub is truly broken. The hub will be available worldwide on stuff. https://mystuff.corp.google.com/stuff/items/1861
,
Nov 6
dmargolis: If some hub doesn't follow the USB standard for wakeup signals, there's nothing we can do. No hack that we can put in Chrome OS will make that hub work. I don't know if that is the case right now, but we will investigate.
,
Nov 6
Ok. I've had a chance to try this on a Pixel Slate today with the monitor I have (not the Acer B326HK, but a Google spec'd JN32A), with I think the same CableMatters hub that dmargolis has. I have not been able to reproduce the problem. However, the real problem is the monitor disconnecting from the system, which causes the system to suspend because the lid is closed. See Derat's analysis here: https://buganizer.corp.google.com/issues/118421985#comment5 Also, the disabling of USB input devices as wake sources when the lid is closed, but there is no external display is intentional. We have had more than a few cases where users left a wireless mouse dongle attached to their Chromebooks when they threw the laptop and their (still on) mouse in their bag, which would cause spurious wakeups while lid closed. If we're not connected to a display, all external USB wakeup sources are disabled, so that part is working as intended. As a policy, if the lid is closed and we're suspended and not in docked mode, external wakeup sources are limited. Let's try to find this Acer monitor and see if we can reproduce the disconnection during normal operation. Maybe the monitor is bad and drops into a low power mode that looks to the system like the display is disconnected.
,
Nov 7
Thanks for the explanation, Benson. Let me know if I can help in any other way.
,
Nov 20
I can no longer reproduce this after swapping my single-DisplayPort hub (https://mystuff.corp.google.com/stuff/items/1861) for the dual-DisplayPort model from the same vendor (https://mystuff.corp.google.com/stuff/items/1873). |
|||
►
Sign in to add a comment |
|||
Comment 1 by cdrichards@google.com
, Feb 9 2018