When using xorg-x11 with the ati-drivers higher resolution videos using the XV driver don't work. Lower resolutions like 320*240 seem to work fine. Reproducible: Always Steps to Reproduce: 1. Open any video player using XV as video out driver (I have tested it with xine and mplayer. 2. Start a video with a higher resolution like 640*480 Actual Results: You get a blank screen in some players like kaffeine or xine. Mplayer freezes and I have to kill it by hand. Expected Results: Show the video :) AthlonXP-2500+, Chipset VIA KT600, GFX Card ATI Radeon 9800 Pro. I am running the 2.5.6 mm-sources. My system is up to date. I noticed that removing the MTRR kernel option fixes the problem but then the drawing speed of any graphics is terribly slow. Here are some error messages I got as console output: using Kaffeine: X Error: BadAlloc (insufficient resources for operation) 11 Major opcode: 140 Minor opcode: 19 Resource id: 0x3600003 using gmplayer: VO: [xv] 720x576 => 768x576 Planar YV12 [ws] Error in display. 0.323 ct: 0.000 1/ 1 0% 0% 0.0% 0 6 24% [ws] Error code: 11 ( BadAlloc (insufficient resources for operation) ) [ws] Request code: 140 [ws] Minor code: 19 [ws] Modules: flip_page If any more information is needed I will try to provide it.
I can confirm this problem. I didn't report it, because I thought the closed source ATI drivers were to blame. ;) I noticed a couple of details: 1) This bug seems to affect xine more than mplayer. If I switch to fullscreen playback in xine, it crashes in about a second. Mplayer doesn't mind and runs fine at full-screen, though. 2) the problem is ven more severe (with even mplayer and tvtime crashing upon startup) when Firefox is active. It might not only be Firefox, but any GUI intensive appliction, I haven't tested this more throroughly yet. 3D performance is fine, as far as I can determine. The open-source ATI-drivers (which are 2D-only on my 9700) that are provided with X.org don't have this XV-bug, so it's most likely an issue with closed source drivers in the ati-drivers ebuild. Oh well, I guess it's a miracle that the closed-source ATI drivers continued functioning with the first X.org release in te first place. :D
Well I don't blame Xorg that it's not working anymore but maybe it would be possible to create a patch that works around that problem.
I'm having a similar problem-XV works most of the time but if I have alot of apps open (firefox, some xterms etc.) I will get: X11 error-BadAlloc (insufficient resources for operation) Mplayer interrupted by signal 6 in module: flip_page I've only seen it when using mplayerplug-in, which is usually when I have the most apps open. When watching a full length avi or DVD I haven't had any problems but I don't normally have any other apps open. If I do get the error when running mplayerplug-in usually if I close firefox and restart it it will play the same clip fine. I've read several similar accounts of this in the gentoo forums but not all were running ati cards so it might not be the ati-drivers....anway, some food for thought.
Known issue
My gentoo has the same problem. Each time I met the mplayer -vo xv problem, I just close, then reopen firefox. mplayer -vo xv will work again. So I guess firefox in xorg-x11 has some conflicts with ati-drivers.
Acording to this thread: http://www.rage3d.com/board/showthread.php?s=&postid=1332865459#post1332865459 " quote:Originally posted by mroy Yep, but you need root access for vidix... We need to find a solution for that xv. XV works with the Radeons. Your XF86Config must have the right options. See mine for details: http://borgerding.org/XF86Config X.org has a bug that breaks XV overlay (as mentioned in a million other posts). If you can't get XV to work with X.org, you might as well stop trying for now. It's broken. It's X.org's fault. It affects several different video chips in addition to the ATIs. If your xorg.conf file is correct, XV *might* work on occasion, but it normally breaks when you feed it a movie that is larger than 320x240 in resolution. There is no known solution at the moment. I guess that if someone looked at the CVS commits for that potion of the code, and made a patch, we could get it to work. Unfortunately, bobody has done it yet. I may be off-base, but it was my belief that XV didn't work with versions of the ATI driver that are older than 3.7.0. If you are still using 3.2.8, try upgrading to at least get *some* intermittent XV support with X.org. " It appears that this is not a bug on the ati-drivers but with xorg. Can someone comment on this?
Just bumping to say ati-drivers 3.9.0 didn't solve the problem.
It appears to be fixed on xorg cvs. http://www.rage3d.com/board/showthread.php?s=&threadid=33761652
I browsed through their CVS. I looked in all the Xv-related directories I could find and almost all files had a date from 7 weeks ago. Does anyone know what particular file the fix was in?
There is no fix, have a look at the above URL, it was a mistake by the author of the thread.
In the same thread as mentioned above someone posted a workaround, so far it is working for me (tested with both mplayer & xine using xv as the output method). The workaround is: add Option "XaaNoOffscreenPixmaps" to /etc/X11/xorg.conf in Section "Device" describing the ATI card. my versions: xorg-x11 6.7.0 ati-drivers 3.7.6-r1 my screen resolution: 1024x768 @ 32 bits colour depth so far I have seen no adverse effects of using this option...
*** Bug 49591 has been marked as a duplicate of this bug. ***
Did anyone try the workaround that I posted above? Also does anyone know what the option XaaNoOffscreenPixmaps actually is doing (any negative effects of this option)?
Just tried it out. Seems to work for me. No immediately obvious side effects
This workaround also works for me. I am curious if that X.org CVS checkout that someone mentioned fixes this without the workaround?
The "XaaNoOffscreenPixmaps" option seems to be working here also, thanks for the info.
According to the forums the workaround also helps for other cards than ATI that have a borken xv support: cards mentioned are Sis630, Intel i810. See http://forums.gentoo.org/viewtopic.php?t=167445&highlight=xorg+xv
After some googling, it appears that: Option "XaaNoOffscreenPixmaps" Disables accelerated draws into pixmaps stored in offscreen video memory. Whatever that means....... anyone care to enlighten us? (In english ;)
While the workaround has fixed most apps for me, it has broken tvtime, which worked just fine before (as long as it wasn't bitten by the original bug). When tvtime launches, I never get a picture, and then it eventually dies after 10-15 seconds.
@Andrew Gaffney Start tvtime from a shell, so you can see the error messages. tvtime is rather verbose with its error messages.
agaffney@kagome agaffney $ watchtv Simple mixer control 'Mic',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Playback channels: Mono Capture channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Playback 31 [100%] [on] Front Left: Capture [on] Front Right: Capture [on] Running tvtime 0.9.12. rtctimer: Cannot open /dev/rtc: Permission denied rtctimer: Cannot open /dev/misc/rtc: Permission denied Enhanced Real Time Clock support in your kernel is necessary for smooth video. We strongly recommend that you load the 'rtc' kernel module before starting tvtime, and make sure that your user has access to the device file (/dev/rtc or /dev/misc/rtc). See our support page at http://tvtime.net/ for more information. Reading configuration from /etc/tvtime/tvtime.xml Reading configuration from /home/agaffney/.tvtime/tvtime.xml videoinput: Can't read frame. Error was: Input/output error (0). videoinput: Can't read frame. Error was: Input/output error (0). videoinput: Can't read frame. Error was: Input/output error (0). /usr/local/bin/watchtv: line 4: 4066 Segmentation fault tvtime -I 720 -H 288 Simple mixer control 'Mic',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Playback channels: Mono Capture channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Playback 31 [100%] [off] Front Left: Capture [on] Front Right: Capture [on] agaffney@kagome agaffney $ cat /usr/local/bin/watchtv #!/bin/bash amixer set Mic unmute tvtime -I 720 -H 288 amixer set Mic mute While it doesn't give me an Xv error, I don't think it gave me an Xv error before when it wouldn't work (before adding that line to xorg.conf).
I found that mplayer crashes as well (worked fine before I updated to xorg - why, oh why, did I update?) with the following text:- Checking audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit... AF_pre: af format: 2 bps, 2 ch, 48000 hz, little endian signed int AF_pre: 48000Hz 2ch Signed 16-bit (Little-Endian) AO: [oss] 48000Hz 2ch Signed 16-bit (Little-Endian) (2 bps) Building audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit... Starting playback... VDec: vo config request - 480 x 352 (preferred csp: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.36:1 - prescaling to correct movie aspect. VO: [xv] 480x352 => 480x352 Planar YV12 [fs] X11 error: BadAlloc (insufficient resources for operation) 0.0% 1 0 99% MPlayer interrupted by signal 6 in module: flip_page - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug. Successfully enabled DPMS Xlib: unexpected async reply (sequence 0x6f)! ========================= Mplayer version is $ mplayer -? MPlayer 1.0pre5-3.3.3 (C) 2000-2004 MPlayer Team CPU: Intel Pentium 4/Xeon/Celeron Foster 2614 MHz (Family: 8, Stepping: 9) Detected cache-line size is 64 bytes MMX supported but disabled MMX2 supported but disabled SSE supported but disabled SSE2 supported but disabled CPUflags: MMX: 0 MMX2: 0 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0 Compiled for x86 CPU with extensions: ===== OS Version is $ cat /proc/version Linux version 2.6.7-gentoo-r11 (root@lyalls-pc) (gcc version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #5 SMP Sun Jul 18 01:49:43 CST 2004 ===== emerge --pretend --deep world (as at 22-Jul-2004 gives) [blocks B ] x11-base/xfree (from pkg x11-base/xorg-x11-6.7.0-r1) [blocks B ] >=net-www/apache-2* (from pkg dev-util/subversion-1.0.6) [ebuild U ] net-misc/neon-0.24.7 [0.24.6] [ebuild U ] dev-util/subversion-1.0.6 [1.0.4-r1] So, my system is just about fully up to scratch - just have to figure out what to do with the two blockers.... ...Lyall
Work around has been posted at http://forums.gentoo.org/viewtopic.php?t=165336 This workaround appears to work. It worked for me, anyway.
I was talking to Keith Packard about this issue yesterday. He claims that XAA is fundamentally broken in X, and it may soon be ripped out altogether. 2D acceleration like what XAA provides is negligible. The reason the problem happens is that there is not enough memory assigned off-screen. That's why a dimension-wise small video still works. It's possible that on some chipsets something as simple as closing Mozilla could free up the XAA memory, as all the graphics in Mozilla are drawn this way.
Appears to be fixed on the comming 6.8: http://freedesktop.org/bugzilla/show_bug.cgi?id=474
Please reopen if it isn't fixed in 6.8.
I use mplayer quite often, so I can confirm that since xorg 6.8, this problem has disappeared (for me, so far). I could comment out the following workaround a few months ago: Option "XaaNoOffscreenPixmaps" Everything worked fine so far -- but still, I will let others know if I see something :-)
It looks like this might still be a problem. Anyone still seeing this? So far reports have come from Debian/Ubuntu only, so maybe it's something wrong with their packages.
