Created attachment 42751 [details] archive with lsmod lspci xorg.0.log dmsg and intel_gpu_dump results I recently installed the new version of Pardus distribution (2011). I tried the i686 and x86_64 version and the issue is the same. With pardus 2009 and 2009.1 i had any issues... If it's a pardus specific issue, i'm sorry to create this bug report... I have an ASUS P5E-VM HDMI motherboard with an intel GMA X3500 video card. 00:02.0 VGA compatible controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03) My computer is connected to my TV with a HDMI cable. I haven't other screen to test it. The colors are really strange. During the installation steps, the background colors is green instead of grey (even the stty screens). After the installation, the issue is the same.
Fixed in circa 2.6.36: commit 2e3d6006aca163db3eeb931cec631974aaa3c293 Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Fri Sep 10 10:39:40 2010 +0800 drm/i915: Enable HDMI audio for monitor with audio support Rely on monitor's audio capability to turn on audio output for HDMI. Tested-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I'm not sure to understand. Firstly, Pardus 2011 uses kernel 2.6.37 and you said that it's fixed in 2.6.36. Secondly, you are talking about an audio issue and I have a display issue...
Colour shift, in particular the green tint, is often observed when sending audio data along with the video signal (for HDMI audio is encoded in the video sync) to a device not expecting such. You have an SDVO HDMI device, it will useful to check that we did indeed set up the device correctly. Please attach a dmesg with drm.debug=0xe (that is append drm.debug=0xe to your boot parameters or as a modprobe option).
Created attachment 42829 [details] dmsg with drm.debug=0xe
OK, Thanks for your explanations, it's clear for me now !!! I had the dms result with the debug option as asked.
This is mysterious: [ 1.074146] [drm:intel_sdvo_debug_write], SDVOB: W: 16 02 3A 80 18 71 38 2D 40 (SDVO_CMD_SET_OUTPUT_TIMINGS_PART1) [ 1.086489] [drm:intel_sdvo_write_cmd], command returns response Not supported [2] Is there any chance you install either drm-intel-fixes or current linus/master? In response to a couple of other bugs, sending SDVO commands has been changed and I'd like to confirm that we still generate that error with those bugs fixed. [drm-intel-fixes is available from http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git ]
Hi, with the kernel 2.6.38-rc2+ from http://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git the issue is still present. I add the result of dmesg with drm.debug=0xe boot paramater
Created attachment 43133 [details] dmsg with drm.debug=0xe option on 2.6.38-rc2+ kernel
Thanks, that clarifies that is indeed an unsupported operation to change the output mode... I just wanted to be sure we weren't making a mistake and missing an earlier error return. Do you still have the old kernel around? Can you also grab a drm.debug=0xe dmesg from it as well? And does "xrander --output HDMI1 --set force_audio -1" have any effect?
You are welcome :D I still have my original kernel (2.6.37). I have already grab a dmsg with drm.debug=0xe option (posted 2011-02-01 14:57). Do you want that I perform a new one ? I try the xrandr command with the original kernel : xrandr --output HDMI1 --set force_audio -1 I have these errors lines : No protocol specified Can't open display :0 It doesn't work...
(In reply to comment #10) > I still have my original kernel (2.6.37). I have already grab a dmsg with > drm.debug=0xe option (posted 2011-02-01 14:57). Do you want that I perform a > new one ? I meant if you have a dmesg from a working kernel. Two possibilities spring to mind for the error: (1) we now try to send audio whereas we didn't before (and for whatever reason we get it wrong), or (2) we regressed somewhere else. > I try the xrandr command with the original kernel : xrandr --output HDMI1 --set > force_audio -1 > > I have these errors lines : > No protocol specified > Can't open display :0 Sorry, that will only work when X is running and you can make a connection to the server.
Created attachment 43139 [details] dmsg with drm.debug=0xe option on 2.6.31 kernel
As my KDE environment is launched, X server is running correctly, so xrandr should work. no ? I launch the 2009.1 live USB Pardus version. it runs 2.6.31 kernel. The video is OK and the audio is not working on the TV with the HDMI but it's the "normal behavior" for this kernel version. I grab the dmesg with this version. Regards
(In reply to comment #13) > As my KDE environment is launched, X server is running correctly, so xrandr > should work. no ? Did you use sudo? It won't work if you change user with "sudo su". Run xrandr with the user you started X session for.
You are right, I used sudo. with the good user, I have no more error message but nothing happens... I tried this command with the 2.6.37 Pardus kernel and the 2.6.38-rc2+ vanilla kernel.
Created attachment 43169 [details] [review] Trigger modesetting if force-audio changes Ok, there's a bug that stops it from automatically triggering a modeset if you change the force-audio parameter, the attached patch should fix that. If you do a subsequent modeset, then it should take effect: $ xrandr --output HDMI1 --set force_audio -1 $ xrandr --output HDMI1 --off $ xrandr --output HDMI1 --preferred
I'm sorry but it still doesn't work... The second line turn off the display, so I reboot my compute, put these 3 three lines in a little script, and test it. But the issue is still present...
Oups, I haven't seen the patch. I will try it.
Hi, I compiled your latest git branch wich has your patch. I apply the xrandr commands. Unfortunately, the issue is still there... Regards,
Just to sanity check, can you try this patch and make sure the green tint goes away? diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo index 19c817a..36af9ad 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1076,8 +1076,8 @@ static void intel_sdvo_mode_set(struct drm_encoder *encode } if (intel_crtc->pipe == 1) sdvox |= SDVO_PIPE_B_SELECT; - if (intel_sdvo->has_hdmi_audio) - sdvox |= SDVO_AUDIO_ENABLE; +// if (intel_sdvo->has_hdmi_audio) +// sdvox |= SDVO_AUDIO_ENABLE; if (INTEL_INFO(dev)->gen >= 4) { /* done in crtc_mode_set as the dpll_md reg must be written earl
Hi, I can just picture it's not the expected result, but it still doesn't work... To be sure that I load the modified module, I add some printk lines and the logs appears... so, I load the good one... Regards,
Hello, I tried with your latest kernel git and the issue is still present... Regards commit 467cffba85791cdfce38c124d75bd578f4bb8625 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Mar 7 10:42:03 2011 +0000
I have the same issue with exactly the same mainboard connected to a Sharp LC-46X20E via HDMI. It worked fine with 2.6.35.6 and now everything is green with 2.6.37.6 and 2.6.38.3. Setting force_audio to -1 doesn't have any effect. Can I help by providing any additional information?
Created attachment 46301 [details] dmesg with drm.debug=0xe on Arch-Linux x64 2.6.38 Don't know if this is exactly the same problem but i've got this green background with white fonts on it when connecting my Lenovo Edge 11 Notebook (Core-i3-380UM, HM55 Express Graphics) via HDMI to my TV-Screen (some older LG model). On system start everything is fine with the colors till "Udev events are processed". Then the console-resolution changes and the colors turn to green/white. On X the colors are still wrong but i think this is not an x-problem cause it does appear without x on the console and different xrandr on/off/resolution switches doesnt change anything. I'm not a big linux-guru but let me know if i can help with anything. Maybe my dmesg-output will help.
This is still broken with Linux 3.0. Chris, any update on this? It makes not so ancient mainboards with HDMI screens completely useless for more than half a year now. Is there a workaround?
This was first filed against kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 My last comment there contains a possible solution approach.
Copying comments from kernel bugzilla, which is still unavailable: --- Comment #17 from Jürg Billeter <j@bitron.ch> 2011-07-23 08:45:36 --- Removing the ecc field from the dip_infoframe struct in intel_drv.h (and the corresponding assignment in intel_hdmi.c) fixes the issue for me - tested with Linux 3.0. I'm not familiar with the relevant specifications, but I suspect that the ECC byte must not be included for HDMI using SDVO hardware. My mainboard is an Asus P5E-VM HDMI (G35). --- Comment #18 from Chris Wilson <chris@chris-wilson.co.uk> 2011-07-23 10:08:02 --- Jesse, can you check whether the infoframe structure really did change between SDVO-HDMI and HDMI, and which one is correct? --- Comment #19 from Tom Hunt <tomahhunt@gmail.com> 2011-07-25 13:41:25 --- I have tested Jürg's patch on my Kernel (2.6.39) and it works a charm. --- Comment #20 from Jürg Billeter <j@bitron.ch> 2011-07-25 14:11:55 --- I can try to come up with a proper patch (removing ECC only in the SDVO case), but I'd like to wait until someone familiar with SDVO confirms that this is the right approach.
The issue still exists here in Linux 3.1.1. I currently have to apply commit 64a8fc0 from master (drm/i915: fix ILK+ infoframe support) on top of 3.1.1 and remove the ecc field¹ as described in comment 17 in the kernel bug report. With those two changes, it works fine. Would be nice if someone from Intel could check whether that's the correct fix and get it upstream. ¹ sed -i -e '/ecc/d' drivers/gpu/drm/i915/{intel_drv.h,intel_hdmi.c}
*** Bug 38685 has been marked as a duplicate of this bug. ***
The infoframe structure hasn't changed afaik, but I'm ok with not having the ECC field in the SDVO case; I guess that particular card must use it somehow. Though it's possible the ECC field isn't supposed to be used on any chipset of this generation... The "fix infoframe" patch caused a regression for at least one other user I know of, but I don't have a way of testing fixes here.
Hi, Jürg Billeter's "remove ecc fix" also works for me too (kernel 3.2.0 / ASUS G35 motherboard). I too believe ECC was never meant to be sent to the DIP data register. The Intel G35 and Intel Sandy Bridge programmer reference manuals use identical terminology when describing use of the ECC field. Also/maybe relevant: The ALSA Intel HDMI audio driver does not include ECC in its DIPs (see sound/pci/hda/patch_hdmi.c). -- Peter
I was having this problem on my Dell Inspiron 14 laptop running ArchLinux+KDE with kernel version 3.1.9. I patched the kernel using Jürg Billeter's two-step fix above (apply "fix infoframe"; delete ecc) and this took some steps toward fixing the problem. Here are some observations which I hope are helpful: 1] HDMI Sound stopped working after the patch. KDE reports the HDMI audio device as nonfunctional in the notifier, and refuses to use it. Prior to the patch, HDMI sound worked fine. 2] HDMI sound is still being output. (Or so I assume.) The laptop is connected to a Denon AVR1610 receiver, which is "autodetecting" sound from the laptop's HDMI. I connected the headphones to the RCA jacks on the back of the receiver but it would not use the analog inputs until I dove into the receiver's menu and forced it to. 3] Closing the laptop lid, letting it sleep, and opening the lid again brings back the green HDMI issue. The green hue did not go away until I rebooted. Actually, as the machine was powering down, the X server was killed, returning me to a text console. The text console was not green. lspci says my hardware is: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) ... 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
Created attachment 55627 [details] dmesg with drm.debug=0xe on 3.2.0 kernel (Ubuntu 3.2.0-8)
@Chris Wilson: I tested your earlier proposal to clear the SDVO_AUDIO_ENABLE bit on SDVOx (https://bugs.freedesktop.org/show_bug.cgi?id=33760#c20). The green color symptom was still present after applying. This change did *not* disable audio output on my system (2ch LPCM over the HDMI interface). I'm curious now what that bit is for. For the sake of completeness, I also disabled the Intel HD Audio driver altogether. The green color symptom was present after applying that change too.
Created attachment 55983 [details] segmented dmesg with drm.debug=0xe on archlinux 3.2.1 kernel The tarball contains a "segmented" dmesg, which is divided according to what I was doing. This is on my Dell Inspiron 14 with Intel core 2 graphics chipset as described by lspci above. The dmesg files go in this order: "pre_connect" represents booting the laptop without being connected to the hdmi (was using laptop screen) "just_tv_on" represents connecting the HDMI cable when everything is turned off, followed by turning on the AV receiver, followed by turning on the TV, followed by configuring the computer to use the HDMI output at 1360x768 using KDE tools. Result: color is fine; picture good. "just_close_open_lid" represents closing the laptop's lid so it sleeps, and opening it again. Result: picture has green hue "just_play_sound_fail" represents opening kmix, opening "setup audio" (Phonon KDE control module), selecting the HDA Intel PCH, HDMI 0 (HDMI Audio output) and pressing the "test" button. Result: KDE notified me that the HDMI audio device was not working and it was falling back to the default audio device (laptop speakers)
Please see comments #24 and #26 in the kernel bug tracker: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Created attachment 59356 [details] [review] fixup sdvo attached hmid timing issue This patch fixes an issue with how we set up the sdvo encoder input timings. Maybe it fixes your issue (it fixed another audio problem magically already), please test it.
@Daniel Vetter: The green color symptom was still present after applying your patch (2012-04-01 12:28:21 PDT; https://bugs.freedesktop.org/attachment.cgi?id=59356). Tested on ASUS G35 mainboard; kernel 3.4.0rc1-git.
If this is the same bug as https://bugzilla.kernel.org/show_bug.cgi?id=25732, then I guess Daniel's patch from comment #70 will fix this and we might be able to finally close the bug. Can anyone please confirm that?
@Paulo Zanoni: Yes, it is the same bug. And, yes, the comment #70 patch fixes it.
(In reply to comment #40) > @Paulo Zanoni: Yes, it is the same bug. And, yes, the comment #70 patch fixes > it. Closing then. This is in Linus' tree already: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=81014b9d0b55fb0b48f26cd2a943359750d532db I wanted to close this as a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=25732, but it's in another bugzilla...
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.