Bug 6151 - xv doesn't work with nv driver (at 1680x1050x24)
Summary: xv doesn't work with nv driver (at 1680x1050x24)
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nVidia (open) (show other bugs)
Version: git
Hardware: All NetBSD
: high major
Assignee: Xorg Project Team
QA Contact:
Keywords: patch
Depends on:
Reported: 2006-03-06 00:57 UTC by Julio Merino
Modified: 2006-12-16 09:47 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

Possible workaround. (1.16 KB, patch)
2006-03-06 00:58 UTC, Julio Merino
no flags Details | Splinter Review
Proposed fix. (1.16 KB, patch)
2006-03-06 02:52 UTC, Julio Merino
no flags Details | Splinter Review
Relax xf86AllocateOffscreenLinear() granularity restriction (987 bytes, patch)
2006-03-06 16:07 UTC, Benjamin Herrenschmidt
no flags Details | Splinter Review
Relax xf86AllocateOffscreenLinear() granularity restriction #2 (999 bytes, patch)
2006-03-06 16:20 UTC, Benjamin Herrenschmidt
no flags Details | Splinter Review

Description Julio Merino 2006-03-06 00:57:31 UTC
Past Christmas I bought a BenQ FP202W 20"-Wide flat panel and I configured my X 
server to use a resolution of 1680x1050 at 24bpp (jumped from 1024x768).  This 
is with a GeForce 6600GT (256MB, AGP 8x) video card using the free nv driver 
under NetBSD 3.99.16.  Since then I haven't been able to use xv to play any 
video, which is very frustrating as I couldn't take advantage of the new 
For example, mplayer spits out the following when run with '-vo xv': 
    BadAlloc (insufficient resources for operation) 
Similarly, xawtv refuses to work in 'overlay' mode, thus becoming unusable. 
Prior to opening this bug, I found that bug #474 might be related.  I'm not so 
sure, though; that one seems to talk about getting out of xv memory when there 
are many open applications or when using DRI.  In my case I cannot play a 
single video at all, even if I start X with plain twm and run mplayer 
afterward.  Not to mention that there is no DRI support in NetBSD.  This is why 
I am opening a new bug. 
I've been inspecting nv's code... but since I am a novice with respect to X's 
code, I haven't found an answer yet.  However, there is something that looks 
suspicious: nv_driver.c has the following in it: 
    offscreenHeight = pNv->ScratchBufferStart / 
                     (pScrn->displayWidth * pScrn->bitsPerPixel >> 3); 
    if(offscreenHeight > 32767) 
        offscreenHeight = 32767; 
    AvailFBArea.y2 = offscreenHeight; 
    xf86InitFBManager(pScreen, &AvailFBArea); 
