+++ This bug was initially created as a clone of Bug #2772 +++ As mentioned in #2772, this problem persists with the i810 driver. See also: http://bugzilla.gnome.org/show_bug.cgi?id=351784
Xorg.0.log, server, and driver version.
Created attachment 9977 [details] Xorg.0.log version: 1.7.4-0ubuntu1
Already fixed.
Eric, which version would that be fixed in?
xf86-video-intel 2.0
I'm using xorg-x11-drv-i810-2.0.0-3.fc7, and still see that problem with compiz running. Running under metacity doesn't show problems.
compiz shouldn't be able to affect this. You're just running compiz on xorg, not compiz on xgl on xorg, right?
No GLX, it's a plain Fedora 7 install. Let me know if you would need to be able to debug this.
Same here, xorg-x11-drv-i810-2.0.0-3.fc7, metacity, xorg-x11-server-Xorg-1.3.0.0-5.fc7 and Section "Device" Identifier "Videocard0" Driver "i810" Option "VideoRam" "65536" Option "LinearAlloc" "6144" EndSection I get this even with small videos (320x200) if played multiple times with mplayer, which suggest a video memory leak. (totem can't open them anymore too after this occurs)
I can confirm this behaviour too; it only happens when compiz is running. It happens with even just a tiny crappy mobile phone video, so it's not related to hd output. If I kill compiz with 'metacity --replace' running the same video then works. This is with compiz 0.5.0 and the Debian 2.0.0 xserver-xorg-video-intel package on an 915GM/GMS/910GML. I have a very un-fancy xorg.conf with Section "Device" Identifier "Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller" Driver "intel" BusID "PCI:0:2:0" Option "UseFBDev" "true" Option "XAANoOffscreenPixmaps" "true" Option "DRI" "true" EndSection Section "Extensions" Option "Composite" "true" EndSection Also seems to be reported by ubuntians https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/111257
(In reply to comment #10) > Option "XAANoOffscreenPixmaps" "true" Does it happen without this option? (Fedora might still be using the hack to disable XAA offscreen pixmaps when starting a GLX compositing manager)
> Does it happen without this option? (Fedora might still be using the hack to > disable XAA offscreen pixmaps when starting a GLX compositing manager) Although I'm using Debian, if I turn this option off none of my terminal window contents get painted, but running "blind" the same thing happens when I try to play a video anyway.
Oh, right. We still have the chance to BadAlloc with XAA, because XAA has no mechanism to force pixmaps into framebuffer. The alternative would be to just violate the composite extension requirements and draw to the front buffer like we used to, but nobody likes that either.
I've experienced this problem too, in my normal x-session with beryl+kde all attempts to use Xv fails with the BadAlloc error message. I've tested to comment out all Options to the intel driver in my xorg.conf, and starting the X server with only an xterm in it, then Xv playback works. If i start beryl it breaks, when i kill beryl it works again. The same goes for xcompmgr. I've tested with both xserver-xorg-video-intel version 2.0.0-1ubuntu2 and a git snapshot from 2007-06-18 with the same results.
Confirmed on an archlinux system using xorg-server 1.3, the intel 2.0.0 driver, kde 3.5.7 and any player with Xv output. Opengl and other output works fine.
Confirmed on Ubuntu Gutsy with Intel driver 2:2.0.0-1ubuntu2 (Tribe 2 Live CD). I always got BadAlloc (insufficient resources for operation) with every video player. If I use the i810 driver I got a flickering image which results in a black screen but at least the video player doesn't crash directly. It seems that compiz fusion uses to much resources so there is nothing left for xv. I have a laptop with Intel 915 chipset.
Also seeing the issue with 965 chipset on Ubuntu Gutsy (tribe3) with xserver-xorg-video-intel 2:2.1.0-1ubuntu1
After talking to Eric, he mentioned that the problem is because of the use of XAA. And although he doesn't directly mention what the work-around is, he repeated it to me during our talk. Add to the device section: Option "AccelMethod" "EXA" It doesn't exactly work well on my machine (performance-wise), but it does play instead of crashing. Eric, 2722 is a proper dupe.
This bug looks a lot like bug #11643, but the answer was determinant there: "There is no way to correctly support XV with XAA and Composite, and the result is that you get an error when you try to do so. Use EXA instead." Who is the dupe? (more info there, earlier here).
*** Bug 11643 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > This bug looks a lot like bug #11643, but the answer was determinant there: > > "There is no way to correctly support XV with XAA and Composite, and the result > is that you get an error when you try to do so. Use EXA instead." It is true that using EXA allows the use of XV, but as I mentioned in #11643 performance is just terrible. I'd rather use XAA without XV. Additionally, using EXA+compiz draws some weird artifacts around windows: http://img175.imageshack.us/img175/3981/screenexapi0.png Thanks!
(In reply to comment #18) > After talking to Eric, he mentioned that the problem is because of the use of > XAA. And although he doesn't directly mention what the work-around is, he > repeated it to me during our talk. Add to the device section: > Option "AccelMethod" "EXA" Seems not to be a solution, as it works REALLY slow compared to default method. My configuration: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03) Gentoo Linux x86 x11-libs/libXv-1.0.3 x11-base/xorg-server-1.3.0.0 x11-drivers/xf86-video-i810-2.1.0, also affects x11-drivers/xf86-video-i810-2.1.1, DOES NOT affects x11-drivers/xf86-video-i810-1.7.4 media-libs/mesa-6.5.2-r1 tried also media-libs/mesa-7.0.1 - the same effect Composite enabled, kwin komposite enabled, NO beryl or compyz
It has been fixed in Ubuntu Gutsy with overlay. If someone is interested: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/111257
(In reply to comment #23) > It has been fixed in Ubuntu Gutsy with overlay. If someone is interested: > https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/111257 That doesn't work on my system, even forcing the textured overlay.
Very funny. With xv I get around 0.2 fps when playing 1920x816 movie (most of the CPU time spent on I830PutImage). With X11 around 20 fps. Latest git versions of xorg, mesa, drm, intel_drv. When using xv, also other dock apps are updated at 0.2 fps rate! xv worked great with Fedora's 1.3.x Xorg, mesa and libdrm. And where did my "video overlay" go? I remember I had that before. Unfortunately I can't find xvinfo outputs from earlier months. Intel(R) 965Q. X-Video Extension version 2.2 screen #0 Adaptor #0: "Intel(R) Textured Video" number of ports: 16 port base: 73 operations supported: PutImage supported visuals: depth 24, visualID 0x23 depth 24, visualID 0x24 depth 24, visualID 0x25 depth 24, visualID 0x26 depth 24, visualID 0x27 depth 24, visualID 0x28 depth 24, visualID 0x29 depth 24, visualID 0x2a number of attributes: 2 "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range 0 to 255) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 1920 x 1088 Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x59565955 (UYVY) guid: 55595659-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed)
>> And where did my "video overlay" go? overlay is not supported on i965.
I have had enough with this "stable" 1.4. I went back to Fedora's 1.3.0.0-24 x86_64 Xorg and i810. xvideo works. Keyboard leds work (except scroll lock). At least somebody has quality control.
(In reply to comment #27) > I have had enough with this "stable" 1.4. > I went back to Fedora's 1.3.0.0-24 x86_64 Xorg and i810. > > xvideo works. Keyboard leds work (except scroll lock). > At least somebody has quality control. Which means that you have nothing to contribute to this bug report, so go away.
*** Bug 12527 has been marked as a duplicate of this bug. ***
This is a regression versus the old, non-native mode setting driver. However, this configuration should work if you use the EXA acceleration method instead of XAA. XAA has several other limitations as well, so we'll be moving to EXA by default in the next release, hopefully dropping XAA altogether at some point.
*** Bug 12647 has been marked as a duplicate of this bug. ***
*** Bug 9930 has been marked as a duplicate of this bug. ***
we won't fix XAA issue any more and move to EXA. Please test EXA and if it doesn't work, please open a new bug. I'll close this bug. thanks.
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.