Created attachment 29480 [details]
dmesg

Created attachment 29481 [details]
xrandr --verbose

Maybe forgot to add that i915 is compile into the kernel.

If there is anything else you may want me to add, just go ahead and ask.

Will you please add the boot option of "drm.debug=15" and attach the output of dmesg ? It is required on both the kernel of 2.6.30 and 2.6.31.

Will you please check whether it can be switched to 1024x768 mode after entering the X-environment?

Thanks.

Created attachment 29535 [details]
dmesg of 2.6.30

Created attachment 29536 [details]
dmesg 2.6.31

I could change to (and got a stabil) 1024x768 without problem.

Anything more you need from me?

Can you please fix a way to on the kernelcmd set a display mode? I can bet that even if we may not e that many I will not be the only one with strange monitor/display that needs to set another mode then kms wants.

<rant>
To be honest here is yet another reason why I in bug #22035 suggested the possibility to on the kernelcmd set a mode for KMS.
Now I have an unusable 2.6.31 (in this case having epileptic bootup until something can run xrandr is not that fun) that I rather would use then having to becouse of bug #22035 patch 2.6.30. Since for example I have problems restoring VTs with both but I have no possibility to know if this is a kernel bug (which in that case came with the fix for bug #22035) or a sideffect of changeing resolution in Xorg, and since I cannot really currently play around with 2.6.31 (I use that box so much for various media purposes that I really do not like massive downtime/short uptimes).
Having the possibility to set the resolution I would still bugreport, but I could at least use the kernel.
</rant>

Created attachment 29789 [details]
kernel.log drm.debug=15

Since I realized the last kernel-logs may not have given what you wanted I removed X from my bootup, added drm.debug=15 to my kernelcmd and rebooted.

So here is everything from boot til login with kernel-2.6.30.
Nothing X, nothing xrandr, just the init of all the hardware.

kernel-2.6.31 will follow shortly.

Created attachment 29790 [details]
kernel-2.6.31.log drm.debug=15

Created attachment 29791 [details]
flickering screen with 2.6.31

This boot it seemed stable while being at the console, but as soon as I started X it started to flicker at the sides, and before I shut down the TV it had escalated to this.

Will you please try the Eric's drm-intel-next tree and attach the output of dmesg, xrandr, Xorg.0.log by adding the boot option of "drm.debug=0x04"?

Thanks.

