[i945] [i945][karmic] S-Video: PAL output is garbled

[Stefano Mosconi]

Binary package hint: xserver-xorg-video-intel

Hi I have a DELL latitude D520 with intel graphics 945.

I used the S-video output with no problem in the latest stages of jaunty (at the beginning performances were not super, but recently quite fair).

Updated to karmic and the same config file didn't work anymore. Tried to make some tweaks (which result you see attached) but still I have some problems.

1) Option "TV CONNECTOR" "S-Video" is not honored anymore (This means I have to start X with the cable connected otherwise I'm screwed, no big deal though)
2) Option "TV_FORMAT" "PAL" is not honored anymore (this means the S-video out starts with NTSC, no big deal I can change it with xrandr)
3) Doing xrandr --output "TV1" --set "mode" "PAL" sets correctly the mode to PAL _but_ the output is garbled.

Garbled means that the image is not stable on the TV, I see blocks going around, flickering and other things happening _but_only_ if I start to move windows around or play a movie or type something on the keyboard or move the mouse. Basically whenever there is a refresh of the screen.

This is actually a big deal since I don't know how to work it around.

Can anybody tell me in the meantime how to revert to 2.6.3 (latest jaunty version)? I tried a stupid downgrade that obviously didn't work. Should I downgrade also the kernel and xorg?

Attaching whatever log I can think of.

xrandr.NTSC-M.not_garbled.log is the xrandr output just after the computer started and the output on S-video is NTSC-M and the screen does not flickr (though it's B/W).

xrandr.PAL.garbled.log is the xrandr output after doing xrandr --output "TV1" --set "mode" "PAL".

I tried also to change the resolution of the TV1, turning off the LVDS1, but nothing helped.

[Xake (xake-rymdraket)]

Created an attachment (id=29480)
dmesg

[Xake (xake-rymdraket)]

Created an attachment (id=29481)
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.

[yakuizhao (yakui-zhao)]

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.

[Xake (xake-rymdraket)]

Created an attachment (id=29535)
dmesg of 2.6.30

[Xake (xake-rymdraket)]

Created an attachment (id=29536)
dmesg 2.6.31

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

[Xake (xake-rymdraket)]

Anything more you need from me?

[Xake (xake-rymdraket)]

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>

[Xake (xake-rymdraket)]

Created an attachment (id=29789)
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.

[Xake (xake-rymdraket)]

Created an attachment (id=29790)
kernel-2.6.31.log drm.debug=15

[Xake (xake-rymdraket)]

Created an attachment (id=29791)
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.

[yakuizhao (yakui-zhao)]

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.

[Xake (xake-rymdraket)]

(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?

[Xake (xake-rymdraket)]

Created an attachment (id=30258)
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.

[Xake (xake-rymdraket)]

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

[Xake (xake-rymdraket)]

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?

[Xake (xake-rymdraket)]

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
 ...

[Xake (xake-rymdraket)]

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

[Stefano Mosconi (stezz)]

Binary package hint: xserver-xorg-video-intel

Hi I have a DELL latitude D520 with intel graphics 945.

I used the S-video output with no problem in the latest stages of jaunty (at the beginning performances were not super, but recently quite fair).

Updated to karmic and the same config file didn't work anymore. Tried to make some tweaks (which result you see attached) but still I have some problems.

1) Option "TV CONNECTOR" "S-Video" is not honored anymore (This means I have to start X with the cable connected otherwise I'm screwed, no big deal though)
2) Option "TV_FORMAT" "PAL" is not honored anymore (this means the S-video out starts with NTSC, no big deal I can change it with xrandr)
3) Doing xrandr --output "TV1" --set "mode" "PAL" sets correctly the mode to PAL _but_ the output is garbled.

Garbled means that the image is not stable on the TV, I see blocks going around, flickering and other things happening _but_only_ if I start to move windows around or play a movie or type something on the keyboard or move the mouse. Basically whenever there is a refresh of the screen.

This is actually a big deal since I don't know how to work it around.

Can anybody tell me in the meantime how to revert to 2.6.3 (latest jaunty version)? I tried a stupid downgrade that obviously didn't work. Should I downgrade also the kernel and xorg?

Attaching whatever log I can think of.

