totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver

Bug #111257 reported by mon
226
This bug affects 2 people
Affects Status Importance Assigned to Milestone
X.Org X server
Won't Fix
High
Fedora
Fix Released
Medium
compiz (Ubuntu)
Fix Released
Undecided
Unassigned
Nominated for Gutsy by unggnu
xserver-xorg-video-intel (Ubuntu)
Fix Released
High
Michael Vogt
Nominated for Gutsy by unggnu

Bug Description

Hi

I have a widescreen monitor (1440x900) and in order to use it in feisty (x86) I've installed the xserver-xorg-video-intel since 915resolution didn't work out of the box. With this driver I can have maximum resolution and everything seems to work fine, including using video applications (like totem), the problem arises when I'm using compiz and I try to use a video application (totem playing a video or launching pitivi for example).

As said I'm using feisty x86 up to date on a intel x3000 video card.

thanks

Tags: iso-testing

Related branches

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :
Revision history for this message
mon (javiermon-deactivatedaccount) wrote :
Revision history for this message
mon (javiermon-deactivatedaccount) wrote :
description: updated
Revision history for this message
hey560 (hey560) wrote :

I can confirm this bug. It is an XV issue i think.

Changed in totem:
status: Unconfirmed → Confirmed
Revision history for this message
Niels Breet (maemo) wrote :

I'm having these problems too. Feisty x86 on Intel GMA 3000.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Description of problem:
Totem immediately crashes under Compiz when playing back movie files of any type
(avi, mpeg, mov, ogg, etc)

Error on the command line is as follows:
The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 57 error_code 11 request_code 140 minor_code 19)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Version-Release number of selected component (if applicable):
totem-2.18.1-3.fc7

How reproducible:
100%

Steps to Reproduce:
1. Open *any* movie file, any format
2. Watch Totem croak

Additional info:
Under Metacity, everything plays fine.

Revision history for this message
In , Bastien (bastien-redhat-bugs) wrote :

Works here. Could you please run "totem --sync", and reproduce the problem as
described in the error message? Make sure you install the relevant -debuginfo
packages so that the backtrace has debugging information.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Trying to watch this: http://www.redhat.com/v/ogg/060407_CDadapco.ogg

$ totem --sync 060407_CDadapco.ogg
The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 51 error_code 11 request_code 140 minor_code 19)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Then I tried just opening totem with "totem --sync" and opening the file from
the File --> Open menu item, and got:

$ totem --sync
((( opened file with File --> Open )))
The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 48 error_code 11 request_code 140 minor_code 19)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Oh, and yes, all the debuginfo packages are installed.

Revision history for this message
In , Bastien (bastien-redhat-bugs) wrote :

You need to run it under gdb, and break on gdk_x_error(), as per the error message.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

sorry - I'm not very familiar with gdb...

I tried anyhow, and the session looked like the following:

$gdb
(gdb) file /usr/bin/totem
Reading symbols from /usr/bin/totem...Reading symbols from
/usr/lib/debug/usr/bin/totem.debug...done.
Using host libthread_db library "/lib/libthread_db.so.1".
done.
(gdb) break gdk_x_error
Breakpoint 1 at 0x453d83: file gdkmain-x11.c, line 614.
(gdb) run --sync
Starting program: /usr/bin/totem --sync
Error in re-setting breakpoint 1:
No source file named gdkmain-x11.c.
(the above gets printed about 15 times...)
[Thread debugging using libthread_db enabled]
[New Thread -1208166688 (LWP 5364)]
[New Thread -1223857264 (LWP 5366)]
[New Thread -1234347120 (LWP 5367)]
[New Thread -1249436784 (LWP 5368)]
[New Thread 27011984 (LWP 5369)]
[New Thread 37501840 (LWP 5370)]
[New Thread 48438160 (LWP 5371)]
[New Thread 62376848 (LWP 5372)]
[New Thread 104319888 (LWP 5373)]
[New Thread 129432464 (LWP 5374)]
[Switching to Thread 62376848 (LWP 5372)]

Breakpoint 1, gdk_x_error (display=0x9ffd6a0, error=0x3b7b718)
    at gdkmain-x11.c:614
614 if (error->error_code)
(gdb)

I'm guessing I'm still doing something wrong, but I have no idea what. :-/

Revision history for this message
In , Bastien (bastien-redhat-bugs) wrote :

> I'm guessing I'm still doing something wrong, but I have no idea what. :-/

You're just missing typing "bt" :)

You might also want to install the -debuginfo packages as well (yum
--enablerepo=development-debuginfo install gtk2-debuginfo ...)

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Hey now, see #3 - I already got all the DB packages installed. :-)

Anyhow, thanks for the tip - here's the results:

