Bug 17776 - [945GC SDVO-TV ]TV out not working
[945GC SDVO-TV ]TV out not working
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
unspecified
x86 (IA32) Linux (All)
: high major
Assigned To: Wang Zhenyu
Xorg Project Team
:
: 9992 18210 18541 18874 (view as bug list)
Depends on:
Blocks: 22891
  Show dependency treegraph
 
Reported: 2008-09-25 15:09 UTC by Till
Modified: 2009-07-22 07:24 UTC (History)
23 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xrandr Error file (205 bytes, text/plain)
2008-09-25 15:09 UTC, Till
no flags Details
patch where I tried to enable PAL as default (2.50 KB, patch)
2008-09-25 15:11 UTC, Till
no flags Details | Splinter Review
log file when the bug appears (45.39 KB, text/plain)
2008-09-25 15:13 UTC, Till
no flags Details
xorg.conf where the bug occurs (4.02 KB, text/plain)
2008-09-25 15:14 UTC, Till
no flags Details
Xorg log with i810 driver where tv out seems to be detected, but driver does not work (51.12 KB, text/plain)
2008-09-25 15:15 UTC, Till
no flags Details
Xorg.conf for i810 driver where tv out seems to be detected, but driver does not work (4.02 KB, text/plain)
2008-09-25 15:19 UTC, Till
no flags Details
xorg log for patched version using patch #19211 (xorg conf is identical to attachment#19213) (45.08 KB, text/plain)
2008-09-25 15:21 UTC, Till
no flags Details
Xorg.0.log with 2.6.99.1+git20081220.d8e89b26-0ubuntu0tormod (20.65 KB, application/octet-stream)
2008-12-21 10:59 UTC, Luka Renko
no flags Details
Xorg.0.log with ModeDebug and xorg.conf with 2.6.99.1+git20081220.d8e89b26-0ubuntu0tormod (60.50 KB, text/plain)
2008-12-21 11:00 UTC, Luka Renko
no flags Details
xorg.conf used to override PAL mode and Modeline (543 bytes, application/octet-stream)
2008-12-21 11:01 UTC, Luka Renko
no flags Details
SDVO TV debug patch (9.05 KB, patch)
2009-02-02 22:25 UTC, Wang Zhenyu
no flags Details | Splinter Review
Xorg.0.log with sdvo-tv-debug.patch (42.02 KB, application/gzipped-patch)
2009-02-07 07:10 UTC, Luka Renko
no flags Details
SDVO TV fix patch (11.60 KB, patch)
2009-02-11 23:32 UTC, Wang Zhenyu
no flags Details | Splinter Review
Xorg.0.log after patch in NTSC mode (380.32 KB, text/plain)
2009-02-12 14:24 UTC, Sven Ginka
no flags Details
Xorg.0.log with fix (working on PAL TV) (73.76 KB, application/octet-stream)
2009-02-13 10:03 UTC, Luka Renko
no flags Details
ebuild for Gentoo (13.25 KB, application/octet-stream)
2009-02-15 05:33 UTC, Till
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Till 2008-09-25 15:09:55 UTC
Created attachment 19210 [details]
xrandr Error file

trying to enable TV output using the intel driver version 2.4.2-r1 (gentoo) on a D945GCLF2 board (945GC Express chipset, atom processor), apparently the detection of PAL support (and modes) does not work resulting in a picture that is completely out of sync with my tv. the driver tries to use 1024x786 at 60 Hz on a pal tv which needs 720x576@50 Hz interlaced.
TV out works for the console, if I don't have a vga monitor plugged in.
in the Xorg.0.log I get a message telling me that the default tv format NTSC-M is used even though I have
Option "TV Format" "PAL"
(also tried Option "TV_FORMAT" "PAL")
in my xorg.conf
xrandr --output TV --set TV_FORMAT PAL gives an error (see attached file xrandr.err).
I tried to change the default TV mode to PAL in the driver but then I get errors saying that the mode clock is too low (see Xorg.0.log.patched)
With respect to the TV out, the old (1.7.4) i810 drivers seem to work better. The TV is detected by the driver, and shows the same picture as the CRT. Unfortunately this picture is garbled and the x server crashes (Xorg.0.log.i810.1.7.4).
I use a 2.6.25 kernel and have the i915 drivers built in.
Comment 1 Till 2008-09-25 15:11:55 UTC
Created attachment 19211 [details] [review]
patch where I tried to enable PAL as default
Comment 2 Till 2008-09-25 15:13:07 UTC
Created attachment 19212 [details]
log file when the bug appears
Comment 3 Till 2008-09-25 15:14:27 UTC
Created attachment 19213 [details]
xorg.conf where the bug occurs
Comment 4 Till 2008-09-25 15:15:27 UTC
Created attachment 19214 [details]
Xorg log with i810 driver where tv out seems to be detected, but driver does not work
Comment 5 Till 2008-09-25 15:19:14 UTC
Created attachment 19215 [details]
Xorg.conf for i810 driver where tv out seems to be detected, but driver does not work
Comment 6 Till 2008-09-25 15:21:03 UTC
Created attachment 19216 [details]
xorg log for patched version using patch #19211 (xorg conf is identical to attachment#19213 [details])
Comment 7 Till 2008-09-26 02:14:36 UTC
for me this issue is quite severe, since I want to use the tv as the only monitor
Comment 8 Gordon Jin 2008-09-27 06:32:52 UTC
Zhenyu, D945GCLF2 is exactly our "little falls" board from CPG. Is that SDVO TV-out or integrated TV-out?
Comment 9 Till 2008-09-27 12:50:20 UTC
The TV is connected to the integrated S-Video connector that is on board, not to an extra card.
Comment 10 Till 2008-09-27 12:53:03 UTC
If I can help in any way with testing etc, let me know. I don't have any experience with programming in C, however. But I can apply and create patches and compile from source...
Comment 11 Daniel Meyer 2008-10-03 21:40:40 UTC
I have the same problem with the same motherboard too. My TV is capable of receiving NTSC, PAL and also PAL60, but i cannot get the D945GCLF2 to display a clear and stable picture on the TV using xorg.

I'm also using gentoo with the 2.4.2-r2 drivers. I'm going to try some other distros today and will report back here.
Comment 12 Daniel Meyer 2008-10-04 02:24:19 UTC
Ok, i've tested it with 3 different TVs now, and with the OpenSuSE 11.0 Live CD, the Ubuntu 8.10 Beta CD and even with the XBMC Live CD (based on Ubuntu 8.04).

