[Unichrome-bugs] [ unichrome-Bugs-1105807 ] Some Xv resolutions screwed up.

[SourceForge.net <no...@so...>]

Bugs item #1105807, was opened at 2005-01-20 01:03
Message generated for change (Comment added) made by jhnw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=630967&aid=1105807&group_id=102048

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: X-driver, Xv
Status: Open
Resolution: None
Priority: 6
Submitted By: Thomas Hellström (totte67)
Assigned to: Ivor Hewitt (ihewitt)
Summary: Some Xv resolutions screwed up.

Initial Comment:
Some Xv resolution / scaling combinations leave
artifacts at the left and right hand side borders.

For example 900x600 scaled to 1024x768. 

Same both for YUY2 and YV12. As far as I can see, this
was present already in r23.

Preferrably, use "xvtestcard" to test.

/Thomas


----------------------------------------------------------------------

Comment By: John Wier (jhnw)
Date: 2005-06-13 09:56

Message:
Logged In: YES 
user_id=1293351

I was having a similar problem.

In the problem case (1280x720p scaled up to 1400x1050) it
looks like
 every other line of the left 25% of the display is getting
swapped with
 the corresponding line from the right 25% of the display. 

It seems to me that you want to turn on the
gdwUseExtendedFIFO value for the VT3259 chip
id, as well as the CLE3122 chip id, if the display width is more
 than 1024.
 
The change is localized to unichrome/via_swov.c, in the function
 VIAVidUpdateOverlay:
 
      if ((pVia->ChipId == PCI_CHIP_CLE3122) &&
(pScrn->currentMode->HDisplay >
 1024)) {
 becomes
   if ((pVia->ChipId == PCI_CHIP_CLE3122 || pVia->ChipId ==
PCI_CHIP_VT3259)
   && (pScrn->currentMode->HDisplay >= 1024)) {



----------------------------------------------------------------------

Comment By: Thomas Hellström (totte67)
Date: 2005-02-10 04:39

Message:
Logged In: YES 
user_id=975532

I haven't had time to try VIA's binaries yet. Have you
tested those?
If they exhibit the same problem, it is a good idea to
disable the interpolation, but we might be able to do it in
a smarter manner.  This problem does not be present when
scaling down, only when scaling up / not scaling at all
under certain conditions. 

/Thomas


----------------------------------------------------------------------

Comment By: Andreas Robinson (sleeperse)
Date: 2005-02-08 12:24

Message:
Logged In: YES 
user_id=405312

I get coloured streaks on every other line on CLE266A. It's
not random garbage but rather part of the video displayed in
the wrong place.

It is not possible to adjust the interpolation, besides
turning it off.

Assuming VIA designed and tested the CLE266 with standard TV
resolutions, we could disable the interpolation when (width
> 800) || (height > 600)?


----------------------------------------------------------------------

Comment By: Thomas Hellström (totte67)
Date: 2005-01-23 04:19

Message:
Logged In: YES 
user_id=975532

Hmm, I'm not sure it's a bandwidth problem, because they
appear like small transient black / white strikes across the
screen?

Also there is an overlay reject function implemented for
KM400 and CLE266 in via_video.c, where I have looked at VIAs
modetable and implemented a conservative formula for what
modes should be rejected. It should be more conservative
than VIA's driver.

Looks more like a HW bug to me? Any way to adjust the Y
interpolation? Maybe we should test VIA's drivers and see
how they behave. Also I've noticed that it seems to never
occur when width is scaled down. Only when it is scaled up.

/Thomas




----------------------------------------------------------------------

Comment By: Andreas Robinson (sleeperse)
Date: 2005-01-21 08:55

Message:
Logged In: YES 
user_id=405312

Ok... I think the hardware runs out of bandwidth. If
Y-interpolation is disabled in the overlay, the problem
disappears.

To help solve this problem, it might be necessary to look at
VIAs driver.

There is a group of functions in Share/Vidcle/overlay.c in
CLEXF0047, called RejectOverlay_<chip-id>(). It calculates
the bandwidth requirements from memory type, number of
screens, resolution, refresh rate, overlay size etc and then
decides whether the overlay can be used.

So ... now what? Can we use it?

----------------------------------------------------------------------

Comment By: Andreas Robinson (sleeperse)
Date: 2005-01-21 07:37

Message:
Logged In: YES 
user_id=405312

> Andreas, do you have time to take a look at this?

Sure, no problem. Hmm, here is something weird: 900x600
looks bad, 900x900 looks ok. 

----------------------------------------------------------------------

Comment By: Thomas Hellström (totte67)
Date: 2005-01-21 01:10

Message:
Logged In: YES 
user_id=975532

Andreas, do you have time to take a look at this?
Otherwise, just reassign the bug!

/Thomas


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=630967&aid=1105807&group_id=102048