jensck@daemon ~
$ gdb
GNU gdb Red Hat Linux (6.6-8.fc7rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
(gdb) file /usr/bin/totem
Reading symbols from /usr/bin/totem...Reading symbols from
/usr/lib/debug/usr/bin/totem.debug...done.
Using host libthread_db library "/lib/libthread_db.so.1".
done.
(gdb) break gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (gdk_x_error) pending.
(gdb) run --sync
Starting program: /usr/bin/totem --sync
[Thread debugging using libthread_db enabled]
[New Thread -1208723744 (LWP 3906)]
Breakpoint 2 at 0x453d83: file gdkmain-x11.c, line 614.
Pending breakpoint "gdk_x_error" resolved
[New Thread -1224414320 (LWP 3910)]
[New Thread -1234904176 (LWP 3911)]
[New Thread -1249993840 (LWP 3914)]
[New Thread 26729360 (LWP 3918)]
[New Thread 123607952 (LWP 3919)]
[New Thread 45018000 (LWP 3925)]
[New Thread 55507856 (LWP 3929)]
[New Thread 65997712 (LWP 3930)]
[New Thread 82574224 (LWP 3931)]
[Switching to Thread 55507856 (LWP 3929)]

Breakpoint 2, gdk_x_error (display=0x89855f0, error=0x34ee718)
    at gdkmain-x11.c:614
614 if (error->error_code)
(gdb) bt

The actual backtrace is attached.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Created attachment 154367
Backtrace from this crash

Revision history for this message
In , Bastien (bastien-redhat-bugs) wrote :

Looks like this bug I filed some time ago:
http://bugzilla.gnome.org/show_bug.cgi?id=351784

I bet that GL is nicking video RAM from Xv.

What's the output of "xvinfo | grep max" on your system? Which video card are
you using? What resolution/depth are you running at (xdpyinfo output)?

On my system, using the maximum values from xvinfo to run:
gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=<width>,height=<height> !
xvimagesink

shows the same problem.

Revision history for this message
In , Bastien (bastien-redhat-bugs) wrote :

Note that xvimagesimagesink will try to use double-buffering by default, which
will limit the amount of memory really available for Xv. See:
http://bugzilla.gnome.org/show_bug.cgi?id=437169
about making it configurable/a property (so that we can switch it off for testing)

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

$ xvinfo | grep max
    maximum XvImage size: 1920 x 1088
    maximum XvImage size: 1920 x 1088

This is what seems to be the relevant piece of xdpyinfo:

screen #0:
  dimensions: 1680x1050 pixels (331x207 millimeters)
  resolution: 129x129 dots per inch
  depths (7): 24, 1, 4, 8, 15, 16, 32
  root window id: 0x6c
  depth of root window: 24 planes
  number of colormaps: minimum 1, maximum 1
  default colormap: 0x20
  default number of colormap cells: 256
  preallocated pixels: black 0, white 16777215
  options: backing-store NO, save-unders NO
  largest cursor: 64x64
  current input event mask: 0x7a803f
    KeyPressMask KeyReleaseMask ButtonPressMask
    ButtonReleaseMask EnterWindowMask LeaveWindowMask
    ExposureMask StructureNotifyMask SubstructureNotifyMask
    SubstructureRedirectMask FocusChangeMask PropertyChangeMask
  number of visuals: 17
  default visual id: 0x23
  visual:
    visual id: 0x23
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Created attachment 154440
Full xdpyinfo output, just in case you want it

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Video card is i945 on a laptop - per HAL, it's called a "Mobile 945GM/GMS,
943/940GML Express Integrated Graphics Controller"

I tried the gst-launch command line you gave, too - even 320x240 fails:

$ gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=320,height=240 ! xvimagesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 140 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 45
  Current serial number in output stream: 46

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Duh - I forgot to try this before, but I can play videos w/Compiz just fine with
this same install if I tell xorg.conf to use the i810 driver instead of the new
'intel' driver. (Mind you, that means going back to using lame 915resolution
hack, etc.)

Revision history for this message
In , Bastien (bastien-redhat-bugs) wrote :

My upstream report was also with this same driver, reassigning to the xorg driver.

Revision history for this message
In , David Schleef (dschleef) wrote :

+++ 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

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

Xorg.0.log, server, and driver version.

Revision history for this message
John B. (jbuncher) wrote :

I'm having the same issues as well on a 1280x800 screen. For me, switching the video out ("vo") to x11 rather than xv lets the videos play, though I would much rather like to use xv.

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

gstreamer seems to work with x11 output, but xine doesn't. Since I'm using totem-xine to have dvd playback this isn't a workaround for me.

Revision history for this message
Baggie (hyperpiper) wrote :

Same here - playing mp3/flac/ video all cause totem to crash when compiz is enabled

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

Baggie, the crash while playing audio is caused because you have visualizations turned on.

Revision history for this message
In , David Schleef (dschleef) wrote :

Created an attachment (id=9977)
Xorg.0.log

version:

1.7.4-0ubuntu1

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

Already fixed.

Revision history for this message
In , Bastien Nocera (hadess-deactivatedaccount) wrote :

Eric, which version would that be fixed in?

Revision history for this message
Luca Rosellini (luca-rosellini) wrote :

Same problem here on an intel 915GM, both totem (using gstreamer backend) and mplayer crash receiving the X11 error: "BadAlloc (insufficient resources for operation)"

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

xf86-video-intel 2.0

Revision history for this message
In , Bastien Nocera (hadess-deactivatedaccount) wrote :

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.

Revision history for this message
In , Bastien (bastien-redhat-bugs) wrote :

See also:
https://bugs.freedesktop.org/show_bug.cgi?id=10912

It works fine for me with xorg-x11-drv-i810-2.0.0-3.fc7, under metacity, but
still fails under compiz. I believe it might be trying to use the "Textured" Xv
port which has most of its memory used up by compiz.

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

compiz shouldn't be able to affect this. You're just running compiz on xorg, not compiz on xgl on xorg, right?

Revision history for this message
In , Bastien Nocera (hadess-deactivatedaccount) wrote :

No GLX, it's a plain Fedora 7 install. Let me know if you would need to be able to debug this.

Revision history for this message
welktach (welktach) wrote :

I have the same issue with using the xserver-xorg-video-intel driver in Ubuntu 7.04. Last night I changed drivers and just noticed this issue on my laptop. I have changed back to the xserver-xorg-vide-i810 along and using 915resolution to get 1280x800 on my screen, which is a work around. The reason I tried changing to this driver is because using i810 only gave me two choices for changing resolution in Gnome.

Revision history for this message
Jan Niklas Hasse (jhasse) wrote :
Revision history for this message
Luca Rosellini (luca-rosellini) wrote :

the fix linked by jhasse doesn't work for me on an intel 915GM

Revision history for this message
welktach (welktach) wrote :

I have an Intel 950GM and the fix also does not work for me.

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

Doesn't work here.

Intel x3000

Revision history for this message
Albert Abril (abrilc) wrote :

Here's the same problem, with a "Intel Corporation 82945G/GZ Integrated Graphics Controller" and a "Flatron TFT L192WS ( 19'' Widescreen )".
I'm running the fix 915resolution.

Video only fails when Compiz or Beryl are running, for all the video-players and video-editors.

Doesn't working the fix of jhasse here.

mplayer output:

Starting playback...
VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 320x240 => 320x240 Planar YV12
X11 error: BadAlloc (insufficient resources for operation)?,?% 0 0

MPlayer interrupted by signal 6 in module: vo_check_events
- 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.

Regards.

Revision history for this message
In , MA (mariusa) wrote :

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)

Revision history for this message
John B. (jbuncher) wrote : Re: [Bug 111257] Re: totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver

@Albert

I'm not sure if that is the same bug, if you say you're experiencing
it with 915resolution. The bug that has been reported here (at least
in my case) does NOT involve 915resolution (in fact, that's when stuff
works), but rather with the xserver-xorg-video-intel package/driver,
not the xserver-xorg-video-i810 + 915resolution package/driver/patch
combo.

On 5/29/07, Albert Abril <email address hidden> wrote:
> Here's the same problem, with a "Intel Corporation 82945G/GZ Integrated
> Graphics Controller" and a "Flatron TFT L192WS ( 19'' Widescreen )".
> I'm running the fix 915resolution.
>
> Video only fails when Compiz or Beryl are running, for all the video-
> players and video-editors.
>
> Doesn't working the fix of jhasse here.
>
> mplayer output:
>
> Starting playback...
> VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12)
> VDec: using Planar YV12 as output csp (no 0)
> Movie-Aspect is undefined - no prescaling applied.
> VO: [xv] 320x240 => 320x240 Planar YV12
> X11 error: BadAlloc (insufficient resources for operation)?,?% 0 0
>
>
> MPlayer interrupted by signal 6 in module: vo_check_events
> - 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.
>
> Regards.
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Albert Abril (abrilc) wrote :

Now, i have the intel driver (without 915resolution), and works fine for my
resolution.
However, with Compiz or Beryl running, still without can't play videos in
any video player.

Now, i can confirm the bug is with the xserver-xorg-video-intel
package/driver.

Thanks for the info.

On 5/30/07, John Buncher <email address hidden> wrote:
>
> @Albert
>
> I'm not sure if that is the same bug, if you say you're experiencing
> it with 915resolution. The bug that has been reported here (at least
> in my case) does NOT involve 915resolution (in fact, that's when stuff
> works), but rather with the xserver-xorg-video-intel package/driver,
> not the xserver-xorg-video-i810 + 915resolution package/driver/patch
> combo.
>
> On 5/29/07, Albert Abril <email address hidden> wrote:
> > Here's the same problem, with a "Intel Corporation 82945G/GZ Integrated
> > Graphics Controller" and a "Flatron TFT L192WS ( 19'' Widescreen )".
> > I'm running the fix 915resolution.
> >
> > Video only fails when Compiz or Beryl are running, for all the video-
> > players and video-editors.
> >
> > Doesn't working the fix of jhasse here.
> >
> > mplayer output:
> >
> > Starting playback...
> > VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12)
> > VDec: using Planar YV12 as output csp (no 0)
> > Movie-Aspect is undefined - no prescaling applied.
> > VO: [xv] 320x240 => 320x240 Planar YV12
> > X11 error: BadAlloc (insufficient resources for operation)?,?% 0 0
> >
> >
> > MPlayer interrupted by signal 6 in module: vo_check_events
> > - 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.
> >
> > Regards.
> >
> > --
> > totem crashes with 'BadAlloc (insufficient resources for operation)'
> when
> > using compiz and xserver-xorg-video-intel driver
> > https://bugs.launchpad.net/bugs/111257
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Revision history for this message
In , Ian Wienand (ianw) wrote :

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

Revision history for this message
In , Michel-tungstengraphics (michel-tungstengraphics) wrote :

(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)

Revision history for this message
In , Ian Wienand (ianw) wrote :

> 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.

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

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.

Revision history for this message
SickNick (sicknick2020) wrote :

I am having the same problem, running on 950GMA from Intel with the 915 driver and 915 resolution fix, it only happens with compiz on. I added the two lines to my xorg and it didnt fix it. Are there any fixes yet on this??

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

you can try an set a different video sync in gstreamer. I think the command is gstreamer-properties, but I can assure it since Im not at home.

Revision history for this message
Albert Abril (abrilc) wrote : Re: [Bug 111257] Re: totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver

Fine! It worked for me!!

Confirmed: the command is gsreamer-properties.

I went to the video tab, I selected "Default Output -> Plugin: X Window
System ( No XV )," and now works fine with Totem.
Only for totem. Not for mplayer neither VLC. Then, is reconfirmed that the
point is in the video output selected.

