Problem with persistent scaling/shifting in RADEONDisplayVideo()
xorg-driver-ati at toh.cx
Mon Jul 28 08:56:06 PDT 2008
On Mon, Jul 28, 2008 at 03:43:45PM +0200, Roland Scheidegger wrote:
> Not sure here what's really the problem, but it's possible the scaler
sure, it's difficult to describe the prob if you've never seen it before.
> gets slightly misprogrammed in interlace mode - programming the scaler
> correctly seems to be a bit tricky. Maybe you'd need to account if
> you're displaying odd or even lines currently or something like that (if
> you look at the displayvideo part, this one uses some of these bits).
right, I already fiddled for hours about these things.
> Also, to disable scaling, maybe the RADEON_SCALER_VERT_PICK_NEAREST
> would do the trick (but I don't think it really helps with your
thank you for this clue. I'll give it a try.
> That said I don't fully understand how the interlaced frames get there
> really, if your source is interlaced wouldn't the source images only
> have half height and you'd scale them up by a factor of 2 (e.g. you'd
> pretend to do bobbing, but since your scanout is interlaced you'd
> actually get back the normal interlaced picture).
no, the source image contains the even and odd field and thus is full
sized. It's the task of the CRT controller to read the right fields at
the right time. If both fields have been fed through the VGA port double
buffers (if overlay) are switched. Sounds complicated but works very
good even with 800Mhz processors.
Except you additionally compile a new kernel in the background on the
> (Though, IMHO interlace should have been buried along with analog
> transmission - this clever 1930-ish hack just doesn't make much sense
> any longer and is just cause for pain...)
interlace output still is important for driving conventional TV
hardware with SCART RGB input. That's what all my current hacking is
meant for. I try to develop a solution that recycles very cheap Radeon
hardware to high quality RGB/PAL output devices.
Until now you get high quality RGB/PAL output only by very expensive
intelligent PCI boards with proprietary firmware.
I think I can cope with the situation. Maybe the suggested fix for
textured XV will be realized some day. I currently can't dig into this
myself. Thank you all for your answers.
More information about the xorg-driver-ati