Hi I come from bug #25732. There were actually 2 problems being debugged there. The original problem (specific to SDVO) was fixed, so this bug report is for the remaining users. The main problem is: - Boot your machine with an HDMI monitor using the i915 driver. - You can't see the screen - Run intel_infoframes -d - You can see the screen :) I can not reproduce this bug exactly as I described here, but I can reproduce another problem which, I believe, has the same cause as this bug. I hope other people will come from bug #25732 to this one and provide comments and test my patches. Otherwise, I'll just look weird reporting a bug to myself :)
Hello Paulo, (I have a SNB/i5-2400S) I found out why I got pink problems on boot and green tint on suspend. This was due to a "Video Conversion" feature on my Pioneer receiver that sits between computer and TV. When I boot 3.1 kernel (last kernel with OK display) the receiver says it gets a RGB signal: -------- Computer -------- Resolution: 1080/60p Aspect: --- Color Format: RGB Full Bit: --- Extended Color Space: Standard Receiver converts and outputs this -------- Receiver -------- Resolution: 1080/60p Aspect: 16:9 Color Format: YCbCr444 Bit: 36bit (12bit*3) Extended Color Space: Standard When I boot 3.2 kernel (first with pink&green colors) the receiver says it gets this signal: -------- Computer -------- Resolution: 1080/60p Aspect: --- Color Format: --- Bit: --- Extended Color Space: Standard And converts and outputs the following: -------- Receiver -------- Resolution: 1080/60p Aspect: 16:9 Color Format: --- Bit: 36bit (12bit*3) Extended Color Space: Standard If I stop the "Video Converter" on the receiver I get no more pink display. Receiver says the TV wants this: -------- TV -------- Recommended Resolution: 1080/60p Deep Color: 36bit (12bit*3) Extended Color Space: xvYCC709 I also tried the resume from suspend and it also looks great when I turned the Video Converter off. Any comments?
I recently wrote another set of patches that solved *all* the problems I could reproduce on HDMI. This included some problems that I could "fix" by running "intel_infoframes -d". Could you please test these patches? They are on the drm-intel-next-queued branch of danvet's tree: http://cgit.freedesktop.org/~danvet/drm-intel/?h=drm-intel-next-queued Please make sure you're on the correct branch before compiling. Maybe with this kernel your receiver will work even in "Video Conversion" mode?
I've tested this now and I can confirm that it even works find in "Video Conversion" mode. The Pioneer VSX-921 Receiver says it gets a "Color Format: RGB Full" from the computer just like it did in kernel 3.1. Awesome Paulo, shame on me that I didn't know this mode was turned on in the Receiver back in July last summer. One more question, what about the Aspect & Bit information. Receiver still says "---". Is this something that should be sent by the driver too?
works find => works fine :)
A patch referencing this bug report has been merged in Linux v3.6-rc1: commit 9d32d1653db10eaba3140dd1a2f8dad51122f0b5 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Mon May 28 16:42:55 2012 -0300 drm/i915: don't write 0 to DIP control at HDMI init
(In reply to comment #3) > > One more question, what about the Aspect & Bit information. Receiver still > says > "---". Is this something that should be sent by the driver too? It's optional. We're not sending this yet. We're not sending many of the optional infoframe fields. What is the impact of not sending this? Does it make something not work? Notice that you can play with the intel-infoframes tool to add any information you may want to send, so you can easily test this. Closing bug. If we conclude we need to send aspect rate & bit information, please open another bug report and assign it to me.