Thanks.

On 6/15/07, kmon <email address hidden> wrote:
>
> you can try an set a different video sync in gstreamer. I think the
> command is gstreamer-properties, but I can assure it since Im not at
> home.
>
>

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

Hi

It only works for gstreamer based player (so it doesn't work with totem-xine either).

Revision history for this message
In , Mikael Gerdin (mgerdin) wrote :

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.

Changed in xorg-server:
status: Unknown → Confirmed
Revision history for this message
In , Shirakawasuna (shirakawasuna) wrote :

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.

Revision history for this message
Jeffrey Knockel (jeff250) wrote :

Setting the video output plugin to "X Window System ( No XV )" means that you won't be getting xv video acceleration. This puts more strain on the CPU during video playback, and higher resolution videos can play jerkily.

Revision history for this message
Francisco Calderón (grunch) wrote : Re: any video player crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver

I have the same problem, my video card is Intel Corporation Mobile 945GM/GMS/940GML with the driver xserver-xorg-video-intel in ubuntu feisty, is not just the video doesnt work, when i was using beryl with edgy (with the 915resolution package), all the video players works and the rendering was perfect, now with feisty if you have beryl and see the top of the cube, you can see there is no normal quality in the original beryl (red with the ruby) top image, other think is when you use the fire effect you can see the bad quality comparing with the beryl in edgy.

Yesterday i install compiz fusion but is the same problem

Revision history for this message
In , unggnu (unggnu) wrote :

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.

Revision history for this message
unggnu (unggnu) wrote :

Confirmed on 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.
This is really serious since Gutsy enabled compiz per default and will use the Intel driver according to the Blueprint of xorg 7.3 so it isn't possible to play videos anymore. Even if the i810 driver is used it is still not really possible to watch videos.

Revision history for this message
Balaji (balaji-ramasubramanian) wrote :

Compiz seems to render excellent desktop effect, but is highly broken:

1. Many windows appear only black. This can happen with even windows that were appearing normal just a while back. If you minimize and unminimize it back, it may or may not appear black!!
2. Videos can't be viewed full-screen. The video will either be fully black or crash completely or generates an error related to display.
3. Video players crash without output. I tried fixing this by changing the XV settings etc., but it is of no use at all.

Clearly, this has nothing to do with hardware and is surely only a software issue. Please fix this early. You are leaving an excellent feature with bugs in Linux. This is the greatest disservice. Microsoft will get ideas and implement it bug-free!! Compiz if implemented properly has the potential to kill Microsoft's monopoly completely. It's amazing graphic rendering and intuitive desktop can be an amazing eye-catch. In fact, it has already become a favorite with iMac users. Just don't leave it with bugs please.

Revision history for this message
Bryce Harrington (bryce) wrote :

Moving to compiz package

Revision history for this message
priit (priit-ohlo) wrote :

Confirmed on Fujitsu-Siemens S7020 with Intel's i915

Doesn't work with xserver-xorg-video-intel, works with xserver-xorg-video-i810 + 915resolution, although there is heavy amount of flickering and shadows involved when trying to move the window or fullscreening it on a "bad" time. Works perfectly eventually.

Revision history for this message
mon (javiermon-deactivatedaccount) wrote :

Hi

I've tested new package from x's maintainer and the bug persists:
http://people.ubuntu.com/~kyle/testing/crestline/

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

Reporter, could you please reply to the previous question? If you won't reply in
one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Created attachment 159134
my xorg.conf

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Created attachment 159135
Xorg.0.log - using my xorg.conf (which only uses one edit from the default)

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Created attachment 159137
Xorg.0.log when using no xorg.conf

note that in this case, watching videos in Totem under Compiz works fine,
because when using no xorg.conf, X picks the 'i810' driver instead of the
'intel' driver

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

Created attachment 159138
Xorg.0.log when using a xorg.conf created solely from system-config-display

Revision history for this message
In , Jens (jens-redhat-bugs) wrote :

The problem still occurs under the xorg.conf created solely from
system-config-display

Revision history for this message
In , Paul McGarry (paul-paulmcgarry) wrote :

Also seeing the issue with 965 chipset on Ubuntu Gutsy (tribe3) with xserver-xorg-video-intel 2:2.1.0-1ubuntu1

Revision history for this message
In , Bastien Nocera (hadess-deactivatedaccount) wrote :

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.

Revision history for this message
In , Bastien (bastien-redhat-bugs) wrote :

I posted an explanation of what happens at:
https://bugs.freedesktop.org/show_bug.cgi?id=10912#c18

The performance of EXA is sub-par though when playing movies, but at least it
doesn't crash anymore.

Revision history for this message
Ben Wilber (benwilber) wrote :

This is a dupe of this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/122979

In Feisty the video app will still playback audio but the video will go blank or jittery. In Gutsy the video app just crashes. It's been confirmed with priority High. Resolving this bug is essential if Compiz Fusion is going to be turned on by default. It effects the Intel chips and the ATI chips that use the Free driver.

Revision history for this message
Travis Watkins (amaranth) wrote :

This is not a dupe of that bug, this one is a limitation in the Xv implementation in the intel driver. This seems to be an out of memory error. Also, not a bug in compiz.

Changed in compiz:
status: Confirmed → Invalid
Revision history for this message
Travis Watkins (amaranth) wrote :

Err, _that_ one is a limitation of the Xv implementation in the intel driver.

Revision history for this message
unggnu (unggnu) wrote :

Still present in Tribe 4. Please try to fix this or at least disable compiz for Intel cards.

Revision history for this message
Burt (albertus-wilson) wrote :

Have the same problem on my Intel Desktop board D946GZIS using Gutsy Tribe 4

http://www.intel.com/products/motherboard/D946GZIS/index.htm

Totem works fine with Desktop Effects disabled. However it crashed whenever I enable Desktop Effects.

totem --debug results in:

Gdk-ERROR **: The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 51 error_code 11 request_code 140 minor_code 19)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...
Trace/breakpoint trap

Please fix this for the final Gutsy

Revision history for this message
Juan Pablo Salazar Bertín (snifer) wrote :

Confirmed by a lot of people and upstream.

Changed in xserver-xorg-video-intel:
status: New → Confirmed
Revision history for this message
Jeff Starling (jeff-cheeber) wrote :

I'm getting the same BadAlloc errors with feisty and a Matrox Millenium G450 card. I filed a bug, https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/129495 which was marked as a dupe of this one. Am I the only person a) using this graphics card, and b) having this issue with a driver other than intel?

Finally, should this bug be affecting me?

Revision history for this message
In , Juan Pablo Salazar Bertín (snifer) wrote :

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).

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

*** Bug 243760 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

A lot of information and logs is in bug 2437ž0.

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

*** Bug 240956 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

*** Bug 11643 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Jack Malmostoso (malmostoso) wrote :

(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!

Revision history for this message
Götz Christ (g-christ) wrote :

I can confirm this problem with Feisty, driver "intel", Compiz Fusion, on a i865G
But with the "i810" driver there is no problem.
With the "intel" driver I can't play videos on Totem, but I can play them with Mplayer.

Revision history for this message
nvadekar (nvadekar) wrote :

i can confirm, intel driver has audio, no video but if I turn off desktop effects it all works fine, i810 works with desktop effects but suspend is broken and resulution are screwed up. interesting point I discoverd that had not yet been listed here, with desktop effects turned on using intel driver, it does work if logged in as root, but not a normal user. the desktop effects might be using a resource that is not world readable?

Revision history for this message
Mahdi (mahdi-hates-spam) wrote :

Xv crashes the apps using intel driver with gma950 (i915). Works fine with i810 driver though.
I'm running an un-to-date gutsy.

Revision history for this message
Tom Vetterlein (smbm) wrote :

I'm getting:

Gdk-ERROR **: The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 81 error_code 11 request_code 140 minor_code 19)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...
Aborted (core dumped)

On fully up to date Gutsy. X3100 graphics.

Changed in xserver-xorg-video-intel:
importance: Undecided → High
Revision history for this message
Justin Sunseri (jmsunseri) wrote :

