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.
Created attachment 19211 [details] [review] patch where I tried to enable PAL as default
Created attachment 19212 [details] log file when the bug appears
Created attachment 19213 [details] xorg.conf where the bug occurs
Created attachment 19214 [details] Xorg log with i810 driver where tv out seems to be detected, but driver does not work
Created attachment 19215 [details] Xorg.conf for i810 driver where tv out seems to be detected, but driver does not work
Created attachment 19216 [details] xorg log for patched version using patch #19211 (xorg conf is identical to attachment#19213 [details])
for me this issue is quite severe, since I want to use the tv as the only monitor
Zhenyu, D945GCLF2 is exactly our "little falls" board from CPG. Is that SDVO TV-out or integrated TV-out?
The TV is connected to the integrated S-Video connector that is on board, not to an extra card.
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...
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.
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.
Zhenyu, I think little falls using SDVO TV-out. If so, this is dup with bug#9992.
*** Bug 18210 has been marked as a duplicate of this bug. ***
Has anyone found a workaround, such as using fbdev or anything?
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
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.
(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...
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.
(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.
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
(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 ;-)
Wang: i see that you posted 6 patches to the intel-gfx mailing list, are they intended to fix this bug?
No, those patches are for integrated TV encoder, not SDVO TV on littlefall board. I'm looking into it on a littlefall board here.
*** Bug 18541 has been marked as a duplicate of this bug. ***
(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).
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); } }
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.
(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.
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
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!
*** Bug 18874 has been marked as a duplicate of this bug. ***
(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
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.
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
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.
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.
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.
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...
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.
Created attachment 21363 [details] Xorg.0.log with 2.6.99.1+git20081220.d8e89b26-0ubuntu0tormod
Created attachment 21364 [details] Xorg.0.log with ModeDebug and xorg.conf with 2.6.99.1+git20081220.d8e89b26-0ubuntu0tormod
Created attachment 21365 [details] xorg.conf used to override PAL mode and Modeline
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
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?
Given that SDVO TV-out hasn't worked yet, removing this from the blocker list.
dont work! please fix this bug, I am forced to use windows media center :(
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.
Kunszt, can you provide more information on what you did to get the fbdev driver working?
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.)
Increasing priority, since many 945GC nettop users are impacted with this.
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.
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.
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.
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)
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?
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.
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
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.
(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.
(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?
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).
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!
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 :-)
(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?
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
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
(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.
(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.
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.
(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
It is working for me in NTSC mode. PAL gives b/w picture. My TV have auto color detection, so NTSC was detected automatically.
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?
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
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
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.
@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
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.
*** Bug 9992 has been marked as a duplicate of this bug. ***
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.
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.
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 ?
(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.
---------------------------------------------------------------- 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.
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
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
(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.
> 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.
> 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??
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?
(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.
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!
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!
Hi Zhenyu, Could you nominate this patch for inclusion to the 2.6 branch? Thanks
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.
(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.
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. >
(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?.
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 ?
I solved it under ubuntu 8.10: http://ubuntuforums.org/showthread.php?t=993136&page=2
(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?
(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.
(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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.