Bug 39314 - [G35 sdvo/hdmi] Display colors are mixed, all too green
[G35 sdvo/hdmi] Display colors are mixed, all too green
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Intel
XOrg git
x86 (IA32) Linux (All)
: medium normal
Assigned To: Daniel Vetter
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-17 14:14 UTC by Jani Ollikainen
Modified: 2012-09-19 15:46 UTC (History)
3 users (show)

See Also:


Attachments
Dmesg output with drm.debug=0x06 (41.20 KB, text/plain)
2011-07-17 14:14 UTC, Jani Ollikainen
no flags Details
Intel reg dumper output (10.56 KB, text/plain)
2011-07-17 14:15 UTC, Jani Ollikainen
no flags Details
Vbiod dump (48.00 KB, application/octet-stream)
2011-07-17 14:15 UTC, Jani Ollikainen
no flags Details
Picture with green console (65.85 KB, image/jpeg)
2011-07-17 14:23 UTC, Jani Ollikainen
no flags Details
Dmesg output with drm.debug=0x06 (this time it seems to have debug) (125.20 KB, text/plain)
2011-07-18 13:38 UTC, Jani Ollikainen
no flags Details
xrandr --verbose (2.62 KB, text/plain)
2011-07-18 13:39 UTC, Jani Ollikainen
no flags Details
xrandr --output HDMI1 --set "audio" "off" dmesg output with drm.debug=0x06 (14.31 KB, text/plain)
2011-07-20 04:42 UTC, Jani Ollikainen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jani Ollikainen 2011-07-17 14:14:48 UTC
Created attachment 49222 [details]
Dmesg output with drm.debug=0x06

Bug description:
When booting Fedora 15 kernel (kernel-2.6.38.8-36.fc15.i686) when KMS sets mode screen goes all too green. If booting to single mode with "nomodeset" parameter screen stays ok.

Broken with:
kernel-3.0-0.rc7.git3.1.fc16.i686
kernel-2.6.38.8-36.fc15.i686

Works with:
kernel-2.6.35.13-92.fc14.i686

Linux cd.purkki.org <kernel> 686 i686 i386 GNU/Linux

System environment:
-- chipset: G35
-- system architecture: 32-bit
-- Linux distribution: Fedora 15
-- Machine or mobo model: Asus P5E-VM HDMI LGA-775 MicroATX
-- Display connector: HDMI

Reproducing steps:
1. Boot kernel

Additional info:
Comment 1 Jani Ollikainen 2011-07-17 14:15:22 UTC
Created attachment 49223 [details]
Intel reg dumper output
Comment 2 Jani Ollikainen 2011-07-17 14:15:49 UTC
Created attachment 49224 [details]
Vbiod dump
Comment 3 Jani Ollikainen 2011-07-17 14:23:38 UTC
Created attachment 49225 [details]
Picture with green console
Comment 4 Chris Wilson 2011-07-17 14:24:16 UTC
Apart from the absence of drm.debug in that dmesg... I presume you have an SDVO HDMI connection on which we are sending audio because the display says it can handle such, but disagrees.

xrandr --verbose.

