ChromeOS bug: http://code.google.com/p/chromium/issues/detail?id=221562 Quoting comments #12 and #13 there: """ Bisecting is proving difficult because the UI isn't coming up on vanilla kernels either, need to investigate that separately as I'm pretty sure it used to work. I looked at this for a while with marcheu@ and it looks like this really only works when we do a powerd_suspend because that also does a vt-switch. So, basically all Sandy and Ivy Bridge platforms seem to be totally broken in any of our normal resume paths, either lid suspend or idle suspend. The new drm code appears to look at the state of the hardware and sees that the lvds pipe and transcoder are off and doesn't attempt to set them, whereas on the 3.4 kernel it was forcing them on at resume time. Our firmware does nothing with respect to setting up the display hardware, and we think that the kernel is expecting it to be set up. specifically we're talking about __i915_drm_thaw() calling intel_modeset_setup_hw_state() which is now looking at hardware state prior to doing any mode setting. """ """ after marcheu spoke with upstream Intel folks, it looks like the issue isn't a firmware issue but rather that they are expecting a VT switch after suspend to set the mode, and ChromeOS doesn't do this in normal mode on a lid close (I believe to save time). If you just call powerd_suspend from the command line, however, you will get a vt switch and this is why that scenario was apparently working. """
Note that this applies to the 3.8 kernel, and represents a regression observed when upgrading from 3.4.
The code restores the mode as set on suspend. The likely cause here is that userspace is not turning the displays back on as it does not get the lid-open event...
Not on 3.7 and 3.8, there we rely on fbcon/vt-switching to restore the mode config. So this is only broken when patching the kernel with vt-switchless suspend/resume patches, which was not supported in upstream until 3.10. Hence closing as fixed (and never really broken in upstream kernels). Aside: There's imo no reason to let such features linger in some random product trees, pushing this upstream would have avoided this waste of time on everyone's side ...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.