In my case, offscreenHeight overflows 32767 (it's somewhere around 38k or 39k), 
so it is rounded down (because it doesn't fit in AvailFBArea.y2, which is a 
short).  I think it is suspicious because it looks like as if the framebuffer 
couldn't get the real required space.  If this is the case, it is scary because 
changing the variable's size (Box's members) to something bigger affects many, 
many parts of the server. (Don't focus too much on this "deduction" because it 
can be perfectly wrong and unrelated.) 
Anyway, I have found a little workaround for my problem which lets me use xv at 
full resolution.  The patch is attached.  What it does is call 
xf86AllocateOffscreenLinear with a granularity (?) of 24 instead of 32.  I've 
checked other drivers (e.g., ATI) and most of them use values smaller than 32.  
I don't know the reason but, if they do, maybe nv could be changed to a smaller 
value too until a correct solution is found. 
Another reason for opening this bug is to let other people who may have the 
same problem to find this information and make use of the workaround.  I will 
keep investigating and will post any new information here, if any.
Comment 1 Julio Merino 2006-03-06 00:58:00 UTC
Created attachment 4830 [details] [review]
Possible workaround.
Comment 2 Julio Merino 2006-03-06 02:50:32 UTC
Upon further inspection, maybe my "workaround" is indeed the correct solution.  
That is, there seems to be no memory allocation problem. 
I see the following in xf86fbman.c:localAllocateOffscreenLinear(): 
   if(gran && ((gran > pitch) || (pitch % gran))) { 
        /* we can't match the specified alignment with XY allocations */ 
        return NULL; 
This is the test that is failing in my case, returning NULL and making mplayer 
think that there is not enough memory for xv.  Why does this fail, though?  
Well, 'gran' is set to 32 by the caller (nv_video.c:NVAllocateOverlayMemory()) 
and 'pitch' is set to 1680 (the horizontal screen resolution, though the 
variable name is confusing...). 
If we do some numbers, 'pitch % gran = 1680 % 32 = 16', which makes the above 
conditional evaluate to true and thus the allocation fails. 
So... given that the '32' is a granularity, I deduce that the less, the better.  
Therefore I have updated my patch to call this function with a granularity of 
16 to match the radeon driver.  I think it may be correct now. 
Comment 3 Julio Merino 2006-03-06 02:52:26 UTC
Created attachment 4833 [details] [review]
Proposed fix.
Comment 4 Benjamin Herrenschmidt 2006-03-06 15:51:39 UTC
I'm not sure... the reason is that it seems that the "nv" driver is indeed
always aligning the pitch of the overlay surfaces to 64, thus 32 might be the
"correct" granularity for such surfaces... Changing it might break on some
hardware revisions...

The problem I see here is that xf86AllocateOffscreenLinear() is trying to match
every allocation with the pitch of the front buffer. That is, basically, boils
down to XAA assuming every offscreen surface has the same bit depth... This
assumption is broken here.

It's not totally clear to me what the right fix is. I think
xf86AllocateOffscreenLinear() is over-zealous here and shouldn't enforce that
pitch/alignement but I would rather have other's validate my reasoning here.
Comment 5 Benjamin Herrenschmidt 2006-03-06 16:07:46 UTC
Created attachment 4835 [details] [review]
Relax xf86AllocateOffscreenLinear() granularity restriction

Please let me know if that works too, it's totally untested, but the idea is
instead to let xf86AllocateOffscreenLinear() allocate when the requested
granularity doesn't match the front buffer pitch, by allocating a bit more and
aligning the result. It should work with xf86FreeOffscreenLinear() since the
->area field will point to the right box to be freed.
Comment 6 Benjamin Herrenschmidt 2006-03-06 16:20:16 UTC
Created attachment 4836 [details] [review]
Relax xf86AllocateOffscreenLinear() granularity restriction #2

And a less sucky version of it :)
Comment 7 Julio Merino 2006-03-07 06:16:08 UTC
Your patch does fix the problem too. 
Comment 8 Damien Laniel 2006-04-05 22:00:26 UTC
Same problem here on Debian.
Will the patch be applied ?
Comment 9 Erik Andren 2006-04-06 18:45:55 UTC
Damien, did BenH's patch also resolve your issue?
Comment 10 Damien Laniel 2006-04-12 01:55:27 UTC
I didn't test it. I don't have time to compile and test it at the moment. I
asked Julio if he had but I didn't receive his answer yet. In case he doesn't
answer and noone else can do it, I may have some time to do it in a few weeks.
Comment 11 Damien Laniel 2006-04-12 01:59:44 UTC
Ok, i've just got his answer :)

Julio M. Merino Vidal wrote :
"I did; and in fact, I have been running with it since it was posted.  My answer
is already in the bug report..."
Comment 12 Philip Paeps 2006-05-10 05:58:01 UTC
Just a "me too!" to note that this patch also works for me - same graphics card,
display is a Philips Brilliance 200W.
Comment 13 Henry Precheur 2006-08-13 03:28:48 UTC
The patch fixes the problem on my machine.
nvidia fx5200 + viewsonic 2025wm
I applied the patch against the X.org version included in OpenBSD 3.9 (6.9 +
patches from OpenBSD).

Comment 14 Matthieu Herrb 2006-10-04 12:55:28 UTC
Would be be neat to include that in 7.2, no ?
Comment 16 Daniel Stone 2006-11-04 09:40:23 UTC
i'd prefer to bump this one out to 7.3, since it might break in non-obvious ways.
Comment 17 Daniel Stone 2006-12-16 09:47:05 UTC
committing to xserver master, not doing it for 1.2.x

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.