Created attachment 76806 [details] dmesg D945GCLF2 I get this error message: [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:4] trying to make tv video output (s-video) working on Intel D945GCLF2 motherboard but without success. kernel 3.8.3-r1 ; xf86-video-intel 2.21.4 ; xorg-server 1.13.1 ; libdrm 2.4.40 With older version it was working correctly.
Created attachment 76807 [details] Xorg.0.log D945GCLF2
Hmm, can you please attach the output of 'xrandr --verbose' (with the TV attached) and also please append drm.debug=6 to your kernel commandline and repeat the dmesg capture?
And to clarify: Does older kernels include 3.7.x series kernels, or only 3.6 and earlier?
And yet another one (coffee isn't working today ...): Any perceivable bad side-effects going along with that message? Anything else changed besides that error message popping up?
(In reply to comment #3) > And to clarify: Does older kernels include 3.7.x series kernels, or only 3.6 > and earlier? only 3.6 kernel and earlier
(In reply to comment #4) > And yet another one (coffee isn't working today ...): Any perceivable bad > side-effects going along with that message? Anything else changed besides > that error message popping up? no at the moment no other side effects in addition to s-video output that does not work
(In reply to comment #2) > Hmm, can you please attach the output of 'xrandr --verbose' (with the TV > attached) and also please append drm.debug=6 to your kernel commandline and > repeat the dmesg capture? I attached debug dmesg and xrandr outputs. I noticed another aspect, I have no video signal on luminance and chrominance pins (s-video) as I told you but I have video signal on composite video pin (composite). Anyway the composite video signal is disturbed, I attach a picture as an example. I have this kind of image on the frame buffer during the entire boot. With 3.6 kernel, the luminance/chrominance pins works correctly, even during boot sequence.
Created attachment 76827 [details] drm debug dmesg connecting s-video pins
Created attachment 76828 [details] drm debug dmesg connecting composite pin
Created attachment 76829 [details] xrandr output connecting s-video pins
Created attachment 76830 [details] xrandr output connecting composite pin
Created attachment 76832 [details] picture showing disturbs on composite signal
Fundamentally there is a hw issue whereby your ADD2 SDVO card is not registering the luma+chroma S-Video connection. Secondary to that we attempt to set a mode on the disconnected output (which could be a good or a bad idea), and in this case that results in illegal programming of the SDVO device (trying to set the target output to 0).
So apparently the sdvo mode_fixup fails. For reference can you please also attach a debug dmesg on the latest still working kernel?
Created attachment 76852 [details] dmesg 3.6 kernel s-video output This is the dmesg with 3.6 kernel, and with i915.modeset=0 option.
Please retest with latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel That contains a few patches to fix up sdvo handling (all cc: stable, so will get backported once those patches are merged into 3.10).
(In reply to comment #16) > Please retest with latest drm-intel-nightly from > > http://cgit.freedesktop.org/~danvet/drm-intel > > That contains a few patches to fix up sdvo handling (all cc: stable, so will > get backported once those patches are merged into 3.10). I tested, now something is going on through s-video output, but the image is really distorted, during boot loader s-video output is ok, during boot the image is recognizable even if distorted, after xorg start up I can only see white and black lines (I attach 3 screenshots, dmesg and Xorg.0.log).
Created attachment 77695 [details] boot loader screenshot
Created attachment 77697 [details] boot screenshot
Created attachment 77698 [details] xorg server screenshot
Created attachment 77699 [details] dmesg drm-intel-nightly
Created attachment 77700 [details] Xorg.0.log drm-intel-nightly
Ok, so we get a picture finally! Now can you please test the different resolutions to figure out whether all a broken or only some?
(In reply to comment #23) > Ok, so we get a picture finally! > > Now can you please test the different resolutions to figure out whether all > a broken or only some? I tested all available resolutions and the pictures I get now are recognizable, even if distorted. For all resolutions picture is similar to the one I attach.
Created attachment 77722 [details] 1024x768 screenshot
Quick shot in the dark to try on top of the lasted drm-intel-nightly branch: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 457a0a0..e3ee6d8 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4145,6 +4145,8 @@ static void i9xx_adjust_sdvo_tv_clock(struct intel_crtc *crtc) unsigned dotclock = crtc->config.adjusted_mode.clock; struct dpll *clock = &crtc->config.dpll; + return; + /* SDVO TV has fixed PLL values depend on its clock range, this mirrors vbios setting. */ if (dotclock >= 100000 && dotclock < 140500) {
(In reply to comment #26) > Quick shot in the dark to try on top of the lasted drm-intel-nightly branch: > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 457a0a0..e3ee6d8 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -4145,6 +4145,8 @@ static void i9xx_adjust_sdvo_tv_clock(struct > intel_crtc *crtc) > unsigned dotclock = crtc->config.adjusted_mode.clock; > struct dpll *clock = &crtc->config.dpll; > > + return; > + > /* SDVO TV has fixed PLL values depend on its clock range, > this mirrors vbios setting. */ > if (dotclock >= 100000 && dotclock < 140500) { I tested the patch. I attach some screenshots. Now it's better, even if it seems that some lines are missing. I attach 2 1024x768 screenshots and 1 768x576 screenshot.
Created attachment 77779 [details] 1024x768 screenshot
Created attachment 77780 [details] 1024x768 screenshot
Created attachment 77781 [details] 768x576 screenshot
Hm, it looks like we're stuck here. Can you please try to bisect where the original regression has been introduce befor 3.8?
I will try, I need some time. Sorry but when I previously told you the working kernel version I confused 3.6.x with 2.6.x as you could see from attached dmesg logs. For sure the last kernel I tried without problem is kernel 2.6.32 and not 3.6.x. Now I will check from whick kernel upgrading version, starting from 2.6.32 I notice the regression.
Finally I bisected the regression and it starts enabling KMS even from kernel 2.6.32. From kernel 3.5.1 KMS option becomes mandatory, so from that kernel there's no way to get svideo output working.
KMS should still be optional, even in latest kernels. I guess you've updated your userspace driver, too? At least booting with i915.modeset=0 should always disable kms on your system.
(In reply to comment #34) > KMS should still be optional, even in latest kernels. I guess you've updated > your userspace driver, too? At least booting with i915.modeset=0 should > always disable kms on your system. When I disable KMS booting with i915.modeset=0 (kernel 3.8.13 + intel userspace driver 2.21.14), my xorg server does not start, I have this error(from Xorg.0.log): [ 1046.583] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, HD Graphics, HD Graphics 2000, HD Graphics 3000, HD Graphics 2500, HD Graphics 4000, HD Graphics P4000, HD Graphics 4600, HD Graphics 5000, HD Graphics P4600/P4700, Iris(TM) Graphics 5100, HD Graphics 4400, HD Graphics 4200, Iris(TM) Pro Graphics 5200 [ 1046.585] (++) using VT number 7 [ 1046.589] (EE) No devices detected. [ 1046.589] Fatal server error: [ 1046.589] no screens found [ 1046.589] (EE)
Bisecting kernel I can use without error the userspace intel driver, booting with option i915.modeset=0, till kernel 3.4.9 (intel driver 2.9.1 + xorg 1.7.7). From kernel 3.5.1 I have the error I posted.
The dmesg is too short sadly, so we don't get to see the actual modeset sequence. However, it does contain at least one [ 695.928729] [drm:intel_sdvo_debug_write], SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) [ 695.930387] [drm:intel_sdvo_read_response], SDVOB: R: (Target not specified)... failed So commit a698a20e8cf9a946b0a491cb58ff96c0b4332d08 Author: Guillaume Clement <gclement@baobob.org> Date: Sat Aug 10 21:57:57 2013 +0200 i915: Fix SDVO potentially turning off randomly is of relevance to you in drm-intel-nightly.
Marco, please try drm-intel-nightly branch of git://people.freedesktop.org/~danvet/drm and report back. Thanks.
(In reply to comment #38) > Marco, please try drm-intel-nightly branch of > git://people.freedesktop.org/~danvet/drm and report back. Thanks. Hello Jani, I tried the nightly build drm kernel and I still get no video output, I attach dmesg and Xorg logs. I used the kernel with xorg server 1.14.3 both with intel driver 2.21.15 and 2.99.903.
Created attachment 87509 [details] dmesg drm kernel + driver 2.21.15
Created attachment 87510 [details] xorg log drm kernel + driver 2.21.15
Daniel likes to torture himself with SDVO and actually seemed to have a handle on this bug early on.
(In reply to Jesse Barnes from comment #42) > Daniel likes to torture himself with SDVO and actually seemed to have a > handle on this bug early on. I think the best I've managed is to figure out that somehow we anger the sdvo encoder with our pick of pll. But that's about it, not real progress at all. Except for tracing the vbios with the vesa driver I don't see any way to progress here, so I think it's time to close this. Thanks for reporting the issue anyway.
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.