Red Hat Bugzilla – Bug 373191
gnome-terminal will not start using xinerama
Last modified: 2009-10-22 08:44:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/20071019 Fedora/22.214.171.124-1.fc7 Firefox/126.96.36.199
Description of problem:
trying to start gnome-terminal on my multihead workstation results in gnome-terminal not starting.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install FC6 or later on a multihead desktop or workstation
2. log in as any user using gnome
3. choose "terminal" from the System Tools sub-menu
gnome-terminal does not start
gnome-terminal would start
here is the out put after trying to start gnome-terminal from konsole
Gdk-ERROR **: The program 'gnome-terminal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 107 error_code 2 request_code 78 minor_code 0)
(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.)
gnome-terminal: xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
Given that this is also a problem on pre-xcb systems, I'm going to rule out the
lock assertion for the moment. request_code is 78, which is XCreateColormap, so
that narrows down our search a bit?
What does 'xdpyinfo' print on this machine? There's only like two places in the
CreateColormap path that can throw BadValue, and one of them is introduced in
the Xinerama code and looks really bogus. It's basically:
if(!stuff->visual || (stuff->visual > 255))
which seems like it shouldn't be tripped, ever.
Created attachment 256071 [details]
Here is the output of xdpyinfo.
Created attachment 256081 [details]
I know mentioned it in talking to you on IRC but noticed it is missing here,
this machine does use the nvidia drivers packaged by Livna and has a quad head
visual id: 0x30a
depth: 32 planes
Way cool. That's the Composite synthetic visual, and obviously its VID is >255,
so the Xinerama code is just refusing to touch it. Tee hee. And according to
the protocol, CreateColormap should basically never throw BadValue, so it's not
surprising that gtk's error handler isn't DTRTing.
I'm making an F8 scratch build now with that check removed, as far as I can tell
it's just broken. I'll post a link when it's finished.
I have a (mostly complete) fix for this, want to land it for F9.
This should be resolved as of 188.8.131.52-0.23.