Intel PAL TV out on Aopen i945GMm-HL - slight chroma flicker on svideo output

[Robert Lowery]

>
> On Tue, 2007-12-04 at 23:08 +0000, Justin Hornsby wrote:
>> Hi folks.
>>
>> I'm experiencing a slight problem with svideo out using the 'intel'
>> driver version 2.1.
>>
>> I eventually managed to find out how to use xrandr to set the TV
>> standard to PAL and how to get the picture nicely overscanned with the
>> margin setting options of xrandr but...
>>
>> I've noticed that the svideo connection on my Aopen motherboard is
>> flickering slightly near the top of the screen.  Turning the colour
>> control on the TV down makes the problem go away which seems to indicate
>> an issue with the chroma signal on the svideo port.  I quickly hacked a
>> spare svideo cable up a little and found (by connecting the Y output to
>> a composite input on the TV) that the chroma signal is also present on
>> the Y pin.  It's my understanding that for svideo, only luminance should
>> be present.  Depending on how the TV treats svideo internally, having
>> chrominance on Y & C could cause problems.
>
> If you hook only the Y pin up, the encoder will be configured for
> composite video; it automatically detects the kind of cable purely based
> on which wires are connected. It shouldn't change after you've turned it
> on though, so hooking it up to svideo, starting the output, then
> switching should keep it in svideo mode.
>
>> I don't know anything about the TV encoder used on this board (yet) but
>> I have access to video test gear at work where I plan to have a real
>> good look at the signals coming out of the svideo port.  We also have
>> good monitors which I know for sure don't do any quick & dirty tricks
>> with Y&C signals so if the issue is one of 'beating' of the 'Y chroma'
>> and C signals it should look nice & clean on there.
>>
>> Are there any quick things I can try?  It seems (from a quick look in
>> the driver code) that xrandr supports only TV_FORMAT & margin
>> adjustments for the TV encoder.  All the timing values look sane to me
>> but as I've already said I plan to examine the signals very closely at
>> work.
>
> Oh, cool! I looked at getting some TV test equipment to figure out
> whether I was generating legal signals, but couldn't really justify the
> price.
>
> There are a million values you can frob to play with the video signals,
> but most of them are not exposed through the protocol. Check out
> i830_tv.c and i810_reg.h which documents the relevant registers
> reasonably completely. In particular, using one of the test patterns may
> help isolate the particular issues you're seeing with the image.
>
> Let me know if you have specific signal problems and I'll read through
> the documentation to see what I can figure out.

Hi Keith,

I've been trying to track down some geometry issues I am seeing in PAL and
576p modes of the intel driver.
https://bugs.freedesktop.org/show_bug.cgi?id=13165

In essence, I believe the raster being generated is a bit too small,
resulting in black borders etc.  Do you know what some of the magic
numbers in i830_tv.c are for (eg 32, 33, 64 and 96 below)

1435         mode_ptr->HDisplay = hactive_s;
1436         mode_ptr->HSyncStart = hactive_s + 1;
1437         mode_ptr->HSyncEnd = hactive_s + 64;
1438         if ( mode_ptr->HSyncEnd <= mode_ptr->HSyncStart)
1439          mode_ptr->HSyncEnd = mode_ptr->HSyncStart + 1;
1440         mode_ptr->HTotal = hactive_s + 96;
1441
1442         mode_ptr->VDisplay = vactive_s;
1443         mode_ptr->VSyncStart = vactive_s + 1;
1444         mode_ptr->VSyncEnd = vactive_s + 32;
1445         if ( mode_ptr->VSyncEnd <= mode_ptr->VSyncStart)
1446             mode_ptr->VSyncEnd = mode_ptr->VSyncStart  + 1;
1447         mode_ptr->VTotal = vactive_s + 33;

> --
> keith.packard at intel.com
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg