After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 93861 - [0.6.2] gst-compprep needs X display to run
[0.6.2] gst-compprep needs X display to run
Status: RESOLVED DUPLICATE of bug 109069
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.6.x
Other other
: Normal normal
: 0.6.2
Assigned To: Thomas Vander Stichele
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-09-22 05:44 UTC by David Schleef
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description David Schleef 2002-09-22 05:44:42 UTC 
gst-compprep tries to open an X display while running.  Since it's
primarily an administration tool, this isn't cool.
Comment 1 Thomas Vander Stichele 2002-09-23 05:02:14 UTC 
Hm, we used to have that for gst-register as well.  It was xvideosink
querying for it's capabilities I think.

Does it actually present a problem ? Segfault, something else ?
Comment 2 David I. Lehn 2002-12-04 02:55:58 UTC 
No segfault but it is a headache for the Debian package maintainer. 
People see the "open display failed!" and report bugs.  That message
should be supressed during gst-compprep for sure.  But during
application runtime that is a important error message that should be
propagated to the user.  How?  I have no idea.

Please reopen this bug.
Comment 3 David I. Lehn 2002-12-12 09:55:17 UTC 
Added fix to CVS that should supress the annoying printing.  Can
probably close this now.
Comment 4 David I. Lehn 2003-01-21 01:04:10 UTC 
Ok, so I didn't fully fix it.  No more "open display failed" messages
but xvideosink and video sink can still print out this while running
gst-compprep:

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

Ideally this would be supressed for gst-compprep and properly reported
to the application when used as a regular plugin.
Comment 5 Benjamin Otte (Company) 2003-04-16 14:27:15 UTC 
Is this still happening?
Because we fixed xvideosink for 0.6.1 to net query the X display upon 
plugin initialization to make gst-register work. (Bug 105256)
Comment 6 Benjamin Otte (Company) 2003-05-07 23:53:44 UTC 
Ok, the real fix is in HEAD now, see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gstreamer/gst-plugins/sys/xvideo/xvideosink.c.diff?r1=1.38&r2=1.39

Problem is that gst-compprep creates elements of each type and
xvideosink tried to initialize an X connection before going to READY.
Comment 7 Christian Fredrik Kalager Schaller 2003-05-12 14:44:04 UTC 
Assigning to thomasvs for merge to 0.6 branch
Comment 8 Ronald Bultje 2003-05-13 13:06:30 UTC 
benjamin, I don't see how the above patch changes the location where
the X connection is opened...?
Comment 9 Benjamin Otte (Company) 2003-05-14 15:01:51 UTC 
line 169++ in _class_init calls gst_xvideosink_get_pad_template_caps.

That function opens (and closes afterwards) an X connection.
Comment 10 Ronald Bultje 2003-05-17 13:05:35 UTC 
I've got a backport of the HEAD xvideosink code in #109069, pending to
be applied into 0.6.2. Let's continue discussion there, it includes
this fix too.

*** This bug has been marked as a duplicate of 109069 ***