Summary: | [SNB HDMI/TV] Wrong colors after resume | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | John Obaterspok <john.obaterspok> | ||||||||||||
Component: | DRM/Intel | Assignee: | Daniel Vetter <daniel> | ||||||||||||
Status: | CLOSED FIXED | QA Contact: | |||||||||||||
Severity: | normal | ||||||||||||||
Priority: | medium | CC: | ben, chris, daniel, jbarnes, przanoni | ||||||||||||
Version: | unspecified | ||||||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||||
OS: | Linux (All) | ||||||||||||||
Whiteboard: | |||||||||||||||
i915 platform: | i915 features: | ||||||||||||||
Attachments: |
|
Description
John Obaterspok
2011-11-10 12:08:06 UTC
Created attachment 53431 [details]
lspci -vvnn output
Created attachment 53432 [details]
regdump 1 with good colors after reboot
Created attachment 53433 [details]
regdump 2 with good colors after reboot
Created attachment 53434 [details]
regdump 1 with bad colors after reboot
Created attachment 53435 [details]
regdump 2 with bad colors after resume
The regdump 1 & 2 with BAD colors were both after resume. NOT reboot as the the previous attachment said.
It seems the only thing that differs in the regdump is DSPASURF. Upon reboot it gets two different values: 0x04805000 0x04820000 when resuming from suspend it get the same value twice: 0x0104c000 Does this say something? Same problem happens when only using runlevel 3 and console. Once computer is resumed from pm-suspend the colors consist mainly of pink & green. I've noticed one more thing. If using X and I change to 1680x1050 I get the colors back fine. When changing back to 1920x1080 the colors are bad again. I also tried to pm-suspend with 1680x1050 while having good colors, on resume I can see the TV shows info about 1920x1080 and pink shades, five seconds later it automatically switches back to the 1680x1050 resolution and the colors are good again. bahh... Could it be a KMS bug? This pretty much smells like a kms issue. To clarify a bit: What's the difference between redump 1 and regdump 2? You've attached good and bad versions for both, hence I don't know what's the difference between 1 & 2. Can you please attach xrandr --verbose and the full dmesg when booting with drm.debug=0xe added to the kernel cmdline, too? One thing to try is to compile & install the latest 3.4-rc kernel and check whether you can still reproduce the issue. Yeah possibly yet another infoframe issue. Adding Paulo. Jesse, you are right about "possibly yet another infoframe issue". I'm the one adding "intel_infoframe -d solves things" in [Bug 25732]. I currently have two problems: 1) Between 3.1 & 3.2 I get a pink CGA pimped display (goes away with intel_inframes -d). This is still present in 3.4 RC2 2) In 3.1 and earlier kernels I get a green tint when resuming from suspend. This goes away with intel_infoframes -d as well. Last weekend I was bisecting #1 but somehow I failed to get to the bad commit. I observed a couple of things while bisecting pink issue between 3.1 - 3.2: - No graphical boot but proper colors when X starts - Graphical boot but pink colors (both during boot and when X starts) - Graphical boot with proper colors I set pink as BAD and non pink as GOOD when bisecting. I hope to redo this again. Paulo Zanoni fixed up our hdmi infoframe support - there's a big chance that this has been the root-cause of your problem. Please test the drm-intel-next-queued branch at http://cgit.freedesktop.org/~danvet/drm-intel/ Yes, the resume problem is fixed. I've been testing patches from Paulo in https://bugzilla.kernel.org/show_bug.cgi?id=25732 As I stated in the above report, I only have an issue during boot now where everything is pink (introduced between 3.1 & 3.2. This is also solved by infoframes -d. Should I close this one and stick to the one in bugzilla.kernel.org? Or perhaps open a new bug? Ok, thanks for the update, I think we can close this as fixed and track your remaining hdmi woes in the kernel bugzilla. Thanks for reporting this. |
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.