[Pyro] Internal display brightness is '0' after Suspend/Resume the device |
|||||||||||
Issue descriptionChrome Version: 61.0.3142.0 OS: 9701.0.0 dev-channel pyro What steps will reproduce the problem? (1) Sign in to device (2) Suspend the device using 'powerd_dbus_suspend' command from crosh terminal (3) Resume the device Note: Also seen with set_short_powerd_timeouts command and when close/open the lid What is the expected result? Internal & external display should come up with default brightness What happens instead? Internal display is black and looks like brightness zero. Please use labels and text to provide additional information. logs and screenshot attached. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Jun 30 2017
,
Jul 1 2017
,
Jul 5 2017
Tested with today's ToT 9715.0.0, 61.0.3147.0 and observed that the issue is seen by suspend/resuming the device itself, not just connected to external monitor. Updated the description and title.
,
Jul 5 2017
,
Jul 5 2017
,
Aug 4 2017
A ping as we're working to eliminate the list of M61 Beta blockers. This one is a bit stale. Thanks bunches...
,
Aug 4 2017
,
Aug 8 2017
Ping since we're planning a Beta release next week. Can we escalate since this is tagged as a beta blocker? IMing marcheu@ as well; thanks :-)
,
Aug 8 2017
Someone on the graphics side needs to take a look. powerd.LATEST suggests that the brightness is being restored, at least from userspace's perspective (and that code hasn't changed in forever): [0630/160948:INFO:internal_backlight_controller.cc(682)] Setting brightness to 0 (0%) over 0 ms [0630/160949:INFO:internal_backlight_controller.cc(699)] Setting resume brightness to 24284 (63%) [0630/160949:INFO:suspend_delay_controller.cc(140)] Announcing suspend request 55574530 with 3 pending delay(s) and 0 outstanding delay(s) from previous request [0630/160949:INFO:suspend_delay_controller.cc(86)] Got notification that delay 55574531 (trunksd) is ready for suspend request 55574530 from :1.28 [0630/160949:INFO:suspend_delay_controller.cc(86)] Got notification that delay 55574529 (shill) is ready for suspend request 55574530 from :1.9 [0630/160949:INFO:audio_client.cc(126)] Updated audio devices: headphones unplugged, HDMI inactive [0630/160949:INFO:daemon.cc(1396)] Chrome is using presentation display mode [0630/160949:INFO:suspend_delay_controller.cc(86)] Got notification that delay 55574530 (chrome) is ready for suspend request 55574530 from :1.10 [0630/160949:INFO:suspend_delay_controller.cc(232)] Notifying observers that suspend is ready [0630/160949:INFO:suspender.cc(473)] Starting suspend [0630/160949:INFO:main.cc(257)] Running "/usr/bin/powerd_setuid_helper --action=suspend --suspend_wakeup_count_valid --suspend_wakeup_count=82 --suspend_to_idle" [0630/160957:INFO:daemon.cc(698)] powerd_suspend returned 0 [0630/160957:INFO:suspender.cc(429)] Finishing request 55574530 successfully [0630/160957:INFO:internal_backlight_controller.cc(682)] Setting brightness to 24284 (63%) over 0 ms
,
Aug 8 2017
Stéphane Marchesin called out that this is being fixed by Intel (per my IM); need to monitor / test / unblock.
,
Aug 10 2017
Hi all, we're targeting a Beta next week so we need fixes and/or workarounds submitted by COB Monday 8/14 if this is still considered a beta blocker. Possible? Thanks!
,
Aug 15 2017
I am not able to reproduce the issue in Chrome OS 9765.29.0, 61.0.3163.47.
,
Aug 16 2017
marcheu@ based on comment 13, do we think this issue might have been resolved?
,
Aug 17 2017
,
Aug 17 2017
Why duped to Candy(after recovery) issue?
,
Aug 17 2017
This is different from candy's issue
,
Aug 17 2017
Actually no, it's the same thing as well; so we're all good. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by pgangishetty@chromium.org
, Jun 30 2017