xrandr.NTSC-M.not_garbled.log is the xrandr output just after the computer started and the output on S-video is NTSC-M and the screen does not flickr (though it's B/W).

xrandr.PAL.garbled.log is the xrandr output after doing xrandr --output "TV1" --set "mode" "PAL".

I tried also to change the resolution of the TV1, turning off the LVDS1, but nothing helped.

[Xake (xake-rymdraket)]

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?

[yakuizhao (yakui-zhao)]

Created an attachment (id=31433)
don't set "848x480" as preferred mode for NTSC/PAL/480p

[yakuizhao (yakui-zhao)]

(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?
>

[Xake (xake-rymdraket)]

(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.

[xian02 (ugo-s)]

Hi there!
Same problem for me.
It sure doesn't help, but you're not alone anymore...
see ya

[Xake (xake-rymdraket)]

(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?

[Xake (xake-rymdraket)]

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?

[Xake (xake-rymdraket)]

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.

[Abhijit Bhopatkar - BAIN (bain-devslashzero)]

Ok i was about to give up on this. I also had the same problem, however i had also changed my laptops and never thought it just being a karmic problem. And just when i was about to give up i read your bug report. And yuppie i found a solution.

Not elegant but it works.

Here it comes.

Disable kernel modesetting ......

Thats it ... the driver behaves just like the old one and all is well again. There are plenty of instructions on google to do this, one way i used is to append nomodeset to kernel command line.

HTH
Cheers

[Xake (xake-rymdraket)]

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?

[Michael Fu (michael-fu-intel)]

(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.

[Xake (xake-rymdraket)]

(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.

[Xake (xake-rymdraket)]

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

[Jesse Barnes (jbarnes-virtuousgeek)]

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.

[Xake (xake-rymdraket)]

(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..

[Jörg Welzel (welzel-everswinkel)]

This seems to be my problem, too.

The option TV_Format "PAL" isn't honored in the xorg.conf nor by a xrandr command.

With Windows XP it works!

May the solution be to upgrade to Lynx?

[Xake (xake-rymdraket)]

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?

[Xake (xake-rymdraket)]

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?

[Vikram Dhillon (dhillon-v10)]

This issue was reported against karmic, so can you confirm if this issue exists with the most recent Lucid Lynx 10.04 Alpha release? ISO CD images are available at http://cdimage.ubuntu.com/releases/lucid/ . Thanks in advance.

[Jörg Welzel (welzel-everswinkel)]

Vikram Dhillon schrieb:
> This issue was reported against karmic, so can you confirm if this issue
> exists with the most recent Lucid Lynx 10.04 Alpha release? ISO CD
> images are available at http://cdimage.ubuntu.com/releases/lucid/ .
> Thanks in advance.
>
> ** Changed in: xserver-xorg-video-intel (Ubuntu)
> Status: New => Incomplete
>
>
Hallo,

to add my considerations:

I use an intel Video card onboard (intel atom CFL...).
There is a 7-pin connector for TV-out! There is provided both a
composite-signal and an S-video signal.

With windows xp, one can get a signal from the s-video pins. The signal
can be changed between PAL and NTSC.

With kubuntu 9.04 there was a signal at the S-video pins or at the
composite pins! Both only with NTSC format! No PAL

With kubuntu 9.10 there is only a signal at the S-Video pin. Only NTSC,
no PAL.

The command xrandr --output TV TV_Format PAL or NTSC is ignored. With
connector the same result.

I tried the 2:2.10.0 driver from
http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu
It does'nt work at all. No change with the Xrandr command.

I need the PAL-Signal, because the quality ist much better than the
NTSC-signal. At the meantime I use a converter from S-video to
Composite. I would like to use the composite pins.

[Jörg Welzel (welzel-everswinkel)]

The problem is the same with lucid! I tried the live-CD.

[Bryce Harrington (bryce)]

[Resetting to incomplete since we need a response from the original reporter on this].

[Stefano Mosconi (stezz)]

I think you need to trust jorg since I gave away that laptop. sorry :)

[Jörg Welzel (welzel-everswinkel)]

I think there is a connection with this bug report:

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

Maybe the problem has the same origin

[Xake (xake-rymdraket)]

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?

[Jörg Welzel (welzel-everswinkel)]

Bryce Harrington schrieb:
> ** Tags added: corruption
>
> ** Tags added: tv-out
>
>
There is a possible solution at this site:

http://fthieme.net/de/blog/2010/03/11/pal-auf-intel-grafik
<http://fthieme.net/de/blog/2010/03/11/pal-auf-intel-grafik>

The standard theme for TV-out is NTSC. Changing with the command
TV_Format "Pal" ist ignored because obviously it isn't implemented.

[Xake (xake-rymdraket)]

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.

[Xake (xake-rymdraket)]

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.

[Xake (xake-rymdraket)]

@Jörg:

first:
you are using the wrong command.
To set your output to PAL with xrandr the correct command is:

xrandr --output TV1 --set mode PAL

second:
PAL should be supported. But it seems like upstream has problems tracking this issue on why the output becomes garbled.
And using a 2.6.33 kernel the only thing I can get working is NTSC/1024x768 (trying out NTSC/640x400 which should be the driver default also breaks).

[Xake (xake-rymdraket)]

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.

[Jörg Welzel (welzel-everswinkel)]

Here may be some news:

https://bugs.freedesktop.org/show_bug.cgi?id=23916

With the kernel Version 2.6.34.966 on
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current/

the correct modi of TV-standard are delivered! This were not with the older kernels and is new for me!

But my problem isn't solved, yet:

                          The command
 xrandr --output TV1 --mode PAL_B
                                                    delivers following:

xrandr: cannot find mode PAL_B

further: now i get four (4!!) devices! 2 VGA and 2 TV-out!

Here the answers of the system of the xrandr command:

 xrandr --verbose
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 4096 x 4096
VGA1 connected 1600x900+0+0 (0x3f) normal (normal left inverted right x axis y axis) 443mm x 249mm
        Identifier: 0x3b
        Timestamp: 2747135
        Subpixel: unknown
        Clones: TV1
        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:
        EDID_DATA:
                00ffffffffffff000472f800eb0d3094
                2b130103082c19782eee95a3544c9926
                0f5054bfee80a9c0714f81c081000101
                010101010101312e40006284223058a8
                3500bbf910000004000000fd00374b1e
                5010000a202020202020000000fc0056
                6973656f323030540a202020000000ff
                004432323042303031373531302000cb
  1600x900 (0x3f) 118.2MHz -HSync +VSync *current +preferred
        h: width 1600 start 1688 end 1856 total 2112 skew 0 clock 56.0KHz
        v: height 900 start 903 end 908 total 934 clock 59.9Hz
  1280x800 (0x40) 83.5MHz +HSync -VSync
        h: width 1280 start 1352 end 1480 total 1680 skew 0 clock 49.7KHz
        v: height 800 star...

[Xake (xake-rymdraket)]

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.

[Jesse Barnes (jbarnes-virtuousgeek)]

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

[Chris Wilson (ickle)]

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?

[Till W. (tillw.)]

Absolutely the same here for me (i915GM in a Dell D410 used with D-Dock's TV output, Ubuntu 10.04, kernel 2.6.32-27-generic).

After boot I have a stable NTSC output but can switch to PAL using "xrandr --output TV1 --set mode PAL". However, the picture gets unstable then: every time I move the mouse or have a lot of harddrive activity the TV picture jumps up and down, sometimes only some (rectangular) areas of the picture are affected. When there is no mouse movement the picture is stable.

$ xrandr --verbose
...
TV1 connected 1024x768+0+0 (0x4f) normal (normal left inverted right x axis y
...
 1024x768 (0x4f) 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

When I create & use a new modeline with doubled dotclock like this:

$ xrandr --newmode foo 54 1024 1025 1088 1120 768 769 800 801

...I get a stable picture.

BTW: If there is no connection to the TV set at boot time, xrandr will always show "TV1 disconnected" no matter if I plug in the TV out cable or not. Maybe both effects are caused by kernel mode settings. I have to try with disabled KMS.

[sewert (ewi100)]

I just want to say that I observe exactly the same behaviour as Xake. And it is really sad that after such a long time the bug is still present. But thanks to Xake for trying out so many options and keeping the bug alive (and valid).

Configuration:
i915 (Centrino 1)
Ubuntu 10.10 (Stock)

[sewert (ewi100)]

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?

[Rodrigo-vivi (rodrigo-vivi)]

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.

[Rodrigo-vivi (rodrigo-vivi)]

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

[Rodrigo-vivi (rodrigo-vivi)]

Created attachment 54488
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.

[Unnikrishnan-am (unnikrishnan-am)]

Created attachment 57544
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.

[Unnikrishnan-am (unnikrishnan-am)]

Created attachment 57545
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.

[Unnikrishnan-am (unnikrishnan-am)]

Created attachment 57546
GTECH - Kernel dmesg output

[Unnikrishnan-am (unnikrishnan-am)]

Created attachment 57547
GTECH - kernel and Xorg version info

[Unnikrishnan-am (unnikrishnan-am)]

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

[Unnikrishnan-am (unnikrishnan-am)]

Created attachment 57549
GTECH - lspci output

[Unnikrishnan-am (unnikrishnan-am)]

Created attachment 57550
GTECH - Xorg config file

[Unnikrishnan-am (unnikrishnan-am)]

Created attachment 57551
GTECH - Xorg log file

[Unnikrishnan-am (unnikrishnan-am)]

Created attachment 57552
GTECH - verbose xrandr output

[Unnikrishnan-am (unnikrishnan-am)]

Created attachment 57555
GTECH - video of problem on Composite output

[Rodrigo-vivi (rodrigo-vivi)]

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.

[Unnikrishnan-am (unnikrishnan-am)]

Created attachment 57642
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.

[Unnikrishnan-am (unnikrishnan-am)]

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

[Unnikrishnan-am (unnikrishnan-am)]

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.

[Daniel-ffwll (daniel-ffwll)]

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.

[Daniel-ffwll (daniel-ffwll)]

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.

[Jari-tahvanainen (jari-tahvanainen)]

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