With 3.0, xrandr --output HDMI1 --set "audio" "off", should do the trick if I've guessed right.
Comment 5 Jani Ollikainen 2011-07-18 03:30:16 UTC
(In reply to comment #4)
> Apart from the absence of drm.debug in that dmesg... I presume you have an SDVO
> HDMI connection on which we are sending audio because the display says it can
> handle such, but disagrees.
> xrandr --verbose.
> With 3.0, xrandr --output HDMI1 --set "audio" "off", should do the trick if
> I've guessed right.

Well, gave that parameter to kernel as described in http://intellinuxgraphics.org/how_to_report_bug.html. I can try it again in evening.

But cannot understand your "solution".

It works for older kernel, audio and video over the HDMI without any problems. So won't call it a issue with my television advertising audio but not supporting it or has the audio format changed in the new kernels?

And it goes green even in single user mode, without Xorg running. So there is no DISPLAY to xrandr to connect to give you --verbose or set audio off.
Comment 6 Chris Wilson 2011-07-18 08:34:54 UTC
Audio enabling on HDMI monitors is one of the paths that has been modified since 2.6.35. Adding a connector property to be able to override audio came much later. (In theory you should be able to disable it through /sys/class/drm/card0-CONNECTOR/ and so not need X). As audio support is enabled by KMS by based on the reported capabilities of the monitor, it affects fbcon equally.

One other patch that catches my eye since v2.6.35 is commit 81a14b46 since that has upset a few people with broken EDID.
Comment 7 Jani Ollikainen 2011-07-18 13:37:22 UTC
Ok, more testing.

I booted up and now got right dmesg. Attaching it and xrandr output next. Booted to Xorg.

Setting audio off does not fix the problem. Screen stays green. But you seem to be awake on IRC, I'll ping you there ;)
Comment 8 Jani Ollikainen 2011-07-18 13:38:39 UTC
Created attachment 49271 [details]
Dmesg output with drm.debug=0x06 (this time it seems to have debug)
Comment 9 Jani Ollikainen 2011-07-18 13:39:10 UTC
Created attachment 49272 [details]
xrandr --verbose
Comment 10 Jani Ollikainen 2011-07-20 00:04:15 UTC
After applying patch that Chris made: http://pastebin.com/iQNNHyVr the result in dmesg with drm.debug=0x06 was multiple lines of:

HDMI connector detected: has_hdmi_monitor=1, has_hdmi_audio=1

So what next?
Comment 11 Chris Wilson 2011-07-20 02:37:03 UTC
Just to check, did you try "xrandr --output HDMI1 --set audio off" after applying the debugging patch?
Comment 12 Jani Ollikainen 2011-07-20 04:42:37 UTC
Created attachment 49337 [details]
xrandr --output HDMI1 --set "audio" "off" dmesg output with drm.debug=0x06

No, but now I did and this is the dmesg output of doing it.

Seems to say that has_hdmi_audio=0 so it disables audio, but screen
is still greenish.
Comment 13 Chris Wilson 2011-07-20 04:52:49 UTC
Meh.

One last trick before starting afresh, set has_hdmi_monitor=0.
Comment 14 Jesse Barnes 2011-08-02 11:00:31 UTC
Aren't we supposed to send NULL packets too?

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo
index 30fe554..762d61a 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1061,7 +1061,8 @@ static void intel_sdvo_mode_set(struct drm_encoder *encode
        if (INTEL_INFO(dev)->gen >= 4) {
                sdvox = 0;
                if (intel_sdvo->is_hdmi)
-                       sdvox |= intel_sdvo->color_range;
+                       sdvox |= intel_sdvo->color_range |
+                               NULL_PACKET_VSYNC_ENABLE;
                if (INTEL_INFO(dev)->gen < 5)
                        sdvox |= SDVO_BORDER_ENABLE;
                if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
Comment 15 Jesse Barnes 2011-08-02 11:06:42 UTC
There's a patch in https://bugzilla.kernel.org/show_bug.cgi?id=25732 that might also help.
Comment 16 Jürg Billeter 2011-08-02 11:15:50 UTC
(In reply to comment #15)
> There's a patch in https://bugzilla.kernel.org/show_bug.cgi?id=25732 that might
> also help.

That would make this a duplicate of bug 33760 in this bugzilla as well.
Comment 17 Chris Wilson 2011-08-02 13:17:24 UTC
And just to remind myself G35 is gen4... So it looks like we currently do enable NULL_PACKETs but only for the integrated HDMI when audio is enabled. Is that correct or do we need to set the NULL flag for any aviframe (i.e. all HDMI) encoding there as well?
Comment 18 Jesse Barnes 2011-08-02 13:22:14 UTC
I think we need to set it whenever there's an HDMI sink connected.
Comment 19 Jesse Barnes 2011-08-02 14:00:15 UTC
It looks like we're calculating the checksum incorrectly too; I think it's just supposed to be for the payload, not for the header bytes.

If you leave the ECC byte in but fix the checksum routine to start the checksum calc at byte 6 instead (past the header and checksum byte) do things work better?
Comment 20 Jesse Barnes 2011-08-04 11:18:06 UTC
You can just test drm-intel-next from keithp's linux-2.6 tree now, it has the fixes (or what I think are fixes).
Comment 21 Jani Ollikainen 2011-09-01 09:20:47 UTC
Ah, back in business. Had a long vacation trip so didn't follow these up.
Tested with a patch saying intel_svdo->has_hdmi_monitor=0; before that
ickles patch and that made things look normal, but of course the HDMI audio is broken after it.

Ok, will try to figure out, where to get that keithp tree and how i can try to patch it to my kernel.

If there's a .rpm for the kernel somewhere. Ah, seems that Linux 3.1-rc4 has them and that's in rawhide as a prebuild rpm. Will test that now.

Ok. Can confirm that the fixes pushed to Linux 3.1-rc4 fixes my problems. Now the screen is normal and the audio works.

Thanks to everyone! And now to get that fix into Fedora 15 kernel:)
Comment 22 Jani Ollikainen 2012-09-19 15:32:41 UTC
It's back!

kernel-3.4.7-1.fc16.i686
kernel-3.4.9-2.fc16.i686

Are green again and kernel-3.1.8-2.fc16.i686 works.
Comment 23 Chris Wilson 2012-09-19 15:39:02 UTC
The first important question is whether the stable 3.5 is equally affected.
Comment 24 Jani Ollikainen 2012-09-19 15:46:04 UTC
Installed kernel-3.5.4-1.fc17.i686.rpm and it works, so it's just Fedora's problem. So closing this again, sorry for the noise:)