Just wanted to add a backtrace of gstreamer-properties crashing while using the intel driver and setting the pipeline to vximagesink device ="0" while running a test. same error as other applications when they crash

Gdk-ERROR **: The program 'gstreamer-properties' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'. ...

Revision history for this message
unggnu (unggnu) wrote :

Since this issue has been fixed in i810 maybe this fix could be used in the new Intel driver too. It would be great since intel driver has more features and it will be the default driver in Gutsy (https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/135141).

Revision history for this message
Justin Sunseri (jmsunseri) wrote : Re: [Bug 111257] Re: totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver

Since i have moved to the i810 driver i have found X to be much less buggy.
I used to have problems with returning from suspend where the machine would
just have a black screen. The backlight would be on but the screen was
being painted black. I have not had the problem since i started using the
i810 driver. Why not revert back to i810 by default until these problems
have been solved? So far the only advanatge I have noticed to using intel
was that i didn't need the 915resolution fix.

On 9/5/07, unggnu <email address hidden> wrote:
>
> Since this issue has been fixed in i810 maybe this fix could be used in
> the new Intel driver too. It would be great since intel driver has more
> features and it will be the default driver in Gutsy
> (https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/135141).
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sincerely

Justin Sunseri

Revision history for this message
Travis Watkins (amaranth) wrote :

This is a different bug than the one for i810. This one is caused by the intel chip you have only supporting textured Xv which only works with composite if you enable EXA.

Revision history for this message
nanog (sorenimpey) wrote :

What is the status of this bug? It does not appear to be assigned to anyone yet. I would really recommend the use the intel driver in Gutsy as it works out of the box on many systems that were problematic previously. The easy solution would be turn off compiz fusion for these systems.

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

Please see Bug 135141 Re: Gutsy: Intel should be preferred over 810

Intel will be preferred over i810 unless there is a good reason. I
would hope that we can find a better solution to this bug than
disabling compiz.

Revision history for this message
Justin Sunseri (jmsunseri) wrote :

https://bugs.freedesktop.org/show_bug.cgi?id=10912#c21

According to this post on the fd.o site it appears as though you can't
support compositioning and support XV with XAA.

On 9/8/07, Aaron Whitehouse <email address hidden> wrote:
>
> Please see Bug 135141 Re: Gutsy: Intel should be preferred over 810
>
> Intel will be preferred over i810 unless there is a good reason. I
> would hope that we can find a better solution to this bug than
> disabling compiz.
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sincerely

Justin Sunseri

Revision history for this message
In , Denis Misiurca (eklykti) wrote :

(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

Revision history for this message
Ben Wilber (benwilber) wrote :

Unfortunately if this bug doesn't get fixed before Gutsy's released, they'll either have to disable Compiz-by-default for these users (of which there are billions) or enable it but disable Xv and just set GStreamer to use X11/No Xv rendering by default...which is slow and looks miserable. I can't see them enabling composite on Intel GMA systems with such horrible bug as "no video playback" so prevalent. I sure hope we can avoid this whole situation by getting a good fix out.

Revision history for this message
Mahdi (mahdi-hates-spam) wrote :

Well, u do not have to give up compiz-fusion nor the intel driver because of this bug nor video accell.
A good workaround is to give up only xv: install gstreamer0.10-gl, run gstreamer-properties, and on video-output select custom and insert glimagesink.
Works fine for me :)
Anyone knows any drawbacks on that? This workaround is widely used with xgl (xv crashes xgl sometimes... and using the opengl driver for video playback revents that).
This is much faster than using only the x11 driver, uses less resources and do not crash totem, mplayer or any other player.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

Drawbacks are that glimagesink is messy when moving windows under compiz. Of course, workaround does not fix other players such as xine and mplayer. However, thanks for the solution, it makes sense for gstreamer based players, it could be adopted by default. Gstreamer should test if xv works and in the opposite case it would use gl.

Revision history for this message
Mahdi (mahdi-hates-spam) wrote :

xv is also messy when moving windows under compiz and i810... maybe that is a deeper issue.

The *real* solution proposed is to use gl instead of xv to play videos while the intel driver is buggy.
Most of the popular players support that.I don't have any experience with xine, but mplayer have gl video output support (check on gmpalyer, the video output preferences... i used to use gl2 with textures and it used to work like a charm) :)

I proposed gstreamer because totem-gstreamer is default on ubuntu, and it took me a while to figure that (glimagesink does not show on the video output combo. I had to type it myself).

Since most of the users play videos fullscreen, or do not change window positions during playback (can't watch anything on a moving window! lol), I guess that would be a good default solution... if the moving windows issue becomes too problematic, then the only solution, other than fixing the intel driver, would be disabling compiz-fusion by default...

Revision history for this message
Alessandro Gervaso (gervystar) wrote :

I confirm the same bug. Worked fine with feisty instead and it has also been working for a while using gutsy.
Using glimagesink could be a temporary fix, but as already reported there are some drawbacks.

Revision history for this message
Jeff Starling (jeff-cheeber) wrote : mga driver, too

I've commented previously on this bug (https://bugs.launchpad.net/xorg-server/+bug/111257/comments/37) after I filed a similar one affecting my Feisty install and my Matrox Millenium card. As best I can tell, that card uses the mga driver.

Seems like everyone else here is having this issue with Intel hardware.

Is anyone else using the mga driver affected by this bug? Should my bug report really be marked as a dupe of this one if I'm not using the intel driver?

Revision history for this message
Franck (alci) wrote :

Well everyone seems to take granted intel driver is much better than i810... I can't see that on my system (intel 945GM/GMS/GML) : the only really noticable difference I see is that with intel driver I cannot play video !

So, isn't i810 by default with suitable xorg config to enable 3D a better solution than any other workaround ?

Revision history for this message
Paul McGarry (paul-paulmcgarry) wrote :

As the very first post mentions you won't get access to proper resolutions with the old Intel driver, at least on the i965/x3000 chipsets so it isn't a good solution for those people (including me) at least.

I think even on older chipsets it requires manual futzing with 915resolution to get access to resolutions which isn't exactly ideal.

I bought an Intel motherboard (and therefore processor) specifically because they released an open source driver and are (at least until AMD come through with the specs) the only people supporting open 3d. It is ironic that there doesn't seem to be much energy around getting the driver up to scratch, I'd have thought people would be all over it.

There used to be some regular posts from a Redhat employee on freedesktop.org who was working on getting XAA up to speed which may provide a way forward but I haven't seen anything for a while.

Revision history for this message
Paul McGarry (paul-paulmcgarry) wrote :

Sorry, "XAA" in the last comment should have read "EXA" I think.

Carl Worth was the person trying to improve it: http://cworth.org/blog/

Sorry for the spam.

Revision history for this message
Franck (alci) wrote :

Hi Paul,

I didn't experience the problems you mention regarding resolution.
But I must admit I have fairly standard 1280x800 laptop screen (widescreen however).

Revision history for this message
Michael Vogt (mvo) wrote :

I add a compiz task for this bug because it needs to be dealt with in one way or the other (fixing or blacklisting this pciid).

Changed in compiz:
status: Invalid → Confirmed
Revision history for this message
TiagoMacambira (macambira) wrote : Re: [Bug 111257] Re: totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver

On 9/12/07, Mahdi <email address hidden> wrote:
> The *real* solution proposed is to use gl instead of xv to play videos while
> the intel driver is buggy. Most of the popular players support that. I don't have
> any experience with xine, but mplayer have gl video output support (check
> on gmpalyer, the video output preferences... i used to use gl2 with textures and
> it used to work like a charm) :)

Since this bug annoys the hell out of me, I'll give my 2 cents.

While I do agree that XV should not be the default option for video
output on ubuntu gutsy (at least not on intel video cards) and that it
MUST replaced by something else, I don't think that gl would be the
best solution:

 * It does not play well with compiz (on feisty) the way plain X11 output does.

      Ok, the fact that the video window miniature doesn't show up when you
      cycle throw open windows or when you invoke the compiz's exposé can
      be a minor annoyance but is nevertheless an indication that something
      is not working as expected.

 * It does not seem to be stable.

      Perhaps this just happens to me but after selecting glimagesink on
      gstreamer-properties, if I ask it to "test" video output, CPU
