Bug 10912 - [intel] Composite + XAA + Xv incompatible
Summary: [intel] Composite + XAA + Xv incompatible
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.2 (2007.02)
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Eric Anholt
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: regression
: 9930 11643 12527 12647 (view as bug list)
Depends on: 2772
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-10 20:35 UTC by David Schleef
Modified: 2008-01-03 18:58 UTC (History)
13 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (74.39 KB, text/plain)
2007-05-15 12:56 UTC, David Schleef
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Schleef 2007-05-10 20:35:12 UTC
+++ 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
Comment 1 Eric Anholt 2007-05-11 12:54:02 UTC
Xorg.0.log, server, and driver version.
Comment 2 David Schleef 2007-05-15 12:56:12 UTC
Created attachment 9977 [details]
Xorg.0.log

version:

1.7.4-0ubuntu1
Comment 3 Eric Anholt 2007-05-15 14:17:51 UTC
Already fixed.
Comment 4 Bastien Nocera 2007-05-15 15:52:08 UTC
Eric, which version would that be fixed in?
Comment 5 Eric Anholt 2007-05-17 11:42:48 UTC
xf86-video-intel 2.0
Comment 6 Bastien Nocera 2007-05-22 05:13:49 UTC
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.
Comment 7 Eric Anholt 2007-05-24 14:51:55 UTC
compiz shouldn't be able to affect this.  You're just running compiz on xorg, not compiz on xgl on xorg, right?
Comment 8 Bastien Nocera 2007-05-24 15:03:03 UTC
No GLX, it's a plain Fedora 7 install. Let me know if you would need to be able to debug this.
Comment 9 Marius Andreiana 2007-05-29 22:41:19 UTC
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)
Comment 10 Ian Wienand 2007-05-31 21:56:30 UTC
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
Comment 11 Michel Dänzer 2007-06-01 00:24:05 UTC
(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)
Comment 12 Ian Wienand 2007-06-02 17:33:23 UTC
> 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.
Comment 13 Eric Anholt 2007-06-12 10:23:05 UTC
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.
Comment 14 Mikael Gerdin 2007-06-19 14:56:18 UTC
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.
Comment 15 Nick Beezzy 2007-06-28 23:36:01 UTC
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.
Comment 16 unggnu 2007-06-30 05:19:43 UTC
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.
Comment 17 Paul McGarry 2007-07-20 17:56:04 UTC
Also seeing the issue with 965 chipset on Ubuntu Gutsy (tribe3) with xserver-xorg-video-intel 2:2.1.0-1ubuntu1
Comment 18 Bastien Nocera 2007-07-21 13:54:11 UTC
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.
Comment 19 Juan Pablo Salazar Bertin 2007-08-15 15:22:49 UTC
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).
Comment 20 Eric Anholt 2007-08-17 19:42:55 UTC
*** Bug 11643 has been marked as a duplicate of this bug. ***
Comment 21 Jack Malmostoso 2007-08-17 23:54:29 UTC
(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!
Comment 22 Denis Misiurca 2007-09-10 14:48:06 UTC
(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
Comment 23 unggnu 2007-09-19 05:09:44 UTC
It has been fixed in Ubuntu Gutsy with overlay. If someone is interested: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/111257
Comment 24 Bastien Nocera 2007-09-20 04:27:19 UTC
(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.
Comment 25 Sami Farin 2007-09-26 02:21:12 UTC
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)
Comment 26 Gordon Jin 2007-09-26 02:39:56 UTC
>> And where did my "video overlay" go?

overlay is not supported on i965.
Comment 27 Sami Farin 2007-09-26 10:24:35 UTC
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.
Comment 28 Daniel Stone 2007-09-26 15:32:02 UTC
(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.
Comment 29 Michel Dänzer 2007-10-13 04:24:12 UTC
*** Bug 12527 has been marked as a duplicate of this bug. ***
Comment 30 Jesse Barnes 2007-10-31 12:45:27 UTC
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.
Comment 31 Jesse Barnes 2007-10-31 12:50:09 UTC
*** Bug 12647 has been marked as a duplicate of this bug. ***
Comment 32 Eric Anholt 2007-11-06 17:17:51 UTC
*** Bug 9930 has been marked as a duplicate of this bug. ***
Comment 33 Michael Fu 2008-01-03 18:58:25 UTC
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.