(In reply to comment #11)
> Will you please try the Eric's drm-intel-next tree and attach the output of
> dmesg, xrandr, Xorg.0.log by adding the boot option of "drm.debug=0x04"?
> 
> Thanks.
> 

http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=shortlog;h=refs/heads/drm-intel-next

Is this the one you are talking about?

Created attachment 30258 [details]
kernel log, drm.debug=0x04

I tried the drm-intel-next from git.kernel.org, same problems as before with resolution.
However flickering is not that much anymore. Before if I left it the screen started to jump out of control. Now it almost stops jumping until I do something that changes the screen, starting a movie renders the screen unwatchable.

Attatching a log from this bootup, up and til X has started.

Just realised one thing, it seems like those modes that has the + sign in xrandrs list (848x480 being the mode choosen by default) has the flickering problems, those other seems stable.


$ DISPLAY=":0" xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA1 disconnected (normal left inverted right x axis y axis)
DVI1 disconnected (normal left inverted right x axis y axis)
TV1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   848x480        25.0 +
   640x480        25.0 +
   1024x768       25.0* 
   800x600        25.0  
   480i/60        30.0  
   480p/60        60.0  
   720p/60        60.0  
   1080i/60       30.0  
   1080p/60       60.0  

Ok, it seems like the flickering has nothing to do with the videomode.

I fired up 2.6.32-rc5 today and took it out for a spind with video=1024x768 on the kernelcmd line, and added PreferredMode to xorg.conf to get it work like it should.
Console seems fine (checked with some graphical things that does not work in 848x480 mode), starting X works fine in 1024x768, starting xterm works fine, starting glxgears and the picture breaks.
My standard session is using OpenGL/GLX, which can explain why that does not work.

Do you want me to provide any new information?

Today I had some time to invest into this.
I got the latest git source from linus kernel tree (commit 7c9abfb884b8737f0afdc8a88bcea77526f0da87), compiled it and started it.
This has all to do with my startup scripts first setting "xrandr --set mode PAL" (since there is no other way) and then a application sets "xrandr --mode 1024x768". If I never do set the mode to PAL everything (except for the picture flashing a bit brigther) works correctly. Below I have documented how I found a way to reproduce using xrandr and glxgears (and xterm as a non-3d reference window).

starting computer to console. Logging in using ssh as your favorite user. ## prefixes comments about what I am about to do, $ prefixes commands of what I did:

## Start X and wait for it to settle
$ X & 
## To make life easier
$ export DISPLAY=":0" 
## Starting xterm to have a non-3d window open as reference
$ xterm &
## I will only post info about TV1 as all else is disconnected
## note that the display is setup for NTSC-M and 1024x768
$ xrandr --verbose 
TV1 connected 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 0mm x 0mm
	Identifier: 0x43
	Timestamp:  118579
	Subpixel:   unknown
	Clones:    
	CRTC:       0
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	bottom margin: 37 (0x00000025)	range:  (0,100)
	right margin: 46 (0x0000002e)	range:  (0,100)
	top margin: 36 (0x00000024)	range:  (0,100)
	left margin: 54 (0x00000036)	range:  (0,100)
	mode:	NTSC-M
		supported: NTSC-M       NTSC-443     NTSC-J       PAL-M       
		           PAL-N        PAL          480p@59.94Hz 480p@60Hz   
		           576p         720p@60Hz    720p@59.94Hz 720p@50Hz   
		           1080i@50Hz   1080i@60Hz   1080i@59.94H
  1024x768 (0x44)   26.9MHz *current +preferred
        h: width  1024 start 1025 end 1088 total 1120 skew    0 clock   24.0KHz
        v: height  768 start  769 end  800 total  801           clock   30.0Hz
  848x480 (0x45)   14.5MHz +preferred
        h: width   848 start  849 end  912 total  944 skew    0 clock   15.4KHz
        v: height  480 start  481 end  512 total  513           clock   30.0Hz
  640x480 (0x46)   11.3MHz +preferred
        h: width   640 start  641 end  704 total  736 skew    0 clock   15.4KHz
        v: height  480 start  481 end  512 total  513           clock   30.0Hz
  800x600 (0x47)   17.0MHz
        h: width   800 start  801 end  864 total  896 skew    0 clock   19.0KHz
        v: height  600 start  601 end  632 total  633           clock   30.0Hz

## Start glxgears and see if it displays properly
$ glxgears
## For me it does, and after killing it with Ctrl-C I proceed 
## Becouse that my TV is a PAL tv I ofcourse want it to use it
$ xrandr --output TV1 --set mode PAL
## Starting glxgears again and visually confirm it works
$ glxgears
## It still displays properly
## Looking at xrandr --verbose I discovers that is does not any longer has *current for 1024x768
$ xrandr --verbose
TV1 connected 1024x768+0+0 (0x44) normal (normal left inverted right x axis y axis) 0mm x 0mm
	Identifier: 0x43
	Timestamp:  490284
	Subpixel:   unknown
	Clones:    
	CRTC:       0
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	bottom margin: 37 (0x00000025)	range:  (0,100)
	right margin: 46 (0x0000002e)	range:  (0,100)
	top margin: 36 (0x00000024)	range:  (0,100)
	left margin: 54 (0x00000036)	range:  (0,100)
	mode:	PAL
		supported: NTSC-M       NTSC-443     NTSC-J       PAL-M       
		           PAL-N        PAL          480p@59.94Hz 480p@60Hz   
		           576p         720p@60Hz    720p@59.94Hz 720p@50Hz   
		           1080i@50Hz   1080i@60Hz   1080i@59.94H
  1024x768 (0x106)   22.4MHz +preferred
        h: width  1024 start 1025 end 1088 total 1120 skew    0 clock   20.0KHz
        v: height  768 start  769 end  800 total  801           clock   25.0Hz
  848x480 (0x107)   12.1MHz +preferred
        h: width   848 start  849 end  912 total  944 skew    0 clock   12.8KHz
        v: height  480 start  481 end  512 total  513           clock   25.0Hz
  640x480 (0x108)    9.4MHz +preferred
        h: width   640 start  641 end  704 total  736 skew    0 clock   12.8KHz
        v: height  480 start  481 end  512 total  513           clock   25.0Hz
  800x600 (0x109)   14.2MHz
        h: width   800 start  801 end  864 total  896 skew    0 clock   15.8KHz
        v: height  600 start  601 end  632 total  633           clock   25.0Hz
  1024x768 (0x44)   26.9MHz
        h: width  1024 start 1025 end 1088 total 1120 skew    0 clock   24.0KHz
        v: height  768 start  769 end  800 total  801           clock   30.0Hz
## What will happend if I reset it to 1024x768?
$ xrandr --output TV1 --mode 1024x768
## xterm still looks fine and has done all the time, what about glxgears?
$ glxgears
## And here the whole screen starts to spin vertically... 
## Killing glxgears and xterm displays fine again.

I looked some more at this, and relized some things:

When I run "xrandr --output TV1 --set mode" (I have tried with both PAL and NTSC-M here) it does not set a display mode fitting for the new output mode, and stays with the old.
i.e. switching to PAL I still have 0x44 as display mode, which seems to be 1024x768 for NTSC-m, and glxgears still work.
Switching to 0x106 (which seem to be 1024x768 for PAL) breaks glxgears.
Switching back to NTSC-M and glxgears is broken until I set 0x44.

So with other words glx seems broken for all PAL display modes my computer allows me to try(0x106-0x109), and works with all NTSC-M display modes (0x44-0x47).

Also every time xrandr fails to set a displaymode when switching between PAL and NTSC-M I get this message (i.e. "xrandr --output TV --set mode PAL && xrandr --output TV --set mode NTSC-M" shows this error one time, while "xrandr --output TV --set mode PAL && xrandr --output TV1 --mode 1024x768 && xrandr --output TV --set mode NTSC-M" shows it twice):

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  147 (RANDR)
  Minor opcode of failed request:  21 (RRSetCrtcConfig)
  Serial number of failed request:  45
  Current serial number in output stream:  45

Ok, this turned out to be a lot of issues:

1)
From 2.6.31 and onwards the kernel chooses as default 848x480 when at least the ddx by default chooses 1024x768 (and so did the kernel before, but that could have been because of a non-existent but enabled LVDS).