usage would rise
      and top on 99% here. If I ask for a second "test", g-p would
just core dump.
      Oddly enough, plain X11 output does not top CPU usage at all
(quite the contrary)
      and works flawlessly across multiples invocations.

      (g)Mplayer seems to be more stable on with gl but only when i
use plain gl -- gl2
      w/ multiple tex. just won't work. Then again it still doesn't
play along with compiz.

 * Plain X11 just works.

      It may not be the most efficient/hyped/logical bet but it is
known to work in all
      scenarios: be it a intel driver, a i810 or any other driver for
that matter. I bet it
      even works with xgl :-)

So, unless XV is fixed or gstreamer-gl is fixed and made play well
along compiz, plain X11 is the best option available now.

Cheers.

Tiago Alves Macambira

Revision history for this message
Travis Watkins (amaranth) wrote :

Actually we're probably just going to make compiz refuse to start for these users.

Revision history for this message
Justin Sunseri (jmsunseri) wrote :

Using i810 is a much better option than not starting compiz because people
will eventually turn on desktop effects and then they will have problems. I
have been using i810 for a month now and other than having to install the
915resolution package i just don't see enough of a drawback to justify
losing either compiz or video playback. unless you want to make it so that
people can't install compiz if the intel driver is being used?

On 9/13/07, Travis Watkins <email address hidden> wrote:
>
> Actually we're probably just going to make compiz refuse to start for
> these users.
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sincerely

Justin Sunseri

Revision history for this message
Franck (alci) wrote :

Yep, I agree blacklisting intel chipset altogether is a bit overkill.

I can admit new 'intel' driver is the next big thing regarding intel chipsets, but for now it just does'nt seem to work much better than i810 in quite a few situations (this bug and a few others in xorg reporting problems with 'intel' driver).

I would advocate blacklisting 'intel' rather than intel chipsets, although I'm not sure this is possible (do you blacklist drivers or chipsets ?)

Revision history for this message
Travis Watkins (amaranth) wrote :

From what I understand not ever intel chip has this problem, only the newest two (965 and 945?). We wouldn't even blacklist the whole driver, just the cards that have this problem.

Revision history for this message
unggnu (unggnu) wrote :

i915 (VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)) has the same problem. I have read somewhere that only the older cards are effected <945 but I don't know.
I think that resolution and the other fixed i810 bugs are more important then compiz. Since intel is enabled by default compiz shouldn't be enabled after install but if some tries to activate it under Desktop Effects it tells him that the driver has to be changed or changes it itself to i810 like for Nvidia cards. Maybe a link how to fix resolution problems (i915 resolution) or at least a message box which informs about the possible penalities would be great.

Revision history for this message
starscalling (starscalling) wrote :

holler!
yeah same problem here.... sux
especially considering intell has more integrated chipsets on notebooks than either nvidia or ati...
this is critical bug.... very critical....

Revision history for this message
unggnu (unggnu) wrote :

If compiz has high priority and intel cards are nearly the only ones who work with free drivers it could be possible to choose between i810 and intel driver through resolution. All tft resolutions which are working out of the box with i810 driver get an xorg.conf with i810 driver with enabled compiz and the other ones the intel driver without compiz. The funny thing is that e.g. my uncommon resolution of 1366x768 works mostly fine with i810 driver out of the box. But I don't know if i810 behavior is for every resolution the same.
Another option would be the automatic install of i915resolution with the correct inserted tft resolution so it should work with i810 driver out of the box. But I don't know if this would work stable in one month.

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

I have an i915 and really don't know what to say about blacklisting. If I use the i810 driver, the only problem I have is that I can't go 1400x1050, however I have 1280x1024 and it's already enough on my 12'' display. On the other hand, both compiz and xv work well. On feisty, everything worked fine out-of-the-box, while on gutsy I had to manually set resolution to 96dpi, it was 75dpi and everything was too small to be usable. This is a regression of the i810 driver. In any case I believe that both disabling 3d effects and disabling Xv is unacceptable on a graphics card that can do both. Also see Bug #137225, can some of you try if you have the same segfault?

Revision history for this message
Michael Vogt (mvo) wrote :
Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

Works perfectly on my system. Playing a movie has the usual very low cpu load of Xv. Thanks a lot Michael. I suppose I _don't_ have an i915, though :) For your reference, my card is detected as follows:

00:02.0 0300: 8086:27a2 (rev 03)
00:02.1 0380: 8086:27a6 (rev 03)

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)

Revision history for this message
Tom Vetterlein (smbm) wrote :

Is this patch likely to work on the X3100? Sorry if that's a silly question.

Revision history for this message
unggnu (unggnu) wrote :

Works fine on Intel 915GM. There are the usually blue borders around menus but they don't really bother and the same happens with i810 driver.
Many thanks, now Gutsy is ready for compiz.

Revision history for this message
Justin Sunseri (jmsunseri) wrote :

1) how do you apply a debdiff?
2) do i set gstreamer back to xvimagesink?

On 9/16/07, unggnu <email address hidden> wrote:
>
> Works fine on Intel 915GM. There are the usually blue borders around menus
> but they don't really bother and the same happens with i810 driver.
> Many thanks, now Gutsy is ready for compiz.
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sincerely

Justin Sunseri

Revision history for this message
unggnu (unggnu) wrote :

@Justin Sunseri
1) https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff
2) I guess you should to test xv.

Revision history for this message
nanog (sorenimpey) wrote :

I applied the patch but video still crashes in totem and vlc irrespective of whether its xv or no xv. Works perfectly in metacity.

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)

Revision history for this message
Stephen Crosby (stevecrozz) wrote :

Applied the patch, the problem remains, here's a backtrace.

Revision history for this message
Stephen Crosby (stevecrozz) wrote : A better backtrace...

This backtrace is better, and it breaks properly at the breakpoint requested by the program's output.

Revision history for this message
Justin Sunseri (jmsunseri) wrote : Re: [Bug 111257] Re: totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver

The patch works here but i have noticed that the colors are off on all video
everything is really way too dark to see anything. i only see a few blues
and reds.

On 9/16/07, stevecrozz <email address hidden> wrote:
>
> Applied the patch, the problem remains, here's a backtrace.
>
> ** Attachment added: "totem backtrace after patch"
> http://launchpadlibrarian.net/9299398/gdb-totem.txt
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sincerely

Justin Sunseri

Revision history for this message
Stephen Crosby (stevecrozz) wrote :

Nevermind my previous comments, it appears that the patch does in fact work. Upon restart, I was able to play videos.

My hardware configuration includes the 945GM and I'm running the latest tribe of ubuntu. Hoping this patch gets into stable as soon as possible.

Revision history for this message
Michael Vogt (mvo) wrote :

Here is a final debdiff that I would like to upload tonight.

Revision history for this message
Alberto Milone (albertomilone) wrote :

@Michael Vogt

your final patch seems to solve the problem on my computer. There are only the following problems:

1) If something (e.g. a window or a menu) overlaps the video it gets blue borders (instead of Compiz's shadow) but at least the video works well. I think it's acceptable as a result.
2) if I use Totem (totem-xine) the colours of the videoclip are not right (no matter which output I choose, e.g. xv, xshm) as described in comment 78. This happens every time, no matter if the desktop effects are enabled or disabled. The videoclip works well in Kaffeine, Mplayer and Vlc though.

I hope problem 2 can be solved.

P.S. my card is detected as an Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA]) and I'm using the "intel" modesettings driver (instead of "i810") on Gutsy

Revision history for this message
Michael Vogt (mvo) wrote :

