Created attachment 31008 [details]
On my Samsung Q45 with Intel GM965 graphics I encounter the following problem when using KMS:
After a suspend/resume cycle the internal LVDS always gets enabled, whether it was on before or not.
State before suspend/resume: LVDS: off / VGA: 1600x1200
State after resuming from suspend: LVDS: 1280x800 / VGA: 1600x1200
"xrandr --query" reports that the LVDS is off and it is not possible to turn it off by issuing "xrandr --output LVDS --off"
To finally turn the LVDS off it needs to be "enabled" first by using "xrandr ... --auto".
Afterwards it is possible to really turn it off.
- LVDS stays off after resume when it was off before
If the displays are configured the other way round (VGA off/LVDS on) a suspend/resume cycle does not enable the VGA output.
Created attachment 31009 [details]
Created attachment 31010 [details]
Created attachment 31011 [details]
xrandr query after resume
Do you happen to know if this bug was introduced in a recent kernel revision?
If so, we may be able to bisect the kernel to find the bad commit.
I just tried different versions and found that this bug was introduced
with version 2.6.31-rc3.
With rc2 the LVDS stays of after resuming.
(In reply to comment #5)
> I just tried different versions and found that this bug was introduced
> with version 2.6.31-rc3.
> With rc2 the LVDS stays of after resuming.
Thanks for the additional information.
This sounds like a bug that's in Jesse's area, (or if no he might know who
can handle it best), so I'll assign it to him.
Ah yeah, we may force LVDS back on now that we listen for lid events (which are sometimes generated at resume). I'll have to come up with a better way of restoring the suspend config by ignoring spurious enables at resume.
Does this still occur with 2.6.33-rc kernels? We may need to add a quirk for your lid if it's generating spurious events. Please attached the output of dmidecode to this bug.
I just tested with 2.6.33-rc6 and it just works fine, so the bug can be closed.
for the sake of completeness I'll however attach the dmidecode info.
Created attachment 33127 [details]
Thanks for the update.