totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
X.Org X server |
Won't Fix
|
High
|
|||
Fedora |
Fix Released
|
Medium
|
|||
compiz (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
xserver-xorg-video-intel (Ubuntu) |
Fix Released
|
High
|
Michael Vogt | ||
Bug Description
Hi
I have a widescreen monitor (1440x900) and in order to use it in feisty (x86) I've installed the xserver-
As said I'm using feisty x86 up to date on a intel x3000 video card.
thanks
Related branches
mon (javiermon-deactivatedaccount) wrote : | #1 |
mon (javiermon-deactivatedaccount) wrote : | #2 |
mon (javiermon-deactivatedaccount) wrote : | #3 |
description: | updated |
hey560 (hey560) wrote : | #4 |
I can confirm this bug. It is an XV issue i think.
Changed in totem: | |
status: | Unconfirmed → Confirmed |
Niels Breet (maemo) wrote : | #5 |
I'm having these problems too. Feisty x86 on Intel GMA 3000.
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #152 |
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.
In Red Hat Bugzilla #239125, Bastien (bastien-redhat-bugs) wrote : | #153 |
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.
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #154 |
Trying to watch this: http://
$ 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.)
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #155 |
Oh, and yes, all the debuginfo packages are installed.
In Red Hat Bugzilla #239125, Bastien (bastien-redhat-bugs) wrote : | #156 |
You need to run it under gdb, and break on gdk_x_error(), as per the error message.
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #157 |
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/
/usr/lib/
Using host libthread_db library "/lib/libthread
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. :-/
In Red Hat Bugzilla #239125, Bastien (bastien-redhat-bugs) wrote : | #158 |
> 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=
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #159 |
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-
(gdb) file /usr/bin/totem
Reading symbols from /usr/bin/
/usr/lib/
Using host libthread_db library "/lib/libthread
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.
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #160 |
Created attachment 154367
Backtrace from this crash
In Red Hat Bugzilla #239125, Bastien (bastien-redhat-bugs) wrote : | #161 |
Looks like this bug I filed some time ago:
http://
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-
xvimagesink
shows the same problem.
In Red Hat Bugzilla #239125, Bastien (bastien-redhat-bugs) wrote : | #162 |
Note that xvimagesimagesink will try to use double-buffering by default, which
will limit the amount of memory really available for Xv. See:
http://
about making it configurable/a property (so that we can switch it off for testing)
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #163 |
$ 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
ButtonRelea
ExposureMask StructureNotifyMask SubstructureNot
Substructur
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
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #164 |
Created attachment 154440
Full xdpyinfo output, just in case you want it
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #165 |
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-
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
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #166 |
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.)
In Red Hat Bugzilla #239125, Bastien (bastien-redhat-bugs) wrote : | #167 |
My upstream report was also with this same driver, reassigning to the xorg driver.
In freedesktop.org Bugzilla #10912, David Schleef (dschleef) wrote : | #6 |
+++ This bug was initially created as a clone of Bug #2772 +++
As mentioned in #2772, this problem persists with the i810 driver.
See also:
In freedesktop.org Bugzilla #10912, Eric Anholt (eric-anholt) wrote : | #7 |
Xorg.0.log, server, and driver version.
John B. (jbuncher) wrote : | #8 |
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.
mon (javiermon-deactivatedaccount) wrote : | #10 |
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.
Baggie (hyperpiper) wrote : | #11 |
Same here - playing mp3/flac/ video all cause totem to crash when compiz is enabled
mon (javiermon-deactivatedaccount) wrote : | #12 |
Baggie, the crash while playing audio is caused because you have visualizations turned on.
In freedesktop.org Bugzilla #10912, David Schleef (dschleef) wrote : | #13 |
Created an attachment (id=9977)
Xorg.0.log
version:
1.7.4-0ubuntu1
In freedesktop.org Bugzilla #10912, Eric Anholt (eric-anholt) wrote : | #14 |
Already fixed.
In freedesktop.org Bugzilla #10912, Bastien Nocera (hadess-deactivatedaccount) wrote : | #15 |
Eric, which version would that be fixed in?
Luca Rosellini (luca-rosellini) wrote : | #16 |
Same problem here on an intel 915GM, both totem (using gstreamer backend) and mplayer crash receiving the X11 error: "BadAlloc (insufficient resources for operation)"
In freedesktop.org Bugzilla #10912, Eric Anholt (eric-anholt) wrote : | #17 |
xf86-video-intel 2.0
In freedesktop.org Bugzilla #10912, Bastien Nocera (hadess-deactivatedaccount) wrote : | #18 |
I'm using xorg-x11-
In Red Hat Bugzilla #239125, Bastien (bastien-redhat-bugs) wrote : | #168 |
See also:
https:/
It works fine for me with xorg-x11-
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.
In freedesktop.org Bugzilla #10912, Eric Anholt (eric-anholt) wrote : | #19 |
compiz shouldn't be able to affect this. You're just running compiz on xorg, not compiz on xgl on xorg, right?
In freedesktop.org Bugzilla #10912, Bastien Nocera (hadess-deactivatedaccount) wrote : | #20 |
No GLX, it's a plain Fedora 7 install. Let me know if you would need to be able to debug this.
welktach (welktach) wrote : | #21 |
I have the same issue with using the xserver-
Jan Niklas Hasse (jhasse) wrote : | #22 |
Here's a fix which worked for me: http://
Luca Rosellini (luca-rosellini) wrote : | #23 |
the fix linked by jhasse doesn't work for me on an intel 915GM
welktach (welktach) wrote : | #24 |
I have an Intel 950GM and the fix also does not work for me.
mon (javiermon-deactivatedaccount) wrote : | #25 |
Doesn't work here.
Intel x3000
Albert Abril (abrilc) wrote : | #26 |
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/
won't help unless you provide this information when reporting a possible bug.
Regards.
In freedesktop.org Bugzilla #10912, MA (mariusa) wrote : | #27 |
Same here, xorg-x11-
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)
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 | #28 |
@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-
not the xserver-
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/
> 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-
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
Albert Abril (abrilc) wrote : | #29 |
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-
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-
> not the xserver-
> 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/
> 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-
> > https:/
> > 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-
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
In Red Hat Bugzilla #239125, Matěj (matj-redhat-bugs) wrote : | #169 |
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/
file (/var/log/
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.
In freedesktop.org Bugzilla #10912, Ian Wienand (ianw) wrote : | #30 |
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-
Section "Device"
Identifier "Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller"
Driver "intel"
BusID "PCI:0:2:0"
Option "UseFBDev" "true"
Option "XAANoOffscreen
Option "DRI" "true"
EndSection
Section "Extensions"
Option "Composite" "true"
EndSection
Also seems to be reported by ubuntians
https:/
In freedesktop.org Bugzilla #10912, Michel-tungstengraphics (michel-tungstengraphics) wrote : | #31 |
(In reply to comment #10)
> Option "XAANoOffscreen
Does it happen without this option? (Fedora might still be using the hack to disable XAA offscreen pixmaps when starting a GLX compositing manager)
In freedesktop.org Bugzilla #10912, Ian Wienand (ianw) wrote : | #32 |
> 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.
In freedesktop.org Bugzilla #10912, Eric Anholt (eric-anholt) wrote : | #33 |
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.
SickNick (sicknick2020) wrote : | #34 |
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??
mon (javiermon-deactivatedaccount) wrote : | #35 |
you can try an set a different video sync in gstreamer. I think the command is gstreamer-
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 | #36 |
Fine! It worked for me!!
Confirmed: the command is gsreamer-
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-
> home.
>
>
mon (javiermon-deactivatedaccount) wrote : | #37 |
Hi
It only works for gstreamer based player (so it doesn't work with totem-xine either).
In freedesktop.org Bugzilla #10912, Mikael Gerdin (mgerdin) wrote : | #38 |
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-
Changed in xorg-server: | |
status: | Unknown → Confirmed |
In freedesktop.org Bugzilla #10912, Shirakawasuna (shirakawasuna) wrote : | #39 |
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.
Jeffrey Knockel (jeff250) wrote : | #40 |
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.
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 | #41 |
I have the same problem, my video card is Intel Corporation Mobile 945GM/GMS/940GML with the driver xserver-
Yesterday i install compiz fusion but is the same problem
In freedesktop.org Bugzilla #10912, unggnu (unggnu) wrote : | #42 |
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.
unggnu (unggnu) wrote : | #43 |
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.
Balaji (balaji-ramasubramanian) wrote : | #44 |
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.
Bryce Harrington (bryce) wrote : | #45 |
Moving to compiz package
priit (priit-ohlo) wrote : | #46 |
Confirmed on Fujitsu-Siemens S7020 with Intel's i915
Doesn't work with xserver-
mon (javiermon-deactivatedaccount) wrote : | #47 |
Hi
I've tested new package from x's maintainer and the bug persists:
http://
In Red Hat Bugzilla #239125, Matěj (matj-redhat-bugs) wrote : | #170 |
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.
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #171 |
Created attachment 159134
my xorg.conf
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #172 |
Created attachment 159135
Xorg.0.log - using my xorg.conf (which only uses one edit from the default)
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #173 |
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
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #174 |
Created attachment 159138
Xorg.0.log when using a xorg.conf created solely from system-
In Red Hat Bugzilla #239125, Jens (jens-redhat-bugs) wrote : | #175 |
The problem still occurs under the xorg.conf created solely from
system-
In freedesktop.org Bugzilla #10912, Paul McGarry (paul-paulmcgarry) wrote : | #48 |
Also seeing the issue with 965 chipset on Ubuntu Gutsy (tribe3) with xserver-
In freedesktop.org Bugzilla #10912, Bastien Nocera (hadess-deactivatedaccount) wrote : | #49 |
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.
In Red Hat Bugzilla #239125, Bastien (bastien-redhat-bugs) wrote : | #176 |
I posted an explanation of what happens at:
https:/
The performance of EXA is sub-par though when playing movies, but at least it
doesn't crash anymore.
Ben Wilber (benwilber) wrote : | #50 |
This is a dupe of this bug: https:/
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.
Travis Watkins (amaranth) wrote : | #51 |
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 |
Travis Watkins (amaranth) wrote : | #52 |
Err, _that_ one is a limitation of the Xv implementation in the intel driver.
unggnu (unggnu) wrote : | #53 |
Still present in Tribe 4. Please try to fix this or at least disable compiz for Intel cards.
Burt (albertus-wilson) wrote : | #54 |
Have the same problem on my Intel Desktop board D946GZIS using Gutsy Tribe 4
http://
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
Juan Pablo Salazar Bertín (snifer) wrote : | #55 |
Confirmed by a lot of people and upstream.
Changed in xserver-xorg-video-intel: | |
status: | New → Confirmed |
Jeff Starling (jeff-cheeber) wrote : | #56 |
I'm getting the same BadAlloc errors with feisty and a Matrox Millenium G450 card. I filed a bug, https:/
Finally, should this bug be affecting me?
In freedesktop.org Bugzilla #10912, Juan Pablo Salazar Bertín (snifer) wrote : | #57 |
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).
In Red Hat Bugzilla #239125, Matěj (matj-redhat-bugs) wrote : | #177 |
*** Bug 243760 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #239125, Matěj (matj-redhat-bugs) wrote : | #178 |
A lot of information and logs is in bug 2437ž0.
In Red Hat Bugzilla #239125, Matěj (matj-redhat-bugs) wrote : | #179 |
*** Bug 240956 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #10912, Eric Anholt (eric-anholt) wrote : | #58 |
*** Bug 11643 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #10912, Jack Malmostoso (malmostoso) wrote : | #59 |
(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://
Thanks!
Götz Christ (g-christ) wrote : | #60 |
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.
nvadekar (nvadekar) wrote : | #61 |
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?
Mahdi (mahdi-hates-spam) wrote : | #62 |
Xv crashes the apps using intel driver with gma950 (i915). Works fine with i810 driver though.
I'm running an un-to-date gutsy.
Tom Vetterlein (smbm) wrote : | #63 |
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 |
Justin Sunseri (jmsunseri) wrote : | #64 |
- gdb-gst-prop.txt Edit (9.6 KiB, text/plain)
Just wanted to add a backtrace of gstreamer-
Gdk-ERROR **: The program 'gstreamer-
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'. ...
unggnu (unggnu) wrote : | #65 |
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:/
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 | #66 |
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:/
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Sincerely
Justin Sunseri
Travis Watkins (amaranth) wrote : | #67 |
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.
nanog (sorenimpey) wrote : | #68 |
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.
Aaron Whitehouse (aaron-whitehouse) wrote : | #69 |
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.
Justin Sunseri (jmsunseri) wrote : | #70 |
https:/
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-
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Sincerely
Justin Sunseri
In freedesktop.org Bugzilla #10912, Denis Misiurca (eklykti) wrote : | #71 |
(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/
Gentoo Linux x86
x11-libs/
x11-base/
x11-drivers/
also affects x11-drivers/
DOES NOT affects x11-drivers/
media-libs/
tried also media-libs/
Composite enabled, kwin komposite enabled, NO beryl or compyz
Ben Wilber (benwilber) wrote : | #72 |
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.
Mahdi (mahdi-hates-spam) wrote : | #73 |
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-
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.
Vincenzo Ciancia (vincenzo-ml) wrote : | #74 |
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.
Mahdi (mahdi-hates-spam) wrote : | #75 |
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...
Alessandro Gervaso (gervystar) wrote : | #76 |
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.
Jeff Starling (jeff-cheeber) wrote : mga driver, too | #77 |
I've commented previously on this bug (https:/
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?
Franck (alci) wrote : | #78 |
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 ?
Paul McGarry (paul-paulmcgarry) wrote : | #79 |
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.
Paul McGarry (paul-paulmcgarry) wrote : | #80 |
Sorry, "XAA" in the last comment should have read "EXA" I think.
Carl Worth was the person trying to improve it: http://
Sorry for the spam.
Franck (alci) wrote : | #81 |
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).
Michael Vogt (mvo) wrote : | #82 |
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 |
TiagoMacambira (macambira) wrote : Re: [Bug 111257] Re: totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver | #83 |
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
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/
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
Travis Watkins (amaranth) wrote : | #84 |
Actually we're probably just going to make compiz refuse to start for these users.
Justin Sunseri (jmsunseri) wrote : | #85 |
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-
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Sincerely
Justin Sunseri
Franck (alci) wrote : | #86 |
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 ?)
Travis Watkins (amaranth) wrote : | #87 |
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.
unggnu (unggnu) wrote : | #88 |
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.
starscalling (starscalling) wrote : | #89 |
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....
unggnu (unggnu) wrote : | #90 |
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.
Vincenzo Ciancia (vincenzo-ml) wrote : | #91 |
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?
Michael Vogt (mvo) wrote : | #92 |
Vincenzo Ciancia (vincenzo-ml) wrote : | #93 |
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)
Tom Vetterlein (smbm) wrote : | #94 |
Is this patch likely to work on the X3100? Sorry if that's a silly question.
unggnu (unggnu) wrote : | #95 |
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.
Justin Sunseri (jmsunseri) wrote : | #96 |
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-
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Sincerely
Justin Sunseri
unggnu (unggnu) wrote : | #97 |
@Justin Sunseri
1) https:/
2) I guess you should to test xv.
nanog (sorenimpey) wrote : | #98 |
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)
Stephen Crosby (stevecrozz) wrote : | #99 |
- totem backtrace after patch Edit (15.2 KiB, text/plain)
Applied the patch, the problem remains, here's a backtrace.
Stephen Crosby (stevecrozz) wrote : A better backtrace... | #100 |
- Better backtrace Edit (15.9 KiB, text/plain)
This backtrace is better, and it breaks properly at the breakpoint requested by the program's output.
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 | #101 |
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://
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Sincerely
Justin Sunseri
Stephen Crosby (stevecrozz) wrote : | #102 |
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.
Michael Vogt (mvo) wrote : | #103 |
- Final debdiff Edit (2.3 KiB, text/plain)
Here is a final debdiff that I would like to upload tonight.
Alberto Milone (albertomilone) wrote : | #104 |
@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
Michael Vogt (mvo) wrote : | #105 |
compiz (1:0.5.
* 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/
- 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/
- 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 |
Alberto Milone (albertomilone) wrote : | #106 |
@Michael
does this mean that we don't need to apply your debdiff to the intel driver and that the new compiz is enough?
Alberto Milone (albertomilone) wrote : | #107 |
Never mind
Alessandro Gervaso (gervystar) wrote : | #108 |
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.
In freedesktop.org Bugzilla #10912, unggnu (unggnu) wrote : | #109 |
It has been fixed in Ubuntu Gutsy with overlay. If someone is interested: https:/
Michael Vogt (mvo) wrote : | #110 |
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 |
Tom Vetterlein (smbm) wrote : | #111 |
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)).
Tom Vetterlein (smbm) wrote : | #112 |
Not to worry, I found this
In freedesktop.org Bugzilla #10912, Bastien Nocera (hadess-deactivatedaccount) wrote : | #113 |
(In reply to comment #23)
> It has been fixed in Ubuntu Gutsy with overlay. If someone is interested:
> https:/
That doesn't work on my system, even forcing the textured overlay.
In Red Hat Bugzilla #239125, Michel (michel-redhat-bugs) wrote : | #180 |
Note that it affects other video apps too -- gxine and vlc.
In Red Hat Bugzilla #239125, Michel (michel-redhat-bugs) wrote : | #181 |
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-
of system configurations?
In freedesktop.org Bugzilla #10912, Safari-ml-freedesktop-bugzilla-kv7oy2vp4mc4jvudr6vccb7oetrzzqe7fwnhahno (safari-ml-freedesktop-bugzilla-kv7oy2vp4mc4jvudr6vccb7oetrzzqe7fwnhahno) wrote : | #114 |
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_CONTRAST" (range 0 to 255)
maximum XvImage size: 1920 x 1088
Number of image formats: 4
id: 0x32595559 (YUY2)
guid: 59555932-
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (YV12)
guid: 59563132-
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x30323449 (I420)
guid: 49343230-
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x59565955 (UYVY)
guid: 55595659-
bits per pixel: 16
number of planes: 1
type: YUV (packed)
In freedesktop.org Bugzilla #10912, Gordon Jin (gordon-jin) wrote : | #115 |
>> And where did my "video overlay" go?
overlay is not supported on i965.
In freedesktop.org Bugzilla #10912, Safari-ml-freedesktop-bugzilla-kv7oy2vp4mc4jvudr6vccb7oetrzzqe7fwnhahno (safari-ml-freedesktop-bugzilla-kv7oy2vp4mc4jvudr6vccb7oetrzzqe7fwnhahno) wrote : | #116 |
I have had enough with this "stable" 1.4.
I went back to Fedora's 1.3.0.0-24 x86_64 Xorg and i810.
xvideo works. Keyboard leds work (except scroll lock).
At least somebody has quality control.
In freedesktop.org Bugzilla #10912, Daniel Stone (daniels) wrote : | #117 |
(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.
danda (dan-osc) wrote : | #118 |
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.
Wade Menard (wade-ezri) wrote : | #119 |
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://
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.
unggnu (unggnu) wrote : | #120 |
"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.
unggnu (unggnu) wrote : | #121 |
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.
Wade Menard (wade-ezri) wrote : | #122 |
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.
unggnu (unggnu) wrote : | #123 |
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.
radicaledward (radicaledward) wrote : | #124 |
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.
Marcus Granado (mrc-gran) wrote : | #125 |
@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
In Red Hat Bugzilla #239125, Michel (michel-redhat-bugs) wrote : | #182 |
Correction -- video performance *is* still terrible.
Dom H (speedsix) wrote : | #126 |
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?
In freedesktop.org Bugzilla #10912, Michel-tungstengraphics (michel-tungstengraphics) wrote : | #127 |
*** Bug 12527 has been marked as a duplicate of this bug. ***
Thom Pischke (thom-pischke) wrote : | #128 |
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.
Thom Pischke (thom-pischke) wrote : | #129 |
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.
Dom H (speedsix) wrote : | #130 |
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.
unggnu (unggnu) wrote : | #131 |
GMA965 and X3100 have no overlay support so XV wouldn't work with compiz. That's why compiz is blacklisted.
Thom Pischke (thom-pischke) wrote : | #132 |
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.
unggnu (unggnu) wrote : | #133 |
Could you recheck it with the Gutsy RC Live CD? Maybe some settings are wrong or something like that.
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 | #134 |
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-
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
Thom Pischke (thom-pischke) wrote : | #135 |
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.
Oxenfrogga (tlatlik) wrote : | #136 |
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
Thom Pischke (thom-pischke) wrote : | #137 |
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.
In Red Hat Bugzilla #239125, Dave (dave-redhat-bugs) wrote : | #183 |
*** Bug 237169 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #239125, Dave (dave-redhat-bugs) wrote : | #184 |
Can F8 users test the latest tree with XAA video should at least play..
In Red Hat Bugzilla #239125, Bastien (bastien-redhat-bugs) wrote : | #185 |
(In reply to comment #32)
> Can F8 users test the latest tree with XAA video should at least play..
Works using xorg-x11-
In freedesktop.org Bugzilla #10912, Jesse Barnes (jbarnes-virtuousgeek) wrote : | #138 |
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.
In freedesktop.org Bugzilla #10912, Jesse Barnes (jbarnes-virtuousgeek) wrote : | #139 |
*** Bug 12647 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #10912, Eric Anholt (eric-anholt) wrote : | #140 |
*** Bug 9930 has been marked as a duplicate of this bug. ***
samstre (samuel-streiner) wrote : | #141 |
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/
I neither have CacheLines nor PageFlip activated in my xorg.conf.
samstre (samuel-streiner) wrote : | #142 |
In Red Hat Bugzilla #239125, Vang (vang-redhat-bugs) wrote : | #186 |
Created attachment 279371
Compiz + VLC = lag and bad video
maybe it's a compiz problem?
kieran (daralantarial) wrote : | #143 |
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.
In freedesktop.org Bugzilla #10912, Michael Fu (michael-fu-intel) wrote : | #144 |
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 |
nucc1 (nucc1) wrote : | #145 |
Will someone be so kind as to describe the relationship between this bug you're looking at, and #193777 ? https:/
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.
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 | #146 |
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:/
>
> 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-
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Sincerely
Justin Sunseri
nucc1 (nucc1) wrote : | #147 |
Justin, would you be so kind as to head over to #193777 ( https:/
Justin Sunseri (jmsunseri) wrote : | #148 |
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:/
> 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-
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Sincerely
Justin Sunseri
In Red Hat Bugzilla #239125, Bug (bug-redhat-bugs) wrote : | #187 |
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://
We will be following the process here:
http://
doesn't happen again.
In Red Hat Bugzilla #239125, Charles (charles-redhat-bugs) wrote : | #188 |
*** Bug 440262 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #239125, Charles (charles-redhat-bugs) wrote : | #189 |
I can confirm that this still happens with F9 rawhide latest with these packages:
kernel-
xorg-x11-
xorg-x11-
xorg-x11-
I have this problem even without compiz on a ThinkPad T61 with Intel GM965 chip.
In Red Hat Bugzilla #239125, Boyan (boyan-redhat-bugs) wrote : | #190 |
(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-
xorg-x11-
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.
In Red Hat Bugzilla #239125, Bill (bill-redhat-bugs) wrote : | #191 |
*** Bug 438361 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #239125, Matěj (matj-redhat-bugs) wrote : | #192 |
*** Bug 441647 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #239125, Vitaly (vitaly-redhat-bugs) wrote : | #193 |
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.
In Red Hat Bugzilla #239125, Matěj (matj-redhat-bugs) wrote : | #194 |
*** Bug 441777 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #239125, Adam (adam-redhat-bugs) wrote : | #195 |
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.
In Red Hat Bugzilla #239125, David (david-redhat-bugs) wrote : | #196 |
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.
In Red Hat Bugzilla #239125, Ralf (ralf-redhat-bugs) wrote : | #197 |
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.
In Red Hat Bugzilla #239125, David (david-redhat-bugs) wrote : | #198 |
Building and installing the latest driver posted by intel:
http://
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.
In Red Hat Bugzilla #239125, Martin (martin-redhat-bugs) wrote : | #199 |
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:/
I'll try the latest driver (as suggested by davem) to see if it's better and
report the results.
In Red Hat Bugzilla #239125, Martin (martin-redhat-bugs) wrote : | #200 |
Created attachment 302372
My Xorg.0.log when testing in totem, gxine, xine, vlc and mplayer
In Red Hat Bugzilla #239125, Martin (martin-redhat-bugs) wrote : | #201 |
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).
In Red Hat Bugzilla #239125, Martin (martin-redhat-bugs) wrote : | #202 |
Oh, and I forgot the package versions...
xorg-x11-
xorg-x11-
In Red Hat Bugzilla #239125, Ralf (ralf-redhat-bugs) wrote : | #203 |
(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_
In Red Hat Bugzilla #239125, Ralf (ralf-redhat-bugs) wrote : | #204 |
Naked driver, btw, no patches ported from the rawhide driver, following the
.spec instructions manually.
In Red Hat Bugzilla #239125, Bill (bill-redhat-bugs) wrote : | #205 |
I wouldn't worry about upstream vs. RH build, this is almost certainly just
using EXA vs XAA. (check your logs.)
In Red Hat Bugzilla #239125, Martin (martin-redhat-bugs) wrote : | #206 |
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.
In Red Hat Bugzilla #239125, Martin (martin-redhat-bugs) wrote : | #207 |
Ok, as promised, here's the SPRM:
http://
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...
In Red Hat Bugzilla #239125, David (david-redhat-bugs) wrote : | #208 |
My config is using EXA.
In Red Hat Bugzilla #239125, Martin (martin-redhat-bugs) wrote : | #209 |
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)...
In Red Hat Bugzilla #239125, David (david-redhat-bugs) wrote : | #210 |
This is still broken in the default Fedora-9-Preview install, and adding:
Option "AccelMethod" "EXA"
to xorg.conf fixes it.
In Red Hat Bugzilla #239125, Bill (bill-redhat-bugs) wrote : | #211 |
Please test xorg-x11-
http://
and in tomorrow's rawhide.
In Red Hat Bugzilla #239125, Bill (bill-redhat-bugs) wrote : | #212 |
I'll note that this build fixes it for me.
In Red Hat Bugzilla #239125, Charles (charles-redhat-bugs) wrote : | #213 |
2.2.1-21.fc9 fixes Xv for me.
In Red Hat Bugzilla #239125, Charles (charles-redhat-bugs) wrote : | #214 |
BTW, I'm still having this exact same problem with radeon. Does the same fix to
i810 apply to radeon?
In Red Hat Bugzilla #239125, Bill (bill-redhat-bugs) wrote : | #215 |
Not that I know of. You can always try frobbing the config option, of course.
In Red Hat Bugzilla #239125, Adam (adam-redhat-bugs) wrote : | #216 |
xorg-x11-
video should work no matter what now (although obviously it won't blend
correctly when compositing).
Tested on i865, closing.
In Red Hat Bugzilla #239125, Valent (valent-redhat-bugs) wrote : | #217 |
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
** Message: Error: File
"/usr/lib/
used.
fluh264dec.c(414): gst_fluh264dec_
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
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
[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...
In Red Hat Bugzilla #239125, Valent (valent-redhat-bugs) wrote : | #218 |
I just added this to my xorg.conf:
Option "AccelMethod" "EXA"
I'll report how it works now after reboot or X restart.
In Red Hat Bugzilla #239125, Matěj (matj-redhat-bugs) wrote : | #219 |
Bug 445395 may be related.
Fabián Rodríguez (magicfab) wrote : | #149 |
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.
hanzhaogang (hanzhaogang) wrote : | #150 |
i used the method intorduced in the summary above.
but the error still there...
i wonder why.
i use mplayer.
anybody help.
Randy Wilson (blazerw) wrote : | #151 |
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 |
This is a sample that makes totem crash: http:// david.navi. cx/blog/ wp-content/ uploads/ 2006/03/ leaftag- gimmie. avi