I get the same result every time. 
Comment 13 Gordon Jin 2008-10-07 18:21:42 UTC
Zhenyu, I think little falls using SDVO TV-out. If so, this is dup with bug#9992.
Comment 14 Gordon Jin 2008-10-25 20:40:37 UTC
*** Bug 18210 has been marked as a duplicate of this bug. ***
Comment 15 Matt 2008-10-27 07:02:21 UTC
Has anyone found a workaround, such as using fbdev or anything?
Comment 16 Matteo Croce 2008-10-27 17:50:57 UTC
I compiled the driver from GIT, i can see some pictures but they go up and down, like a refresh issue.
Maybe because the output is NTSC?
Also, why my Xorg sees the monitor as TV-1?
With a previous driver (2.4) it was VGA-1
Comment 17 Matteo Croce 2008-10-27 17:56:07 UTC
The D945GCLF2 board is becaming  more and more popular.
I can say this for sure, i work for a company which makes kiosks,
we do plan switching from current solutions to the D945GCLF2 as it has _great_ performances
with linux 64 bit, but wee need TV output.
Please fix.
Comment 18 Till 2008-10-28 03:44:24 UTC
(In reply to comment #16)
> I compiled the driver from GIT, i can see some pictures but they go up and
> down, like a refresh issue.
> Maybe because the output is NTSC?
I do not think the problem is NTSC, since Daniel (Comment #11) also had sync issues even though his TV is NTSC capable. Also in Bug #18210 someone with a NTSC TV had this issue.
I guess the problem is rather, that the driver tries to address the TV like a VGA monitor, not like a TV.

> Also, why my Xorg sees the monitor as TV-1?
Same for me...

Comment 19 Matteo Croce 2008-10-28 04:09:33 UTC
Daniel, with the 2.4.2 driver the card will see the monitor as a second VGA monitor,
so you will end up with VGA and VGA-1, which is wrong.
You HAVE to use 2.5.0 to detect the TV as TV-1, but that doesn't works for me, dunno if
it's because the PAL/NTSC issue or other stuff.

Anyway, the S-Video connector onboard is internally connected to a SDVO port.
Comment 20 Daniel Meyer 2008-10-28 04:16:25 UTC
(In reply to comment #19)
> Daniel, with the 2.4.2 driver the card will see the monitor as a second VGA
> monitor,
> so you will end up with VGA and VGA-1, which is wrong.
> You HAVE to use 2.5.0 to detect the TV as TV-1, but that doesn't works for me,
> dunno if
> it's because the PAL/NTSC issue or other stuff.
Hm, the driver detected the TV as TV-1. The older drivers detected it as VGA-1.

But i've already switched to a mainboard with nvidia onboard graphics (yes intel, there is a business case here) and ended up with only 4 watts more powerconsumption (idle)... The 945GC chipset is really bad for the atom cpu. 

I'll follow the bug anyway, just to see if the situation with the S-Video output get fixed and the board gets usable for future projects.

Comment 21 Matteo Croce 2008-10-28 04:39:16 UTC
src/i830_driver.c:930

if (IS_I9XX(pI830) && IS_MOBILE(pI830))
   i830_tv_init(pScrn);

it should be self explanatory

Daniel: what nvidia board do you have? It's a business case here too, my company makes kiosks
Comment 22 Till 2008-10-28 05:02:46 UTC
(In reply to comment #20)
> Hm, the driver detected the TV as TV-1. The older drivers detected it as VGA-1.
> 
The same is true in my case (see the Xorg.0.logs I posted). I used driver versions 2.4.2-r2, 2.4.2-r3 (gentoo). Both detect TV as TV-1, while some earlier version (I think 2.4.0) detected the second output as VGA-1.

> But i've already switched to a mainboard with nvidia onboard graphics (yes
> intel, there is a business case here) and ended up with only 4 watts more
> powerconsumption (idle)... The 945GC chipset is really bad for the atom cpu. 
I totally agree, 22 watts power consuption for the chipset versus 8 for the cpu...
I guess the point is, that it is REALLY cheap ;-)
Comment 23 Matteo Croce 2008-11-03 08:51:12 UTC
Wang: i see that you posted 6 patches to the intel-gfx mailing list, are they intended to fix this bug?
Comment 24 Wang Zhenyu 2008-11-03 17:30:07 UTC
No, those patches are for integrated TV encoder, not SDVO TV on littlefall board. I'm looking into it on a littlefall board here.
Comment 25 Gordon Jin 2008-11-15 03:28:46 UTC
*** Bug 18541 has been marked as a duplicate of this bug. ***
Comment 26 Todd Brunhoff 2008-11-15 14:05:20 UTC
(In reply to comment #25)
> *** Bug 18541 has been marked as a duplicate of this bug. ***

That was my bug. I've been looking at a workaround using 2.5.1 code. It appears that the probed mode lines are all progressive. For example, one of the lowest dot clocks probed by the driver is

    Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync

Yet the modelines suggest for analog ntsc here (http://www.mythtv.org/wiki/index.php/Modeline_Database#NTSC_.28Analog.29) Look like.

    ModeLine "720x480@30i" 13.5   720 736 799 858  480 486 492 525 interlace -hsync -vsync

I think this would actually work in the intel driver... except that the driver vetos the mode because the "mode clock" is too low. That's because the configuration of the PIPE B at that point causes the hardware to state the clock range as 25.0MHz - 160.0MHz.

This leads me back again to the suspicion that, at the time the code asks about the clock range, the hardware has been configured for progressive, not interlaced. The Pipe B Configuration Register contains 3 bits for setting interlace, but I don't know the code well enough to map the Intel documentation onto the code. It looks like there is a byte-wide i2c interface to 32-bit registers.

If you could point me at some code docs or just give me some hints about when the interlace bits should be set, I might be able to help a bit (25 years developing broadcast hw/sw for companies like Tektronix).
Comment 27 Todd Brunhoff 2008-11-15 21:59:19 UTC
Here is a minor bug, it seems, in i830_sdvo_check_tv_format. It checks the current output format and (is supposed to) set it to ntsc if nothing has been set. This is not a fix for this particular bug, but is somewhat related.

*** i830_sdvo.c.orig    2008-11-15 21:06:44.000000000 -0800
--- i830_sdvo.c 2008-11-15 21:06:01.000000000 -0800
***************
*** 1567,1579 ****
        return;
  
      memset(&unset, 0, sizeof(unset));
!     if (memcmp(&format, &unset, sizeof(format))) {
        xf86DrvMsg(pScrn->scrnIndex, X_INFO,
                   "%s: Choosing default TV format of NTSC-M\n",
                   SDVO_NAME(dev_priv));
  
        format.ntsc_m = TRUE;
!       i830_sdvo_write_cmd(output, SDVO_CMD_SET_TV_FORMAT, NULL, 0);
        status = i830_sdvo_read_response(output, NULL, 0);
      }
  }
--- 1567,1579 ----
        return;
  
      memset(&unset, 0, sizeof(unset));
!     if (memcmp(&format, &unset, sizeof(format)) == 0) {
        xf86DrvMsg(pScrn->scrnIndex, X_INFO,
                   "%s: Choosing default TV format of NTSC-M\n",
                   SDVO_NAME(dev_priv));
  
        format.ntsc_m = TRUE;
!       i830_sdvo_write_cmd(output, SDVO_CMD_SET_TV_FORMAT, &format, sizeof(format));
        status = i830_sdvo_read_response(output, NULL, 0);
      }
  }
Comment 28 Wang Zhenyu 2008-11-16 19:41:18 UTC
yeah, we have some wrong usage on those SDVO TV commands in the driver, I might try to clean up my current hacks, and let you try it which contains that fix and others.

Intel published graphics doc is at http://www.x.org/docs/intel/, you can find display related chapter there, _but_ SDVO spec is not open yet.

Comment 29 Matt 2008-11-21 08:43:56 UTC
(In reply to comment #28)
> I might
> try to clean up my current hacks, and let you try it which contains that fix
> and others.

I'd also be willing to test any fixes to help move this along.
Comment 30 Marek Mintal 2008-11-23 05:18:12 UTC
Wang,

Any progress on this bug ? I'd also like to help with testing.
I've did a several hacks to the driver 2.5.1 (i830_sdvo_get_tv_modes() 50 Hz modes, added missing 768x576 mode) but without success, the D945GCLF2 TV-1 output will not set the proper Horizontal frequency at all ...

Thanks,

Marek
Comment 31 ullix 2008-11-23 09:46:17 UTC
I also have the D945GCLF2 board and cannot get the TV to work. Ubuntu Intrepid is installed. I tried it with two TVs, one a genuine US set, and one a European PAL set (possibly also accepting NTSC). When either set is connected but no VGA, then a stable picture can be seen on either TV set. But as soon as Xserver starts, the TV picture is rolling through. VGA is always ok. The TV picture responds to mode changes, but TV_FORMAT can never be set. I did a bug report at ubuntu launchpad, but I believe I was mistaken in the cause for the problem. (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/298422) 

When I try the same ubuntu intrepid installation on a laptop with a 965GM chipset (Acer Extensa 5220), everything works fine. However, I noticed that the output of 'xrandr --verbose' on the two systems is very different: On the 965 it tells me what TV mode is used, and which are available, while on the 945 nothing of this nature is shown, as if it were no TV outlet. The Xorg.log have similar differences. Setting TV formats (to PAL, or NTSC, or other): on 965:works, on 945: 'BadName' error message that 'TV_FORMAT' is not recognized.

I believe that the driver is not even recognizing this is as a TV outlet despite the suggestive name TV-1. Under Ubuntu Hardy it shows as VGA-1, and also does not work on TV. The rolling-through picture is in color, btw.

This nice little system is intended to work as a media center, so the s-video not working it a real bummer!
Comment 32 Gordon Jin 2008-12-04 00:14:54 UTC
*** Bug 18874 has been marked as a duplicate of this bug. ***
Comment 33 mike 2008-12-04 09:21:56 UTC
(just joined mailing list)
I've actually done some scope probing of the signal, and to me, I see a 100hz desktop being overlayed onto a 60hz tv frame (hence, the rolling).  I've posted some pics of the scope capture (3rd post down)over at http://www.linuxquestions.org/questions/linux-hardware-18/945g-s-video-out.-x-vsync-refresh-rate-error-let-me-buy-you-lunch-685454/  .

The s-video decoder is a ch7021a, that communicates with the 945g via I2C bus. 
I've yet to dust off the I2C sniffer to see if I can backward engineer the commands needed...  (walking  bit's with an index finger and a logic analyzer screen is too painful). 

The ch7021 datasheets can be found here -> http://www.chrontel.com/products/7021.htm



Comment 34 Todd Brunhoff 2008-12-04 09:57:40 UTC
The intel guys appear to have gone silent. Perhaps they are on vacation.

Interesting note about the 100hz overlayed on 60hz output. As far as I can tel, all versions of intel code for X appear to fall well short of correctly configuring the downstream SDVO part (Chontel 7021), including the git archive.

I installed windows vista home premium (blech) and it apparently has all the right code to treat the svideo output correctly. You might try booting that (maybe XP will work as well), because it appears to have made a state change in the Chrontel part. It appears that the TV-1 frame buffer can be rendered at any resolution and refresh, and that the appointed task of the Crontel part at the other end of the SDVO bus is to correctly resample that for the appropriate signal, which in this case *should* be ntsc or pal.

Absent any other hints from Intel folks, I hope to dig into this over the holidays and try to capture the SDVO state of the Crontel under Vista, and recreate it under X.  I think that's what's required.
Comment 35 Till 2008-12-05 04:59:31 UTC
Mike and Todd,

Way to go! If I can help you in any way (e.g. testing), let me know.
Zhenyu, maybe you could help out with some specs?

Till
Comment 36 mike 2008-12-07 23:15:54 UTC
Just a quick update.  I'm spending some time, after this weekend re-writing my i2c sniffer probe code after I found out that there is in fact, a whole lot of stuff being written to that chrontel part, and my probe buffer is only 90 bytes long. Even then, I'm not sure I'll be able to make hide-nor-hair of what's going on, because it's a LOT of stuff. In fact, a whole 5000 byte buffer fills up in about a second.  This is still during posting, and after post it doesn't get much better (the buss didn't look 'shared', just a straight shot from chrontel to the 945). 

     Here's an example of just one line of hundreds that gets written to i2c address 0x70 (chrontel).

70.04.05.38.01.60.1C.00.00.8E.01.03.87.00.2B.10.19.80.40.D8.C0.29.E2.57.

Followed by a read;

71.C0.38.08.5C.B4.4E.02.57.23.13.00.95.88.0C.C0.20.70.E0.14.

and there are pages of this stuff. (..yeah,  Ouch!)

I'll hopefully get to test out some new probe code this coming week. I'll have some P,S,R indicators (stop,start,restart) too. However, I see a dual port ram being added to the probe too. 

Comment 37 Todd Brunhoff 2008-12-08 08:49:23 UTC
Your sniffer output could be very useful... I take it you are sniffing during boot up of windows Vista. To minimize the amount of i2c data written which correctly configures the chrontel part, you might try (a) bring up X, to get things screwed up; then (1b) shut down and set move the "configuration" jumper so that only the bios comes up and see if it correctly configures the chrontel. If it does, and you see a coherent ntsc/pal signal, and you are able to capture (1b) after doing (a), that may be the minimal set if i2c data.

If that fails, try (a) bring up X, then (2b) reboot with windows vista in safe mode or perhaps from the windows install CD. Either of those may produces less data.

In any case, I would suggest only having an s-video cable connected, which appears to be correctly detected by the hardware and the OS.

Also, I assume you are able to capture a synchronized flow from both directions, because several of the commands are queries which have corresponding replies from the chrontel.

Once you have that stream, I might be able to work backwards to figure out which commands are the key to bringing up X on the S-video.

You realize of course, that all this effort would evaporate if someone were to send you and me $2,000 with which we could buy a HDTV with a vga input.
Comment 38 Luka Renko 2008-12-21 07:57:54 UTC
Another interested user/tester: same problem on PAL TV.
Running on Ubuntu Jaunty with 2.5.1-1ubuntu7 version of the driver. If there is anything that I can test (binaries, patches...), I am more than interested to do it.
Comment 39 Luka Renko 2008-12-21 08:35:30 UTC
It looks like that 2.6 RC1 release might have fix for our problem. From release mail:
http://lists.freedesktop.org/archives/xorg/2008-December/041553.html

Zhenyu Wang (24):
      Make IS_GM45 into IS_G4X define
      SDVO: fix wrong order of sdvo version's major/minor
      SDVO: add HDMI audio encrypt change bit for GetInterruptEventSource command
      SDVO: fix sdvo tv format and sdtv resolution request/reply definition
      SDVO: add GetScaledHDTVResolutionSupport command
      SDVO: add command for set monitor power state
      SDVO: fix more command definition errors
      TV: white space cleanup
      TV: fix default contrast and saturation modifier
      TV: save serveral TV_CTL register fields in mode set
      TV: fix timing parameters for PAL, 480p, 1080i
      TV: subcarrier fix for NTSC and PAL
      quirk LVDS on Asus Eee box
      TV: fix contrast and saturation for 915/945G
      Disable XvMC on DRI2 for now
      Fix maxium backlight level restored issue
      Fix TV compiling warning
      Fix DRI2 compiling warning
      Remove Cappuccino SlimPRO SP625F 855GM LVDS quirk
      bug #17395: Quirk CRT for Sony VGC-LT71DB
      Try to always probe SDVOC on 965G/965GM
      Fix directRenderingType check
      Don't warn on ring enabled in GEM
      Bump version 2.5.99.1


Will need to first upgrade to libdrm2 2.4.2 to get this onto Ubuntu Jaunty...
Comment 40 Luka Renko 2008-12-21 10:58:18 UTC
I have found latest packages for Ubuntu Jaunty here:

deb http://ppa.launchpad.net/xorg-edgers/ubuntu jaunty main

However, it does not help. :-(

Will attach log files - hope this might help.
Comment 41 Luka Renko 2008-12-21 10:59:51 UTC
Created attachment 21363 [details]
Xorg.0.log with 2.6.99.1+git20081220.d8e89b26-0ubuntu0tormod
Comment 42 Luka Renko 2008-12-21 11:00:37 UTC
Created attachment 21364 [details]
Xorg.0.log with ModeDebug and xorg.conf with 2.6.99.1+git20081220.d8e89b26-0ubuntu0tormod
Comment 43 Luka Renko 2008-12-21 11:01:20 UTC
Created attachment 21365 [details]
xorg.conf used to override PAL mode and Modeline
Comment 44 mike 2008-12-22 00:29:03 UTC
Another update on the I2c sniffer side.
Bad news.  Long story short, I found that the i2c bus is communicating at 400khz (fast mode), versus the standard 100khz mode.  My little homemade I2C tools just can't keep up with trying to passively sniff the traffic.   
     
     Options for me, if I'll to successfully sniff the I2C traffic, are to either look for a high-end commercial solution for sniffing traffic at those speeds, or redesign my tool from the ground up (not a quick turn around time). 

...darn it. I could have sworn it was at 100khz when I looked at it before.

I haven't given up yet. 

-Mike
Comment 45 Eric Anholt 2008-12-31 11:58:28 UTC
That check_tv_format code I wrote looks totally bogus.  Do things change (for the better?) if you actually smash one of the bits in the format on?
Comment 46 Eric Anholt 2008-12-31 11:58:58 UTC
Given that SDVO TV-out hasn't worked yet, removing this from the blocker list.
Comment 47 kappe 2009-01-13 12:32:58 UTC
dont work! please fix this bug, I am forced to use windows media center :(
Comment 48 Kunszt Arpad 2009-01-18 03:46:50 UTC
I also have an Intel D945GCLF2 for HTPC. The TV out doesn't work with the intel driver under X. But if I use intelfb and set the resolution on the boot (video=intelfb vga=0x315 for 800x600 or video=intelfb vga=0x318) and use fbdev driver the X works. I think because the fbdev driver do not want to change the current video mode. The fb has so many other problems (no XV, low performance, no contrast and other settings etc), so this is just a workaround, but I can watch movies with Freevo.

It can't be done that the driver just use the video mode and didn't want to change it on the initialization? I'm a programmer but I'm not familiar with VGA drivers, so this can be a very stupid idea...

PS: Sorry for my English.
Comment 49 Bob 2009-01-19 14:30:09 UTC
Kunszt, can you provide more information on what you did to get the fbdev driver working?
Comment 50 Kunszt Arpad 2009-01-20 00:15:06 UTC
I compile the intelfb in to the kernel (2.6.27 + gentoo patches). I add this bootparams to kernel (append after the kernel line in boot/menu.lst): video=intelfb vga=0x318. I have only the TV attached, no monitors. This gave me 1024x768 on the TV. In the xorg.conf I use the fbdev driver (ran X -configure and changed intel to fbdev). That's all. But this was too slow, for full screen movies so I have to use 800x600 (vga=0x315 instead of 0x318). I had problems if I compile vesafb in the kernel so I disabled it. Thats all.

Another observations. When I try with intel driver, the screen remains unreadable after I quit from X. Only the reboot helps.

When the kernel boots up it says at the intelfb that the code won't change any video mode because no monitor connected. (This is why you need gave vga= and the video=intelfb:mode=1024x768 don't work.)
Comment 51 Gordon Jin 2009-01-20 01:11:28 UTC
Increasing priority, since many 945GC nettop users are impacted with this.
Comment 52 Wang Zhenyu 2009-02-02 22:25:18 UTC
Created attachment 22509 [details] [review]
SDVO TV debug patch

This is my current debug patch, which fixed some obvious bugs, but I still can't get TV sync right, and my board can't light up TV with video bios too. So please help to test with this patch on your board. Patch is against git master.
Comment 53 mike 2009-02-03 15:30:39 UTC
In another post (that pointed to details of the problem on a web site), I detailed how the frame looked as if it were sending out a 100hz refresh rate, hence the 'rolling' we see.  The more I think about it, I wonder if this was just 50hz PAL mode (interlaced frames).    Just brainstorming here.  

     Haven't done anything recently on the i2c bus because of other priorities. 
Comment 54 Dmitry 2009-02-05 02:13:54 UTC
I have the same problem with D945GCLF2 and Debian Lenny. The 2.6 driver is build from sources. I can help to test it on my system.
Comment 55 Sven Ginka 2009-02-05 09:21:24 UTC
I've got the same board (D945GCLF2) as most people here I guess. When starting the board with only TV connected it starts in b/w and Xorg.0.log says it set the mode NTSC. I'm using XServer 1.5.2 and the intel 2.6 driver. 

I'm not so much in x86 architecture but could try to provide i2c data with a data logger. The point is I have no idea where to put the my probes. Any suggestions?
(btw. I am not willing to solder anything on the board as this might break my warranty)

Comment 56 Sven Ginka 2009-02-05 09:24:45 UTC
after posting the message i went over the mailing list and figured out that there are intel guys on the list. why is there a need to re-engineer the board although there are people here sitting on the informtion and actually hiding it?
Comment 57 kionez 2009-02-06 00:46:41 UTC
Same here, I built a little media center with D945GCLF2 and gentoo, but i can't get TV-OUT working properly.
I can do tests and something like that, if it helps:)

k.
Comment 58 Luka Renko 2009-02-07 07:10:05 UTC
Created attachment 22664 [details]
Xorg.0.log with sdvo-tv-debug.patch

Wang: thanks for trying to address this bug and providing the patch. Today I had the time to try the patch on my system (connected to PAL TV), but without success.
I am running Ubuntu/Jaunty (up-to-date) + latest intel drivers from xorg-edgers PPA:
https://launchpad.net/~xorg-edgers/+archive/ppa

I have therefore applied the patch to this version of the package: 2.6.99.1+git20090127.57a02b50

In the attached tar.gz, you will find the following log files:
before-Xorg.0.log: no patch, no xorg.conf
patch-Xorg.0.log: with patch applied, no xorg.conf
patch+conf-Xorg.0.log: with patch applied, xorg.conf with TV configuration
xorg.conf: configuration used for last test

I have also made a video with my phone of the boot with patch/config applied, so that you have idea what kind of screen we get in X (running KDE 4.2/KDM login screen).
Video should be available here (as soon as processed by YouTube):
http://www.youtube.com/watch?v=JiFwW0xjhgc
Comment 59 Wang Zhenyu 2009-02-11 23:32:36 UTC
Created attachment 22848 [details] [review]
SDVO TV fix patch

Finally I got this patch working on my 945GCLF2 board. S-Video can work stable now in NTSC-M. There's no enhancement has been used now, and only NTSC-M can be used. But this will be added later soon.

Patch is against current git master.
Comment 60 kionez 2009-02-12 03:05:40 UTC
(In reply to comment #59)

> Finally I got this patch working on my 945GCLF2 board. S-Video can work stable
> now in NTSC-M. There's no enhancement has been used now, and only NTSC-M can be
> used. But this will be added later soon.

great! 

I'll wait for "PAL edition" of this patch!

many many thanks!

k.
Comment 61 Michael Fu 2009-02-12 05:12:17 UTC
(In reply to comment #60)
> (In reply to comment #59)
> 
> > Finally I got this patch working on my 945GCLF2 board. S-Video can work stable
> > now in NTSC-M. There's no enhancement has been used now, and only NTSC-M can be
> > used. But this will be added later soon.
> 
> great! 
> 
> I'll wait for "PAL edition" of this patch!
> 
> many many thanks!
> 
> k.
> 

are you able to give this patch a test anyway?
Comment 62 Evgeny Zyubin 2009-02-12 05:52:19 UTC
Nice news. I tried this patch for intel drivers 2.6.1 and 2.6.0. While xorg is running it works. But after quit Xorg the TV picture  is rolling afresh (my console works through framebuffer).
Comment 63 Luka Renko 2009-02-12 12:48:46 UTC
Wang, Michael: I have tried your patch on Ubuntu/Jaunty and have applied it to this package: 2.6.99.1+git20090207.3aa8591a

It works on my PAL TV!!!!

Thank you very much for the fix!
Comment 64 Sven Ginka 2009-02-12 14:24:57 UTC
Created attachment 22873 [details]
Xorg.0.log after patch in NTSC mode

i tried the patch "http://bugs.freedesktop.org/attachment.cgi?id=22848" with only tv-connected. i had to get the drm from git as in "http://bugs.freedesktop.org/show_bug.cgi?id=19126" due to the "error: ‘I915_SETPARAM_NUM_USED_FENCES’ undeclared" . but after all it compiled successfully.

my tv flickered around a lot and i had to switch to another console which was running through but back on xorg it went well it was a nice NTSC screen. good work!

the next challenge might be the pal tv i guess :-)
Comment 65 Sven Ginka 2009-02-12 14:30:54 UTC
(In reply to comment #63)
> Wang, Michael: I have tried your patch on Ubuntu/Jaunty and have applied it to
> this package: 2.6.99.1+git20090207.3aa8591a
> 
> It works on my PAL TV!!!!
> 
> Thank you very much for the fix!
> 

Do you mean you have a b/w picture on your pal screen or a perfect coloured picture?
Comment 66 Luka Renko 2009-02-12 23:31:53 UTC
Sven: yes, I get perfect, color picture on my S-Video PAL TV. I did not do extensive testing (as it was late), but KDE4's KDM screen was perfect.
If you get only B/W, it may be that you are not using S-VHS (S-Video) mode on your TV, but only VHS (this is where I get B/W).
Also note that I use some xorg.conf settings, that may help in this case. You can get my xorg.conf from attachement in comment #58
Comment 67 Luka Renko 2009-02-13 10:03:45 UTC
Created attachment 22907 [details]
Xorg.0.log with fix (working on PAL TV)

Yes, it works with colors and everything. My Xorg.0.log is attached and I have uploaded the video (made with phone, so no quality):
http://www.youtube.com/watch?v=MrihKAabIjE

Now you can compare this with video from comment #58
Comment 68 kionez 2009-02-14 04:09:06 UTC
(In reply to comment #61)
> are you able to give this patch a test anyway?

Yes, i've just patched and compiled from git repository, now TV-OUT seems working, but only in B\W. I can't get colours on my PAL tv.


k.
Comment 69 kionez 2009-02-14 04:23:47 UTC
(In reply to comment #68)
> (In reply to comment #61)
> > are you able to give this patch a test anyway?
> 
> Yes, i've just patched and compiled from git repository, now TV-OUT seems
> working, but only in B\W. I can't get colours on my PAL tv.

and seems "stable" only with 1024x768, for example if i choose:

$ xrandr --output TV-1 --mode 800x600

the screen become unreadable (it seems splitted in four part, that flikers around, always in B\W)

I try to use Luka Renko's xorg.conf, but i can't get colours.

k.
Comment 70 Kunszt Arpad 2009-02-14 05:07:52 UTC
About B/W problem:

First time I get only B/W on TV but after some googleing I found this page http://vganfo.uw.hu/tvout.html. It's Hungarian, sorry. It says if you get only B/W on TV make a connection between the pin 15 and 20 on your SCART connector (there's a picture on that webpage which shows the pin order). It's enough to iron (is this word?) some cable between the pins, but if you want to be extra safe you can put a small (470-630 pF) condesator directed from 15 to 20.

I only put a cable between the pins and it's working fine now.

I hope I'll have time to test the new patch at weekend. I'll write my experiences to here.
Comment 71 Sven Ginka 2009-02-14 07:18:22 UTC
(In reply to comment #67)
> Created an attachment (id=22907) [details]
> Xorg.0.log with fix (working on PAL TV)
> 
> Yes, it works with colors and everything. My Xorg.0.log is attached and I have
> uploaded the video (made with phone, so no quality):
> http://www.youtube.com/watch?v=MrihKAabIjE
> 
> Now you can compare this with video from comment #58
> 

Did you use the patch which sets the pal-mode per default?
strangely in your log it says:

[    2.868498] (II) intel(0): SDVOB: Choosing default TV format of NTSC-M

[    3.027016] (WW) intel(0): Option "TV Format" is not used
[    3.027035] (WW) intel(0): Option "PreferredMode" is not used

so it says it is using ntsc instead of pal

so it might come that your tv is able to display ntsc and thus you have color?

the strange thing is that in your video i can see the kubuntu booting logo in color as well, what means the bios recognized you tv mode correct. in my case the color while booting is b/w as is the xserver. i can't see the difference between your configuration and mine. i also used your xorg.conf.

could you provide the pinout of your adapter cable from D945GCLF2 to S-Video or SCART ?

-thnx 
Comment 72 Dmitry 2009-02-14 07:26:48 UTC
It is working for me in NTSC mode. PAL gives b/w picture.
My TV have auto color detection, so NTSC was detected automatically.
Comment 73 Bob 2009-02-14 11:25:03 UTC
I would like to try this fix, but I need a little help. Can someone point me to where the source code can be found?
Comment 74 Mitja Tavcar 2009-02-15 03:15:38 UTC
I tried to use the patch (SDVO TV fix patch) against the source package from ubuntu jaunty: http://packages.ubuntu.com/source/jaunty/xserver-xorg-video-intel

It works wery well on my old PAL(only) tv. connected with a S-video (Y/c) scart adatpter.
Thanks
Comment 75 Till 2009-02-15 05:33:35 UTC
Created attachment 22965 [details]
ebuild for Gentoo

Works for me, too (my TV also suports NTSC mode).

For all Gentoo users, I created an ebuild.
Just unpack the attached file into your portage overlay dir (usually /usr/local/portage)
then run
emerge -1 xf86-video-intel
enjoy
Comment 76 Mitja Tavcar 2009-02-15 06:53:01 UTC
I tried to use the patch (SDVO TV fix patch) against the source package from ubuntu jaunty: http://packages.ubuntu.com/source/jaunty/xserver-xorg-video-intel

It works wery well on my old PAL(only) tv. connected with a S-video (Y/c) scart adatpter.
Thanks
Comment 77 Luka Renko 2009-02-15 07:13:15 UTC
Sven, it may be that my TV would support NTSC, but I doubt it - no mention anywhere in menus, but I do not have documentation that would describe it.

I use S-Video cable with 4-pin DIN connector on both sides. Same as shown here:
http://en.wikipedia.org/wiki/S-Video
I bought it in regular electronics shop, so I doubt it is any special. I do not have SCART cable to try, sorry.

I have heard that cabling can cause B/W pictures in past, but I do not know the details.
Comment 78 Sven Ginka 2009-02-15 12:28:35 UTC
@luka: i read that most sony-tvs are able to decode both pal and ntsc. also most new tv sets decode both signals.
anyways there seem to be others having an old pal tv and a nice coloured picture, so it might be my configuration that lacks.

@mitja: could you provide your xorg.conf and the /var/log/Xorg.0.log please?

thnx
Comment 79 Wang Zhenyu 2009-02-15 19:14:54 UTC
My patch doesn't expose any option to config TV format now, yeah we should do that like integrated TV encoder. For testing PAL mode, you can change format in i830_sdvo_set_tv_format(), like format->pal_b = 1. 
Comment 80 Wang Zhenyu 2009-02-15 19:51:16 UTC
*** Bug 9992 has been marked as a duplicate of this bug. ***
Comment 81 Wang Zhenyu 2009-02-15 21:17:08 UTC
I've pushed the current fix to git master now. So close this one. I'll add TV format option for SDVO TV later, so it'll be easy to change.

commit f1ca56e17d0ecd4f1299061a6b3272bfd289e123
Author: Zhenyu Wang <zhenyu.z.wang@intel.com>
Date:   Fri Feb 13 10:02:02 2009 +0800

    SDVO: Fix TV support
    
    As SDVO TV uses SDVO_TVClkIn from SDVO encoder for clock reference,
    it needs to generate proper PLL for current input clock. This uses
    fixed PLL table from vbios for this. And possible sdvo mulitiplier
    has to be setup correctly. This makes TV output stable on my 945GCLF2
    board with NTSC-M format.
Comment 82 kionez 2009-02-16 02:58:01 UTC
Hi, thanks for the patches!

I use the lastest xf86-video-intel and libdrm, taken from git repository, I can't get working PAL on my d945gclf2 board, now I have a stable 1280x1024 image but in B\W, i try to modify the format in i830_sdvo_set_tv_format(), but nothing happens.

There's anyone who can post here his xorg.conf (or xrandr commands) for a working PAL environment? :)  thanks!

k.
Comment 83 Sven Ginka 2009-02-16 05:45:21 UTC
GOTCHA!!!

i checked out the latest git src. and could get a colored picture on an old pal tv!!!

when this option is set:

             Option "ModeDebug" "true"

i get information like this:

(II) intel(0): SDVOB: W: 28                         (SDVO_CMD_GET_TV_FORMAT)
(II) intel(0): SDVOB: R: 01 00 00 00 00 00       (Success)

where the "01 00 00 00 00 00" says it is ntsc-m mode see: src/i830_sdvo_regs.h where LSB is first und thus its ntsc-m.

however the discoverd mode needs to be cleared!

so i had to insert into src/i830_sdvo_regs.h 
function i830_sdvo_set_tv_format(...) the following lines

        format->ntsc_m = 0;
        format->pal_60 = 1;

after restarting the xserver i checked the corret tv_set here:
(II) intel(0): SDVOB: W: 29 00 08 00 00 00 00       (SDVO_CMD_SET_TV_FORMAT)
(II) intel(0): SDVOB: R:                         (Success)

where "00 08 00 00 00 00" is the same as above an thus pal-60 mode.

and the tv shows a screen in colours.


however has anybody any idea. vertical lines are very fuzzy they seem not to timed correctly. how would i change this ?

Comment 84 kionez 2009-02-16 07:20:52 UTC
(In reply to comment #83)
[cut]
> i830_sdvo_set_tv_format(...) the following lines
> 
>         format->ntsc_m = 0;
>         format->pal_60 = 1;
> 
[cut]

Hi, could you send me your xorg.conf? I'm trying to play around with configs, but I can't see any "SDVBO_SET_TV_FORMAT" in my Xorg.0.log, only the "GET" ones..

thanks.

k.
Comment 85 Sven Ginka 2009-02-16 07:35:20 UTC
----------------------------------------------------------------
This has to be put in the device section of your xorg.conf

             Option "ModeDebug" "true"

----------------------------------------------------------------

open the file  src/i830_sdvo_regs.h in the drivers directory

search for the function 
i830_sdvo_set_tv_format(...) and add the following lines

        format->ntsc_m = 0;
        format->pal_60 = 1;


----------------------------------------------------------------

restart your computer and check your Xorg.0.log for the following lines

(II) intel(0): SDVOB: W: 29 00 08 00 00 00 00       (SDVO_CMD_SET_TV_FORMAT)
(II) intel(0): SDVOB: R:                         (Success)


if it looks like this you should be able to see a colored picture.

Comment 86 Sven Ginka 2009-02-16 07:37:22 UTC
1. btw. you have to re-compile the driver after that 
2. there is allready a line like " format->ntsc_m = 0;" so you simply replace it
Comment 87 Sven Ginka 2009-02-16 07:38:05 UTC
btw.
1. there is allready a line like " format->ntsc_m = 0;" so you simply replace it
2. you have to re-compile the driver after that 
Comment 88 kionez 2009-02-16 08:27:27 UTC
(In reply to comment #83)

> however has anybody any idea. vertical lines are very fuzzy they seem not to
> timed correctly. how would i change this ?

Thanks!

I have to reboot to get new driver work properly (I don't know why...).

I confirm that there's some fuzzyness around vertical lines, even in "pal_b" mode.

I noticed that colours aren't so "bright", and sometimes it flickers to B\W for a second, then it returns to colour mode.. (I think that is not a problem on my TV, but I can't test it on another TV, sorry)

k.
Comment 89 Sven Ginka 2009-02-16 23:40:00 UTC
> I have to reboot to get new driver work properly (I don't know why...).

i basically had to reload the video driver, but it sometimes did work only after a reboot for me.

Comment 90 Sven Ginka 2009-02-18 08:08:20 UTC
> however has anybody any idea. vertical lines are very fuzzy they seem not to
> timed correctly. how would i change this ?


i figured out that it is tv-releated. it does only support composite. however due to a bad cable which obviously had a too large capacity in it. the chrominance signal could be seen on the luminance signal. so i guess this is what my tv displayed. simply un-soldering the chrominance signal showed that circumstances perfect. so i had only the luminance signal connected to the tv but it was a colored picture with ugly synced color information. :-)

replacing the cable/tv solved the issue.

the only thing which is missing is that i always have to start the xserver twice when booting. the picture is not in sync first. but then i go to the console to restart the server and i get the perfect picture. 

any ideas??
Comment 91 duszcz 2009-02-19 14:14:12 UTC
It works but partially. 
Video out of S-Video seems to be progressive where standard TV expects it to be interlaced. 
As an effect, during video playback, upper part of the screen is not in sync with lower part (in scenes where something moves horizontally).  
See how it looks here: http://neuron2.net/LVG/interlacing.html (animation "Progressive video on an interlaced display").

Unfortunately, I also found comment in README in xf86-intel-2.6.99.1:
- "Interlace modes cannot be supported".
Any ideas how to solve it?
Comment 92 Gordon Jin 2009-02-20 00:27:47 UTC
(In reply to comment #91)
> It works but partially. 

"works partially" is different with the original report of this bug "not working". So please don't reopen.
And since many people have confirmed the patch takes effect, I believe the original problem has been fixed, and don't want this bug (already with 90+ comments) to be tracked any more.
If anyone has further problem, please file a separate bug. Thanks.

> Unfortunately, I also found comment in README in xf86-intel-2.6.99.1:
> - "Interlace modes cannot be supported".
> Any ideas how to solve it?

It's tracked at bug#11220. 
Comment 93 Matt 2009-02-22 06:52:36 UTC
Confirmed, it works fine when applied to the older xf86-video-intel-2.4.2 driver and run on a D945GCLF2 as well.

Thanks for the fix!
Comment 94 Darren Enns 2009-02-23 06:22:28 UTC
Please forgive my obvious ignorance of the proper etiquette of participation in this discussion.  I have been following this conversation since conception -- after finding that the S-video out of my home-built D945GCLF2 motherboard-based PC did not work in Fedora 10.  My question is this: should I simply wait for an update to this driver to show up in the F10 repositories, or should I seek out the source and patch it myself, or be directed to already-patched source that I should compile?  Thanks!
Comment 95 Rémi Cardona 2009-03-03 05:48:33 UTC
Hi Zhenyu,

Could you nominate this patch for inclusion to the 2.6 branch?

Thanks
Comment 96 Wang Zhenyu 2009-03-04 17:38:09 UTC
2.6 is feature done, so this should be in 2.7 (intel Q1 release). You can port it to 2.6 if you wish, but does need to include later fix like 62ca1c479825ffa0e9cf444b4e25080150faa45b.

Comment 97 kionez 2009-03-04 23:27:15 UTC
(In reply to comment #96)
> 2.6 is feature done, so this should be in 2.7 (intel Q1 release). You can port
> it to 2.6 if you wish, but does need to include later fix like
> 62ca1c479825ffa0e9cf444b4e25080150faa45b.
> 

I'm using the lastest git version (14bb61e0c2e28725a2f6167d3263649bc845be18) with xorg server 1.6, and everything comes from x11 gentoo overlay (libdrm-git, randrproto-git and so on...) but I still can't change to PAL format or brightness, neither with TV_FORMAT or BRIGHTNESS in xorg.conf, nor with xrandr.
I have to create a patch that sets formats->pal = 1 ?

thanks in advance :)

k.
Comment 98 Sven Ginka 2009-03-05 08:47:09 UTC
as far as i know you have to patch it ;-)

> 
> I'm using the lastest git version (14bb61e0c2e28725a2f6167d3263649bc845be18)
> with xorg server 1.6, and everything comes from x11 gentoo overlay (libdrm-git,
> randrproto-git and so on...) but I still can't change to PAL format or
> brightness, neither with TV_FORMAT or BRIGHTNESS in xorg.conf, nor with xrandr.
> I have to create a patch that sets formats->pal = 1 ?
> 
> thanks in advance :)
> 
> k.
> 

Comment 99 Peio Azkarate 2009-03-10 00:52:23 UTC
(In reply to comment #94)
> Please forgive my obvious ignorance of the proper etiquette of participation in
> this discussion.  I have been following this conversation since conception --
> after finding that the S-video out of my home-built D945GCLF2 motherboard-based
> PC did not work in Fedora 10.  My question is this: should I simply wait for an
> update to this driver to show up in the F10 repositories, or should I seek out
> the source and patch it myself, or be directed to already-patched source that I
> should compile?  Thanks!
> 
Sorry for my ignorance about de mechanics of git an so. Could someone say more explicitly how to include the fix "62ca1c479825ffa0e9cf444b4e25080150faa45b" and "SDVO TV fix patch" to the 2.6 to obtain a bug free driver?.
I see on the latest commit messages of the intel and drm drivers from Wang that they are related to TV and SDVO, are also related to this bug?.

Comment 100 Benoit LORAND 2009-04-13 10:11:57 UTC
Hi,

I'm using 2.6.99.903 video-intel driver who should works on D945GCLF2. But i'm always in black and white. I have tried to use composite enable into my xorg.conf but no change.

I'm not very familiar to xorg syntax so i thing my xorg.conf does corresponde to prerequiste to have color on my TV (who should work as PAL or as NTSC). I have color in S-VIDEO but video isn't very good.

Is there someone who should send working xorg.conf ?
Comment 101 Peio Azkarate 2009-04-15 02:27:07 UTC
I solved it under ubuntu 8.10:
http://ubuntuforums.org/showthread.php?t=993136&page=2
Comment 102 Peio Azkarate 2009-04-16 07:25:01 UTC
I solved it under ubuntu 8.10:
http://ubuntuforums.org/showthread.php?t=993136&page=2
Comment 103 ullix 2009-04-16 10:44:18 UTC
(In reply to comment #102)

Following Peio's instructions - thanks - with Ubuntu Jaunty beta I was able (needed to additionally install xutils.dev) to have the s-video function  on an attached NTSC TV set in color, stable, and in decent quality, but:

xrandr --verbose does not show any TV typical output. In fact the output has not changed at all from before Peio's modifications. And I still can't change the TV Format, as this command is not recognized; it results in a 'BadName' error: 
xrandr --output TV-1 --set TV_Format PAL 


Apparently Intel has also done some changes in the bios (but no info on this given in the release notes). All of the above was done with bios version 1.22. I then upgraded the bio to 1.71, out since a few days. After that the TV picture scrolls through upon start, but can be set to stable and same decent quality as before with:
xrandr --output TV-1 --mode 1024x768

using mode 800x600 or 640x480 results in multifold divided picture, scrolling through. 

I also connected a PAL TV set, but I believe the set adapts to NTSC signals; the picture is the same as far as I can say.

I hope this is not the final result?
Comment 104 Till 2009-04-17 02:11:16 UTC
(In reply to comment #103)
> I hope this is not the final result?

This Bug has been marked RESOLVED FIXED since the bug was about TV output not working at all, which is fixed by the patch.

Any comments you post here will not have any effect. instead, you should file new bugs for any problems you have. Before you do so, one quick question: Which driver version did you try? you should only file bugs if you have problems with the newest version 2.7. According to Zhenyu, this version contains more SDVO TV out bug fixes than the one posted here.
Also, before you file a new bug, check if someone else has filed it already to avoid duplicates (see the guidelines for filing a new bug).

> xrandr --verbose does not show any TV typical output. In fact the output has
> not changed at all from before Peio's modifications. And I still can't change
> the TV Format, as this command is not recognized; it results in a 'BadName'
> error: 
> xrandr --output TV-1 --set TV_Format PAL

AFAIK this is a known limitation (TV Format switching is not supported yet).
However, filing a bug might help to get it fixed sooner.

> Apparently Intel has also done some changes in the bios (but no info on this
> given in the release notes). All of the above was done with bios version 1.22.
> I then upgraded the bio to 1.71, out since a few days. After that the TV
> picture scrolls through upon start, but can be set to stable and same decent
> quality as before with:
> xrandr --output TV-1 --mode 1024x768

this is a bug, file it if it does not exist yet.

 
> using mode 800x600 or 640x480 results in multifold divided picture, scrolling
> through. 
 
this is also a bug you could file.
Comment 105 ullix 2009-04-17 10:21:23 UTC
(In reply to comment #104)

> Before you do so, one quick question: Which
> driver version did you try? you should only file bugs if you have problems with
> the newest version 2.7. According to Zhenyu, this version contains more SDVO TV
> out bug fixes than the one posted here.

This was the latest one I found: Intel 2.6.99.901 release (2.7 rc1), with this file name: 	xf86-video-intel-4e334ef33c38e2e930958a4b68d79f1860bb9efa.zip