Steven Yap wrote:
Well, I suspect it is not. What's happening is that the Xv extension is being used, which provides hardware-based scaling and YUV to RGB colour space conversion. I have an ATI Radeon 7500 and I see the same problem when the Xv extension is being used.I think this may be a bug in the Xv part of the radeon driver. Does anyone on the list using Nvidia or Matrox and the Xv extension have thesame problem?
I have also had this problem when i first purchased my Radeon 64MB VIVO. This behaviour has not improved through diffrernt upgrades (Xfree 4.01, 4.1, 4.2). Several people have responded that this was indeed a bug with XV and these series of Radeon cards.
I never experienced this bug with a Rage 128 Pro running on a IBM Thinkpad a22. Xv and video scaling worked perfectly.
I'm currently considering replacing the Radeon with a Rage 128 Ultra card. They are availablw with 32mb of ram for about 25 USD. I have a second box to play windows games, so 3d isn't that important.
Another solution pointed out to me on the list a while back, was the GATOS enhanced ati modules, which supposedly fix this issue. It entails (this from the gatos webstite, http://www.gatos.sourceforge.net):
"Installing ati.2 binaries
* Download tarfile from our download area
* Backup your /usr/X11R6/ directory (or wherever you installed
XFree 4.1.0)
* Make sure that /usr/X11R6 points to the directory where you
installed XFree 4.2.0. It could be a symlink, it could be a hardlink.
* Change directory to /usr and unpack the archive:
tar zxvf ATI-4.2.0-X.i386.tar.gz
This will install some additional modules and replace some
binaries that are part of standard XFree86 4.1.0 installation.
Please make sure to install _ALL_ of ati.2 binaries (if you compile _apply_, _make_ and _install_ patches (see ati_xv/README)). If you just install modules it will _not_ work. Installation process for 4.1.0 is identical (s/4.2.0/4.1.0).
Note: many people have reported problems installing over RPM or DPKG based installations. These problems stem from the fact that package maintainers get creative and put XFree86 in non-standard places. Our "official" recommended way is to either compile XFree86 4.2.0 tree yourself (this way you can develop too) or to use plain XFree86 binaries - the ones in .tgz format."
The disclaimer at the end is why I chose against messing with my X11R6 tree. I hope this helps. Nick