compiz (1:0.5.2+git20070918-0ubuntu1) gutsy; urgency=low

  * new 0.6 snapshot
    - remember system beep setting from gnome (LP: #132804)
    - fix auto-raise for transient parents
    - drawer and clock windows no longer go under (LP: #131050)
  * debian/compiz.wrapper:
    - do not start compiz on i965 as video does not work
      there under compiz (LP: #111257)
    - use printf instead of echo (thanks to Kristian Lyngstøl)
    - be more compatible with oldish shells (LP: #131484)
  * debian/patches/013-add-cursor-theme-support.patch:
    - updated to fix conflicts against the latest git

 -- Michael Vogt <email address hidden> Tue, 18 Sep 2007 18:25:18 +0100

Changed in compiz:
status: Confirmed → Fix Released
Revision history for this message
Alberto Milone (albertomilone) wrote :

@Michael
does this mean that we don't need to apply your debdiff to the intel driver and that the new compiz is enough?

Revision history for this message
Alberto Milone (albertomilone) wrote :

Never mind

Revision history for this message
Alessandro Gervaso (gervystar) wrote :

I can confirm that the updated driver works on my systems.
The only remaining issue is that when moving a window while playing a video (xv) the image isn't updated until the window is still again.

Revision history for this message
In , unggnu (unggnu) wrote :

It has been fixed in Ubuntu Gutsy with overlay. If someone is interested: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/111257

Revision history for this message
Michael Vogt (mvo) wrote :

I uploaded the new driver yesterday so this issue should be fixed now. Thanks everybody who helped getting this fixed :)

Changed in xserver-xorg-video-intel:
assignee: nobody → mvo
status: Confirmed → Fix Released
Revision history for this message
Tom Vetterlein (smbm) wrote :

Just out of interest, what is it that has to fixed to fully support the i965? It seems like a lot of systems are going to be affected (T61, R61 new Dells etc (some Apple hardware too??? not sure about that)).

Revision history for this message
Tom Vetterlein (smbm) wrote :
Revision history for this message
In , Bastien Nocera (hadess-deactivatedaccount) wrote :

(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.

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Note that it affects other video apps too -- gxine and vlc.

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

On Thinkpad T61, Intel X3000, with Rawhide x86_64 installed:

Subjectively, turning on EXA seems to slow down scrolling in Firefox a bit, but
glxgears shows the same level of performance, so it might just be me. But it
does let me use compositing and Xv at the same time (i.e. watching videos under
Compiz).

Without EXA, even playing a sound file would crash Totem with the default
settings (visualization is turned on by default).

Should system-config-display automatically turn on EXA for some whitelisted list
of system configurations?

Revision history for this message
In , Safari-ml-freedesktop-bugzilla-kv7oy2vp4mc4jvudr6vccb7oetrzzqe7fwnhahno (safari-ml-freedesktop-bugzilla-kv7oy2vp4mc4jvudr6vccb7oetrzzqe7fwnhahno) wrote :

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)

Revision history for this message
In , Gordon Jin (gordon-jin) wrote :

>> And where did my "video overlay" go?

overlay is not supported on i965.

Revision history for this message
In , Safari-ml-freedesktop-bugzilla-kv7oy2vp4mc4jvudr6vccb7oetrzzqe7fwnhahno (safari-ml-freedesktop-bugzilla-kv7oy2vp4mc4jvudr6vccb7oetrzzqe7fwnhahno) wrote :

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.

Revision history for this message
In , Daniel Stone (daniels) wrote :

(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.

Revision history for this message
danda (dan-osc) wrote :

I'd like to know what is going on with regards to the 965 also. Does anyone know if intel is working on resolving this? I took a cursory look in the git repository at freedesktop.org, and I don't see any recent mods that look relevant. As a T61 owner, it is quite annoying to have to choose between compiz and video playback.

Revision history for this message
Wade Menard (wade-ezri) wrote :

danda: as has been explained earlier in this bug, the fix for i965 is getting EXA support up to speed, something that will slowly happen. Carl worth has been doing some great work that you can follow at http://cworth.org/tag/exa/

Discussion about that is beyond the scope of this bug (BadAlloc crashes) and discussion should be continued on the wiki or forums and not here.

Revision history for this message
unggnu (unggnu) wrote :

"The patch works here but i have noticed that the colors are off on all video
everything is really way too dark to see anything. i only see a few blues
and reds."
I can confirm this. This only happens with the new intel driver under xv. X11 output and i810 driver haven't this problem.

Revision history for this message
unggnu (unggnu) wrote :

This color bug seems to be Totem and intel driver related. If I play after X start a video file with vlc oder Mplayer colors are normal but I play a file with Totem colors are very dark and nearly without colors. After playing a video with Totem all other xv players have the same problem until X restart so it seems that Totem changes a gamma value or something like that.

Revision history for this message
Wade Menard (wade-ezri) wrote :

unggnu: is this an upgrade or a new install? You can adujust the contrast and saturation settings in Totem's preferences.

Please open a new bug for this.

Revision history for this message
unggnu (unggnu) wrote :

I have made a new install and I am pretty sure that I haven't restored totem settings or the whole gconf directory but resetting totem works and it works on Beta Live CD out of the box too. There will be a bug report I guess but it is not needed.

Revision history for this message
radicaledward (radicaledward) wrote :

I am getting this problem on my 965GM even when I am not running compiz. Any help? I have the latest everything on gutsy tribe 5.

Revision history for this message
Marcus Granado (mrc-gran) wrote :

@radicaledward: If you are willing to turn compiz off, you can use EXA with x3100 to play accelerated videos so that xine,mplayer,totem etc all work (at least it works for me in an Inspiron 1720):
Just add 'Option "accelmethod" "exa"' in your xorg.conf's gm965 Device section. Make sure all other options but DRI are commented out, since exa does not currently like e.g. pageflip, cacheline and other options. e.g.
Section "Device"
        Identifier "Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller"
        Driver "intel"
        BusID "PCI:0:2:0"
        Option "DRI" "true"
        Option "AccelMethod" "exa"
EndSection

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Correction -- video performance *is* still terrible.

Revision history for this message
Dom H (speedsix) wrote :

When people say i965 is this reffering to the GM965 chipset? So I'm guessing this patch doesn't allow you to run XV video with the X3100 gpu?

Revision history for this message
In , Michel-tungstengraphics (michel-tungstengraphics) wrote :

*** Bug 12527 has been marked as a duplicate of this bug. ***

Revision history for this message
Thom Pischke (thom-pischke) wrote :

I have the GM965 chipset with x3100 GPU (Dell Intel 1420n). Neither compiz nor video works on gutsy. Compiz refuses to start and video crashes on any player with the Same BadAlloc mentioned here. Haven't tried any of the fixes here, but there seemed to be a lack of responses from people with this chipset, so adding my experiences.

Revision history for this message
Thom Pischke (thom-pischke) wrote :

Tested with No XV. Video still broken, though the 'Test' button works ok. So as far as I can tell, video is completely broken for the x3100 in gutsy, with no workaround available.

Revision history for this message
Dom H (speedsix) wrote :

Video works fine on my X3100 aslong as compiz is disabled. Compiz only works if I comment out the blacklist section in /usr/bin/compiz.

Revision history for this message
unggnu (unggnu) wrote :

GMA965 and X3100 have no overlay support so XV wouldn't work with compiz. That's why compiz is blacklisted.

Revision history for this message
Thom Pischke (thom-pischke) wrote :

I don't have compiz enabled (still blacklisted), and still no video. Even turning of XV doesn't help so the problem seems to be something else.

Revision history for this message
unggnu (unggnu) wrote :

Could you recheck it with the Gutsy RC Live CD? Maybe some settings are wrong or something like that.

Revision history for this message
Thom Pischke (thom-pischke) wrote : Re: [Bug 111257] Re: totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver

good idea... will try that when i have time. I did try a script I
found in a forum thread that was supposed to allow compiz to run.
Don't know if video worked before that or not, but compiz still
doesn't work. It's possible the script messed up some settings.

On 10/15/07, unggnu <email address hidden> wrote:
> Could you recheck it with the Gutsy RC Live CD? Maybe some settings are
> wrong or something like that.
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Thom Pischke (thom-pischke) wrote :

Ok, tried this with the gutsy RC Live CD and video played fine, meaning I have a messed-up configuration. I suppose I'll just wait until the official release and do a fresh install, unless someone wants to walk me through troubleshooting my configuration.

Revision history for this message
Oxenfrogga (tlatlik) wrote :

Hi Thom,

maybe you have xserver-xgl installed? I had it installed and I simply did not know (probably I just forgot) -- and searched really REALLY long for the reason for my crashes with glxgears and the damned slow display.

Isn't there a way to keep Intel users away from that package?

Ciao,
Harald

Revision history for this message
Thom Pischke (thom-pischke) wrote :

Thanks for the help. I think I've pinpointed the source of the problem. I had set the CacheLines parameter in my xorg.conf as part of a tutorial for a dual monitor setup. Also had the PageFlip parameter set. Both of these seem to be big no-nos for video playback with the intel card.

Removed them and can now play video. Using AccelMethod EXA also works if CacheLines if these parms are not set.

In short, I just removed all the nonstandard configuration options in the card's device section and that took care of things. Hopefully dual monitor will still work ok. Will find out tomorrow.

Revision history for this message
In , Dave (dave-redhat-bugs) wrote :

*** Bug 237169 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Dave (dave-redhat-bugs) wrote :

Can F8 users test the latest tree with XAA video should at least play..

Revision history for this message
In , Bastien (bastien-redhat-bugs) wrote :

(In reply to comment #32)
> Can F8 users test the latest tree with XAA video should at least play..

Works using xorg-x11-drv-i810-2.1.1-7.fc8, but it's just about as slow as using EXA.

Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

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.

Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

*** Bug 12647 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

*** Bug 9930 has been marked as a duplicate of this bug. ***

Revision history for this message
samstre (samuel-streiner) wrote :

I've got the same problem. I'm using Gutsy (final) on a HP 6720s laptop (intel X3100). Compiz is disabled by default and cannot be enabled (without removing the blacklist check). My machine doesn't play videos at all. It doesent matter whether i try using Mplayer, Totem or VLC. Mplayer crashes when i try to open a video (Error opening/initializing the selected video_out (-vo) device. I tried it with -vo xv, -vo x11 and -vo gl2 ...

I neither have CacheLines nor PageFlip activated in my xorg.conf.

Revision history for this message
samstre (samuel-streiner) wrote :

sorry for the spam...

here's my xorg.conf

Revision history for this message
In , Vang (vang-redhat-bugs) wrote :

Created attachment 279371
Compiz + VLC = lag and bad video

maybe it's a compiz problem?

Revision history for this message
kieran (daralantarial) wrote :

if you're using EXA, try setting FBTexPercent to '0' in your xorg.conf.
this fixed it for me, using radeon/gutsy/exa and metacity with the compositor. i can use xvimagesink in totem no problems now.

Revision history for this message
In , Michael Fu (michael-fu-intel) wrote :

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.

Changed in xorg-server:
status: Confirmed → Won't Fix
Revision history for this message
nucc1 (nucc1) wrote :

Will someone be so kind as to describe the relationship between this bug you're looking at, and #193777 ? https://bugs.launchpad.net/ubuntu/+source/totem/+bug/193777

Obviously, this one refers to people using Compiz, and Intel Hardware, and the crash is a "Badalloc..."

My hardware is ATI, and I am not using compiz (the ATI drivers in stock Ubuntu gutsy don't support compiz).

A certain person keeps closing this bug as invalid, and has now revoked my rights to edit the same bug. As I speak, totem is still unusable. This is unnerving to say the least.

Revision history for this message
Justin Sunseri (jmsunseri) wrote : Re: [Bug 111257] Re: totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver

fanen i think you are suffering from something else. The bug 99% of us
reported here has been resolved.

On Sat, Feb 23, 2008 at 12:42 AM, fanen <email address hidden> wrote:

> Will someone be so kind as to describe the relationship between this bug
> you're looking at, and #193777 ?
> https://bugs.launchpad.net/ubuntu/+source/totem/+bug/193777
>
> Obviously, this one refers to people using Compiz, and Intel Hardware,
> and the crash is a "Badalloc..."
>
> My hardware is ATI, and I am not using compiz (the ATI drivers in stock
> Ubuntu gutsy don't support compiz).
>
> A certain person keeps closing this bug as invalid, and has now revoked
> my rights to edit the same bug. As I speak, totem is still unusable.
> This is unnerving to say the least.
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sincerely

Justin Sunseri

Revision history for this message
nucc1 (nucc1) wrote :

Justin, would you be so kind as to head over to #193777 ( https://bugs.launchpad.net/ubuntu/+source/totem/+bug/193777 ) and explain this to Pedro? He has closed the bug report, marking it as invalid, and revoked my rights to edit that bug.

Revision history for this message
Justin Sunseri (jmsunseri) wrote :

It appears as thought someone has opened it up

On Sat, Feb 23, 2008 at 3:12 AM, fanen <email address hidden> wrote:

> Justin, would you be so kind as to head over to #193777 (
> https://bugs.launchpad.net/ubuntu/+source/totem/+bug/193777 ) and
> explain this to Pedro? He has closed the bug report, marking it as
> invalid, and revoked my rights to edit that bug.
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sincerely

Justin Sunseri

Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Revision history for this message
In , Charles (charles-redhat-bugs) wrote :

*** Bug 440262 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Charles (charles-redhat-bugs) wrote :

I can confirm that this still happens with F9 rawhide latest with these packages:

kernel-2.6.25-0.185.rc7.git6.fc9.x86_64
xorg-x11-drv-i810-2.2.1-19.fc9.x86_64
xorg-x11-server-common-1.4.99.901-16.20080401.fc9.x86_64
xorg-x11-server-Xorg-1.4.99.901-16.20080401.fc9.x86_64

I have this problem even without compiz on a ThinkPad T61 with Intel GM965 chip.

Revision history for this message
In , Boyan (boyan-redhat-bugs) wrote :

(In reply to comment #36)
> *** Bug 440262 has been marked as a duplicate of this bug. ***

Ok, it appears now Xv is not working not only with Compiz which is my case
#440262.

But the difference is that I didn't have such problems with Xorg from
December 2007/January 2008:

xorg-x11-server-Xorg-1.3.0.0-39.fc8.i386
xorg-x11-drv-i810-2.1.1-7.fc8.i386

In fact Xv was working great with "intel" driver even with high definition
video files with 1920x1080 resolution.
At this point the new Xorg 1.4 appeared in rawhide.
My latest check with newer drivers was around February, but can't find
exact version as of this time. The problem then was that with EXA which was
chosen as default is very slow. Changing to XAA resulted to distorted fonts
in terminals but the video was playable with Xv. Then I switched back to older
version.
As of one-two weeks ago I changed Xorg to the latest in rawhide again and
noticed the problem which I've reported here as bug #440262.
The problem is somewhere in the updates from the last 1-2 months, not as
with #239125 a year ago.

Revision history for this message
In , Bill (bill-redhat-bugs) wrote :

*** Bug 438361 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

*** Bug 441647 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Vitaly (vitaly-redhat-bugs) wrote :

Seeing the same here with latest rawhide and
Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)

X11 is the only option to play anything. No compiz, same with compositing
enabled and disabled in metacity.

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

*** Bug 441777 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Adam (adam-redhat-bugs) wrote :

Directed here as my bug was marked as a duplicate. In my case I'm using
metacity and the problem has appeared in the past week or so.

Revision history for this message
In , David (david-redhat-bugs) wrote :

Same here on a Fujitsu Lifebook using mplayer. It spits out endless
BadAlloc errors and nothing appears in the video output.

This is with metacity.

Intel Corporation Mobile 915GM/GMS/910GML (rev 04)

xorg.conf is using driver "intel"

It would be nice to hear that some Xorg developer has tried to use xv
with the current packages in fedora rawhide, and either had success or
can reproduce the problem.

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

The fun thing is, this used to work up to the last two weeks or so (on a 945GM,
intel driver). Now it does not, and I have not found out what package caused the
breakage.

Xine, for example, works fine with Xv. vlc does not.

Revision history for this message
In , David (david-redhat-bugs) wrote :

Building and installing the latest driver posted by intel:

http://lists.freedesktop.org/archives/xorg/2008-April/034668.html

Makes the problem go away completely for me.

I can't believe I'm the first person, either as bug reporter or
owner, to try this.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

Hi, I am having this issue as well. Here's my testing for normal-res and low-res
video in totem-gstreamer, gxine, xine, mplayer and vlc, with plain metacity,
with compositing manager enabled in metacity, I'll attach Xorg.0.log and xorg.conf.

plain metacity:

programme 720x384, 23.976 fps 320x239, 30.000 fps
totem-gstreamer plays, but displays error plays
gxine SEGFAULTs SEGFAULTs
xine SEGFAULTs plays
mplayer only audio only audio
vlc crash -

Displayed errors/warnings on cosole:
totem:
No accelerated IMDCT transform found

mplayer:
X11 error: BadAlloc (insufficient resources for operation)

vlc:
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 140 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 86
  Current serial number in output stream: 87
Segmentation fault

Metacity with compositing:
nothing works, showed errors:
Totem:
The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.

mplayer:
X11 error: BadAlloc (insufficient resources for operation)

vlc:
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 140 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 86
  Current serial number in output stream: 87
Segmentation fault

xine:
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 140 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 2342
  Current serial number in output stream: 2343

x11 and gl2 video output drivers work (slow, and with compositing enabled gl2
also with rendering issues) both with and without compositing.

I've noticed this bug on upstream bugzilla which seems to be similar:
https://bugs.freedesktop.org/show_bug.cgi?id=2772

I'll try the latest driver (as suggested by davem) to see if it's better and
report the results.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

Created attachment 302372
My Xorg.0.log when testing in totem, gxine, xine, vlc and mplayer

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

Created attachment 302373
my xorg.conf

There is one option added in the xorg.conf manualy which was suggested on
test-list as possible fix (with no luck).

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

Oh, and I forgot the package versions...

xorg-x11-server-Xorg-1.4.99.901-21.20080407.fc9.i386
xorg-x11-drv-i810-2.2.1-20.fc9.i386

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

(In reply to comment #46)

> I can't believe I'm the first person, either as bug reporter or
> owner, to try this.

I can't get this to build, configure craps out on me saying
./configure: line 20451: syntax error near unexpected token `XINERAMA,'
./configure: line 20451: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)'

Revision history for this message
In , Ralf (ralf-redhat-bugs) wrote :

Naked driver, btw, no patches ported from the rawhide driver, following the
.spec instructions manually.

Revision history for this message
In , Bill (bill-redhat-bugs) wrote :

I wouldn't worry about upstream vs. RH build, this is almost certainly just
using EXA vs XAA. (check your logs.)

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

I've just rebased rawhide rpm to the new version and it builds OK (but I need to
update the %%file section). I'll post a srpm when it's done.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

Ok, as promised, here's the SPRM:

http://mso.fedorapeople.org/rawhide/xorg-x11-drv-i810-2.2.99.903-0.1.fc9.src.rpm

The changes are: removed patch 6,7 and 10 (seems they were just backports from
git), edited patch 5, added libIntelXvMC.so* libs.

I have yet to test, whether it works...

Revision history for this message
In , David (david-redhat-bugs) wrote :

My config is using EXA.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

The update to 2.2.99.903 didn't solved the problem, but I noticed that XAA was
used. So I switched to EXA, which makes videos playable in mplayer with -vo xv
again, but HD (720p) is being quickly desynced with sound (and enabling
framedropping does not help)...

Revision history for this message
In , David (david-redhat-bugs) wrote :

This is still broken in the default Fedora-9-Preview install, and adding:

      Option "AccelMethod" "EXA"

to xorg.conf fixes it.

Revision history for this message
In , Bill (bill-redhat-bugs) wrote :

Please test xorg-x11-drv-i810-2.2.1-21.fc9, available at:
  http://koji.fedoraproject.org/packages/xorg-x11-drv-i810/2.2.1/21.fc9/

and in tomorrow's rawhide.

Revision history for this message
In , Bill (bill-redhat-bugs) wrote :

I'll note that this build fixes it for me.

Revision history for this message
In , Charles (charles-redhat-bugs) wrote :

2.2.1-21.fc9 fixes Xv for me.

Revision history for this message
In , Charles (charles-redhat-bugs) wrote :

BTW, I'm still having this exact same problem with radeon. Does the same fix to
i810 apply to radeon?

Revision history for this message
In , Bill (bill-redhat-bugs) wrote :

Not that I know of. You can always try frobbing the config option, of course.

Revision history for this message
In , Adam (adam-redhat-bugs) wrote :

xorg-x11-drv-i810-2.2.1-22.fc9 also contains a fix for the XAA case, so overlay
video should work no matter what now (although obviously it won't blend
correctly when compositing).

Tested on i865, closing.

Revision history for this message
In , Valent (valent-redhat-bugs) wrote :
Download full text (4.1 KiB)

Hi,
I have some high-def video trailers I downloaded via azureus and I
can't play them on F9 Preview (with all codecs installed).

I have been running Rawhide for some time now and when I saw this bug
I thought it could be something I did so I did a clean install of F9
Preview and installed fluendo codecs for totem, and also installed vlc
and mplayer (with codecs) from livna.

None player can play these mkv files that I can play without any
problems under Fedora 8 with all of mentioned video players.

I have Intel graphic chip:
Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated
Graphics Controller (rev 03)

To reproduce this bug do this:
1. yum install azureus
2. start azureus
3. download some high-def video trailer (Iron Man for example)
4. install video player + codecs (vlc, mplayer, totem + fluendo codecs
- take your pick)
5. play high-def video

I get these errors:

$ totem IronManTrailer2-1080p.mkv
** Message: Error: File
"/usr/lib/gstreamer-0.10/libmch264dec.so.7.4.0.20778" could not be
used.
fluh264dec.c(414): gst_fluh264dec_setup (): /play/decodebin0/fluh264dec0:
Could not open module: libstdc++.so.5: cannot open shared object file:
No such file or directory

(totem:9953): GStreamer-CRITICAL **: gst_object_unref: assertion
`object != NULL' failed

(totem:9953): GStreamer-CRITICAL **: gst_object_unref: assertion
`object != NULL' failed

(totem:9953): GStreamer-CRITICAL **: gst_object_unref: assertion
`object != NULL' failed

$ mplayer IronManTrailer2-1080p.mkv
MPlayer SVN-r25979 rpm.livna.org (C) 2000-2007 MPlayer Team
CPU: Intel(R) Core(TM) Duo CPU T2450 @ 2.00GHz (Family: 6,
Model: 14, Stepping: 12)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing IronManTrailer2-1080p.mkv.
[mkv] Track ID 1: video (V_MPEG4/ISO/AVC), -vid 0
[mkv] Track ID 2: audio (A_VORBIS), -aid 0, -alang und
[mkv] Will play video track 1.
Matroska file format detected.
VIDEO: [avc1] 1920x816 24bpp 23.952 fps 0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->192000)
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis decoder)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 1920 x 816 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 2.35:1 - prescaling to correct movie aspect.
VO: [xv] 1920x816 => 1920x816 Planar YV12
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warni...

Read more...

Revision history for this message
In , Valent (valent-redhat-bugs) wrote :

I just added this to my xorg.conf:

Option "AccelMethod" "EXA"

I'll report how it works now after reboot or X restart.

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

Bug 445395 may be related.

Revision history for this message
Fabián Rodríguez (magicfab) wrote :

Here is a summary of the workaround mentioned before the bug was fixed:

1) Open a terminal window (Applications > Accessories > Terminal)
2) Enable the Multimedia Systems Selector menu option:
a) Go to System > Preferences > Main Menu
b) Under "Menus:" scroll down to and click "Preferences". The right part under "Items;" will update itself
c) Mark the "Multimedia System Selector" checkbox, click "Close"
3) Go to System > Preferences >Multimedia System Selector"
4) Under the "Video" tab change the Default output plugin to "X Window System (no XV)"
5) Click "Test", you should see a window popup with a series of vertical color bars, much as older classic TV color tests
6) Click "OK" to finish the test, now mpeg playback should work.

Revision history for this message
hanzhaogang (hanzhaogang) wrote :

i used the method intorduced in the summary above.
but the error still there...

i wonder why.

i use mplayer.

anybody help.

Revision history for this message
Randy Wilson (blazerw) wrote :

Using Intrepid with the intel driver on a laptop with 915GM I still get this bug. The workaround to not use Xv works, but with the high CPU usage. Should this bug still be occurring in Intrepid?

Changed in xorg-server:
importance: Unknown → High
Changed in xorg-server:
importance: High → Unknown
Changed in xorg-server:
importance: Unknown → High
Changed in fedora:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.