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 resolution. 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.
Created attachment 4830 [details] [review] Possible workaround.
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 */ xfree(link); 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.
Created attachment 4833 [details] [review] Proposed fix.
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.
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.
Created attachment 4836 [details] [review] Relax xf86AllocateOffscreenLinear() granularity restriction #2 And a less sucky version of it :)
Your patch does fix the problem too.
Same problem here on Debian. Will the patch be applied ?
Damien, did BenH's patch also resolve your issue?
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.
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..."
Just a "me too!" to note that this patch also works for me - same graphics card, display is a Philips Brilliance 200W.
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). Thanks
Would be be neat to include that in 7.2, no ?
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86fbman.c.diff?r1=1.33&r2=1.34 may be a more complete fix.
i'd prefer to bump this one out to 7.3, since it might break in non-obvious ways.
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.