and for the "xrandr --output TV1 --set mode PAL && xrandr --output TV1 --mode 1024x768" breaks glx-apps:

2)
The git tag v2.6.31 works from linus kernel tree as well as in the stable tree provided by gregkh. But between v2.6.31.1 and .2 there is breakage introduced in the stable tree, but reverting that on top of v2.6.31.6 still fails so I guess there is more then one breaking commit here. So v2.6.31.1 is fine but not the later in the stable series.

3)
Linus kerneltree broke between 2.6.32-rc3 and 2.6.32-rc4 with the following commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0d0884cee3099ec1271a5d379c39b66de1e31923 (drm/i915: Multiply the refresh by 1000 in TV mode validatiion)
and reverting that commit on top of current tree makes my glx-related problems go away (i.e. the picture stops flicker vertically over the screen).


So which one should we track here and which one should I open new bugs for?

Created attachment 31433 [details] [review]
don't set "848x480" as preferred mode for NTSC/PAL/480p

(In reply to comment #18)
> Ok, this turned out to be a lot of issues:
>
Sorry for the late response.
> 1)
> From 2.6.31 and onwards the kernel chooses as default 848x480 when at least the
> ddx by default chooses 1024x768 (and so did the kernel before, but that could
> have been because of a non-existent but enabled LVDS).
> 
> 
> and for the "xrandr --output TV1 --set mode PAL && xrandr --output TV1 --mode
> 1024x768" breaks glx-apps:
Will you please query the mode list for TV after changing the TV format and then set the display mode to see whether the issue still exists?

> 3)
> Linus kerneltree broke between 2.6.32-rc3 and 2.6.32-rc4 with the following
> commit:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0d0884cee3099ec1271a5d379c39b66de1e31923
> (drm/i915: Multiply the refresh by 1000 in TV mode validatiion)
> and reverting that commit on top of current tree makes my glx-related problems
> go away (i.e. the picture stops flicker vertically over the screen).
> 
Will you please try the debug patch in comment #19 and see whether the issue still exists?

thanks.
> 
> So which one should we track here and which one should I open new bugs for?
> 

