Created attachment 21550 [details] TV screen showing top half of desktop, illustrated by xclock -geometry 200x200 I'm trying to display X on a regular old-fashioned PAL television, using the VGA port of a Gigabyte GA-MA78GM-S2H with integrated HD3200 GPU (780g). I couldn't get composite sync on the HSYNC pin, so I constructed a small electronic circuit to combine horizontal and vertical sync into composite sync. The motherboard doesn't have tv-out so I'm stuck (fortunately?) on the VGA port. I can get synchronization on the TV, but only the top of the desktop is displayed....See the screenshot, displaying 'xclock -geometry 200x200'; You can clearly see overscan, which is okay. But the last visible line seems to be at 288px (desktop is x2:576px). I can also see the some parts of the cursor, probably positioned exactly in the middle. There is a difference if I turn off interlace, but it only increases flicker. Some more details: * Running debian unstable, with package "xorg 7.3+18" * compiled radeon driver 6.9.0.91 * no special xorg configuration or nothing strange in the logfile, will attach later. * The desktop is probably still running at 768x576, but the lower half is never displayed on the television. * This could be related to bug 12626, running the 6.9.0 driver gave me the black horizontal band in the middle. Questions: ? Did i misconfigure X for running PAL on the VGA port, or is this a bug? ? could it be the cable? I assumed that if I have sync, the cable must be fine. ? how to debug this is in the code? I have some programming experience, so any help there is appreciated as well. Thanks (Alex, and others)
Created attachment 21551 [details] xorg.conf
Created attachment 21552 [details] Xorg.0.log
I've seen the same problem with a X1250. I'd be very happy to provide further information or conduct further tests. I was also wondering if it is worth adding a row to the radeon feature list for the sake of interlaced modes.
Created attachment 22046 [details] [review] Patch to restore D1MODE_DATA_FORMAT after scaler setup. I found out that the problem has to do with the undocument register AVIVO_D1MODE_DATA_FORMAT. This register is set to AVIVO_D1MODE_INTERLEAVE_EN (0x1) in src/atombios_crtc.c in function atombios_crtc_mode_set when an interlaced mode is used. Later in atombios_output_scaler_setup this register is reset to 0 when RHDAtomBiosFunc is called. If the register is set to 0x1 again after this function the interlaced mode works fine. The patch saves the register before calling the atombios function and sets it to the original value after the call. I would guess that this is not the real solution, because there must be a reason that the value is changed. This patch works for me on a X1250 IGP.
That patch works for me too on my K9AGM2 mobo with integrated X1250. This is great. Gives me another option for connectint a MythTV box to a TV using the "VGA to Scart" trick, where previously the only option was to buy an old Radeon 9200, an old AGP mobo to plug it into and an old CPU. XV blitting also works, and gives me an excellent picture. I guess there's no chance this will get committed, being a patch around the real problem, but it seems a great step forward. Is it likely that most integated, modern ATI chips will work in interlaced modes with this patch?
(In reply to comment #5) > I guess there's no chance this will get committed, being a patch around the > real problem, but it seems a great step forward. Is it likely that most > integated, modern ATI chips will work in interlaced modes with this patch? > This should already be fixed in git master.
(In reply to comment #6) > This should already be fixed in git master. > Yes I can confirm that it is fixed in git master now. In which commit was the fix?
(In reply to comment #7) > Yes I can confirm that it is fixed in git master now. In which commit was the > fix? > 7cc7ba8bf9ce2f0eebfd9b48aa648c416c333ff4
Yep, trunk works for me too. Anyone know which other chips can do TV modes from VGA?
(In reply to comment #9) > Yep, trunk works for me too. > > Anyone know which other chips can do TV modes from VGA? > All ati chips should be able to with the right modeline.
(In reply to comment #10) > All ati chips should be able to with the right modeline. Amazing. Should they all be able to generate composite sync (if "composite" is added to the mode line)? I'm using the more complicated VGA to Scart circuit, which combines syncs, because I built it not knowing if I'd used ATI or nVidea. I'd like to simplify though.
Generation of composite sync doesn't seem to work, at least not with the X1250. Should I open another bug for that, or is composite sync not expected/intended to work?
(In reply to comment #12) > Generation of composite sync doesn't seem to work, at least not with the X1250. > Should I open another bug for that, or is composite sync not expected/intended > to work? > I'm not sure if that's supported by the hw or not anymore. I don't think the driver handles it.
Thank you, thank you, thank you. I've verified the fix using the patch from Mike Pieper (2009-01-16 23:10:37) and from the mainstream as reported (and fixed) by Alex. I used the a download from the latest commit (04859362ce64ed4ae48305a83c92059899c1db4b). For the record, I didn't have the X1250 gpu, but the HD3200 which is onboard of the 780G motherboards. Besides fixing the interlace bug, this also fixes a different bug which I didn't report. Somehow after killing the X-server and restarting with the cable still connected, the X-server didn't pickup the correct modeline and started in a 800x600 resolution which didn't sync on my TV. Now it does, so I have to make a big compliment to the guys doing the hard work here. It's too bad the there so much flicker on a 50Hz television, otherwise it would really be a good way to connect such a set to your computer. Overscan in all directions can be handled quite well by adjusting the modelines. As for the followup concerning the composite sync output. I couldn't get composite sync to work using the +composite flags in xorg.conf. I measured the signal using an oscilloscope and there wasn't any significant difference. Although on a dutch site (gathering.tweakers.net), I've read that some people were able to get this working in PowerStrip so I guess the hardware is still capable of generating composite sync on the hsync pin. @Paul Gardiner: Can you open another bug for that? I've set this bug to verified.
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.