(In reply to comment #20)
> Will you please query the mode list for TV after changing the TV format and
> then set the display mode to see whether the issue still exists?
> 
You mean like I did in comment 16 where I essentially did "xrandr --set mode PAL && xrandr --verbose && xrandr --mode 1024x768" but with visual confirmation of the output and glxgears in between? The output from those xrandr --verbose is in that comment.
Or you want me to retest with the debug-patch?

> Will you please try the debug patch in comment #19 and see whether the issue
> still exists?
> 
Now my TV uses 1024x768 both in console and in Xorg by default, just like the ddx.

(In reply to comment #21)
> Now my TV uses 1024x768 both in console and in Xorg by default, just like the
> ddx.
> 

After a cleanup and retest I saw this was quite not true, now KMS uses 640x480. At least it is a common mode, but still the intel ddx uses 1024x768 by default, why should not KMS?

Ok, now this only gets more broken and broken...

I checked out a clean v2.6.32 from linus kernel-tree and tested both with and without debug patch (giving either 640x480 or 848x480 and NTSC-M).

Just starting X and starting glxgears makes glxgears scrolls vertically.
It turns out all resolutions except 1024x768/NTSC-M makes glxgears scroll.

This means everything I can try for S-Video for NTSC-M and PAL makes glxgears scrolls except exactly 1024x768 for NTSC-M...

xterms still looks fine, so it IS something wrt glx... Was there not some change to use vsync by default and could that expose error like this? And could I try that somehow?

Wanted to point out that apart from having to use "TV_Connector" to force the TV as "connected" this works fine with any resolution in UMS, it is only broken with KMS.

Today I got my thumbs out to try some new code.
Nothing seems to change, running glxgears (single xterm is fine until you start glxgears at the same time) in the default configuration (KMS, 848x480, NTSC-M) is busted and so is everything PAL and almost everything but 1024x768 for NTSC-M.

The following versions was used:
libdrm-2.6.17
mesa-7.7
xf86-video-intel-2.9.1
linus kernel tree, tag v2.6.33-rc2 and drm-intel-next up until commit  cf74ecbbff3e3b45bae61d28d2220f74d853e2f0 merged ontop.


Any more info I can provide or anything I can do to kick this on the right track?
Is there noone who has time, has the equipment to test for themselves or are you currently just out of options/ideas?

(In reply to comment #22)
> (In reply to comment #21)
> > Now my TV uses 1024x768 both in console and in Xorg by default, just like the
> > ddx.
> > 
> 
> After a cleanup and retest I saw this was quite not true, now KMS uses 640x480.
> At least it is a common mode, but still the intel ddx uses 1024x768 by default,
> why should not KMS?
> 

640x480 is a the "preferred" resolution if using PAL or NTSC, otherwise you may notice fonts looks weird when in 1024x768 in PAL. Of course, you can always change it to 1024x768 or even higher if you like using xrandr.

(In reply to comment #26)
> (In reply to comment #22)
> > (In reply to comment #21)
> > > Now my TV uses 1024x768 both in console and in Xorg by default, just like the
> > > ddx.
> > > 
> > 
> > After a cleanup and retest I saw this was quite not true, now KMS uses 640x480.
> > At least it is a common mode, but still the intel ddx uses 1024x768 by default,
> > why should not KMS?
> > 
> 
> 640x480 is a the "preferred" resolution if using PAL or NTSC, otherwise you may
> notice fonts looks weird when in 1024x768 in PAL. Of course, you can always
> change it to 1024x768 or even higher if you like using xrandr.
> 

Yeah, I understood it was something like that behind the decision. Also I know both xrandr and viedo= on kernelcmd can workaround this.
Still maybe you graphic-driver-guys should try to figure out a standardresolution for this? If I connect my laptop with intel-ums to my TV (yeah, I know UMS-support is going away) I get 1024x768, if I connect my ati using KMS I get 800x600, intel-kms I get 640x400, nouveau I have not tested yet. But you maybe get my point? Maybe something to mail dri-devel about?

And there was also a bug related to that part which has been fixed (from the beginning the kernel choosed 848x480 by default).


The problem still standing is that glxgears/opengl apps does not work with any other resolution then 1024x764/NTSC-M and it is still not fixed (tried the kernel from linus git, merging in intel-drm-next about two days ago). I raised that here in this bug since I thought my problems were connected, but it seems like they were not. So the question is: should I repost that as another bug without the noise or should we track that one here?
Also what can I do to have it fixed?
All apps/resolutions seems to work nice with 2.9.1 and UMS, only with KMS it is broken. And I do not want to be left behind when I have to update to something that removes UMS-support.

I know the description is a bit ranty but here is what a boot up looks like using the default resolutions, and issuing xinit glxgears from console.

Could someone please tell me what to do to get this thing going? Else I do not really know what to do next dist-update when 2.10.0 with removed UMS starts rolling out...

http://www.youtube.com/watch?v=cFiL48TGaX8

Sounds like there are two issues here:
  1) starting up at 1024x768 by default
  2) running GL apps at less than 1024x768 doesn't work

Is that right?  For (1), you can create an xorg.conf to bring your TV up at a different resolution.

Bug (2) seems more serious.  We should have one of our Mesa developers check it out.

(In reply to comment #29)
> Sounds like there are two issues here:
>   1) starting up at 1024x768 by default

This problem is fixed, the default for KMS should be 640x400, but KMS started in 848x480 which neither my bootsplash or anything else I used handled fine (and therefore I thought the opengl-issue was because of this too). But as said this is fixed, and video= works fine if you want anything else (which it did not when this bug was opened).

>   2) running GL apps at less than 1024x768 doesn't work
> 

More seriously, opengl did not work for me for any resolution except 1024x768/NTSC-M.
Remember that for tv there also exists PAL (which I use, but tested the other NTSC-M resolutions for completeness), and it is broken with every PAL resolution (including 1024x768).
This is what is mostly bugging me, this computer is most of the time used for xbmc, and it depends on opengl, and thus do not work at all with KMS. And using NTSC-M does not give a good picture on my TV..

Took out 2.6.33-rc8 for a spin and noticed that the resolution fix seems like it has not landed (I have used drm-intel-next before on top, but when I compiled this, it did not merge cleanly). So in linus three, 848x400 still is the rather strange default resolution.

I also noted that the glx-flickering seems dependent on system load.
When I start glxgears the screen went crazy, but when I start xbmc there is almost no system load, no moving elements and no flickering, just a browser which jumps from time to time. However I noticed that if I log into the computer over ssh, and run a command it nearly always jumps as I press enter. It made me curious so I tried what would happend if I did "dd if=/dev/sda1 of=null". And the screen jumped around for just as long as dd took, as soon as dd was finished, the screen went back to displaying a flicker free menu.
And so I tested how it would react on something heavy on the CPU (folding@home), and the same result.

So KMS is busted when I give the system some load, but UMS works fine. Is this kernel related or mesa related, and what can I do to rule out stuff?

I start to more and more suspect that this is more related to system load then to gl.

While playing around (I tried mesa from git and different kernel configurations) to see if I could find any more info I broke my network. So instead of doing things from ssh I changed VT while using KMS, killed X (as I did not see any reason to have it in the background), and started to recompile my kernel with an old known working config.
And while compiling I could notice that the console text did jump several times sideways, just like xbmc could do while having minor system load.

So can we rule out mesa, and take it that opengl just exposes this bug more, or is there something other I should try out?

Today I decided to see how this computer did with Fedora, so I downloaded F12 livecd and F13-alpha livecd, unmodified and with standard settings booting from usb.

F12 boots fine (plymouth does not seem to start, tho) and runs glxgears fine.

F13-alpha boots fine and everything seems to work nice except the graphics.
During plymouth there is some vertical flickering, during gdm the flickering comes and goes, and so also while the autologin proceeds. At the desktop when the system hits idle the screen almost stops flickering. However do anything (open a menu, press Alt+F2) and the screen flickers. Starting glxgears and the flickers becomes a "roll".


The flickering (and the rolling) is always like frames places themselves wrong vertically, and the more load (disk load and gfx load seems to have bigger impact then for example CPU load) the more it looks like the picture starts to roll vertically. Also as even plymouth "flickers" I start to doubt more and more that this is a mesa-problem.

Is there anything I can do to help here? something I should test, something I should post, anything?

It seems like I am not the only one with this issue...

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/480220

The original bugreporters problems sound very much like mine.

Also the flickering is not a mesa-thing.

Removing /usr/lib/dri/i*_dir.so (leaving only swrast_dri.so behind) still displays these symptoms with 2.6.34-rc2. Also during fbsplash (a gentoo bootsplash implementation) when using KMS the logo flickers noticeable already before X has started.

So the current status of unpatched linus tree as of 2.6.34-rc4 (and seems also true for drm-intel-next):


Starting the kernel still gives you an unexpected resolution of 848x480.


S-Video is still garbage under system load (not depending on 3d).
I have a git bisect of when this first appeared (0d0884cee3099ec1271a5d379c39b66de1e31923) and reverting that commit on top of 2.6.34-rc4 fixes everything wrt to X (and the X.log says kms is used) but breaks everything else (i.e. console). 
And I have no clue on what more I can provide, what I can test or anything.

After trying out 2.6.35-rc2 and doing some research:

The bug about wrong mode (i.e. the kernel setting 848x480 by default) is still present.

The bug about garbled output is actually a timing issue, creating a newmode with all the same specs but the Mhz value about doubled creates a stable picture on my TV.

Hm I'll have to dig out my one machine with s-video and see what I can find.

Hah, I thought this bug looked familiar, see also bug 28012 ;-)

Synopsis from 28012 is that there appears to be no difference in the mode registers between either ums/kms/kms+double+pixel+clock. Jesse you might like to review the register dumps Peter attached to that bug to check our conclusions.

So where is the discrepancy hiding?

I basically want to use my i915 based laptop as a simple HTPC in combination with my old PAL based TV. I would also be interested in what I could do to help getting this fixed. Are there any workarounds I could try out?

The flickering appears always for any pclk < 20, independent of screen resolution or refresh rate.

I could reproduce with 2 different boards: 945GME and 82945G/GZ. 

On the first one I had to add newmodes forcing the pclk >= 20 in order to avoid the flickering:

xrandr --newmode "640x480_20" 20  640 664 720 800  480 483 487 500
xrandr --addmode TV1 "640x480_20"
xrandr --output TV1 --mode 640x480_20

On the 82945G/GZ the flickering wasn't appearing in any resolution so I forced pclk <= 19.99 in order to get it flickering.

*** Bug 38044 has been marked as a duplicate of this bug. ***

Created attachment 54488 [details] [review]
drm/i915: Fix TV Out refresh rate.

TV Out refresh rate was half of the specification for almost all modes.
Due to this reason pixel clock was so low for some modes causing flickering screen.

Created attachment 57544 [details]
Xorg config file

Applied the patch given by Rodrigo Vivi in comment 43. Greatly improves the "flickering" effect, but it is not fully resolved. Attached Xorg logs and other information about the system that we're still seeing the issue on. All files prefixed with GTECH to differentiate it from the logs already uploaded.

Created attachment 57545 [details]
Xorg startup log

Additional files as mentioned in comment 44. Not sure if any more information is needed, please holler and i shall provide. Am also trying to upload a video file that shows the problem elsewhere.

Created attachment 57546 [details]
GTECH - Kernel dmesg output

Created attachment 57547 [details]
GTECH - kernel and Xorg version info

Created attachment 57548 [details]
GTECH - lsmod - i915 and other drivers loaded as modules

Created attachment 57549 [details]
GTECH - lspci output

Created attachment 57550 [details]
GTECH - Xorg config file

Created attachment 57551 [details]
GTECH - Xorg log file

Created attachment 57552 [details]
GTECH - verbose xrandr output

Created attachment 57555 [details]
GTECH - video of problem on Composite output

Thanks for all this info.

Could you please boot it with drm.debug=0xe and post dmesg output again?

Also could you please the correct xrandr output. This one says that the current mode is 640x480.

Created attachment 57642 [details]
Contents of /var/log/messages with drm.debug set to 0xe

The mode of the secondary composite TV output is indeed 640x480 only, the primary VGA is at 800x600. We need to run TV-out at 640x480, which is where we see the problem. Please find output of /var/log/messages, with the drm.debug parameter set to 0xe.

Not sure if this has been mentioned before, we face the problem only with Composite and S-video output, not with component.

Some more information: The kernel we're running at is 2.6.31.7, but the drm stack has been upgraded to 2.6.32.24. This was done to enable widescreen display support, and also to try to solve the problem with the TV-out. That did not help. I then patched in the fix provided in comment 43, and that is where we stand currently.

Closing this, the original reporter seems to have disappeared.

To unnikrishnan: Please reopen a new bug for your issue, but please test first on kernel 3.3 - kernel 2.6.32 is pretty much stone-age for graphics issues and far away from relevant for upstream development.

Ok, _really_ closing this. I've re-read all the comments, and the flicker should be fixed with Rodrigo's patch to double the pixelclock of some of the default TV-out modes.

The default mode is just that, if someone feels strongly I'm willing to merge a patch to change it.

unnikrishnan: Please open a new bug report for your issue and put a link in here so people know where to look for it.

Closing resolved+fixed. No activity on >4 years.