Problems with XOrg-R7.4
S Andreason
sandreas41 at gmail.com
Tue Nov 4 07:38:52 PST 2008
OK, I've managed to build and install XOrg-R7.4, "upgrading" from
XOrg-R7.0, but I've observed a number of problems with it. If
these problems can be fixed, or you can suggest additional tests
or changes I could make to help you find and fix the problems,
I'd appreciate it. :)
This message should have two Xorg log files (one from XOrg-R7.0
and one from XOrg-R7.4), a build log for R7.4, a copy of the
build-from-tarballs.sh script I used to build R7.4, the xorg.conf
files I'm using (one from R7.0, one from R7.4), one problematic
program's output (including an "ldd" run on the executable under
the conditions it runs in and gdb's backtrace from running it),
and a number of screenshots illustrating some of these problems
attached (where possible). I include these to help you in
tracking down and understanding the problems I'm bringing up...
and in the hope that you'll be able to help me with them.
The /usr/X11R6 directory I was building into didn't exist when
I started the build script, and the build log was slightly post-
processed while it was being created by a Perl script that was
watching for "Building"..."module component" lines to add in
timestamps. That Perl script was also responsible for recording
the command line I used... and, actually, for storing the build
log at all.
Please don't complain about the versions of various software I
tested against, or suggest that I upgrade. In some of these
cases, I actually already have upgraded packages, but I don't
always use them for a variety of reasons (for example, I patched
the version I'm using [in a way that certainly didn't cause the
problem under XOrg R7.0], and I may not have found my record of
just what and how I patched it yet... or the old diff may not
apply to newer versions). In some cases, I've already retrieved
the most current versions available. Some of these programs
have no newer versions (i.e. precompiled binaries, no source).
I (generally :) ) really do have reasons for which particular
software and versions I'm running and testing.
Some of the problems I list are no longer "active" concerns; I
simply wanted to let you know that I encountered the problem, and
what solution I found (and, where possible, where I found it).
In one case, I still have an "active" concern mentioned (the
error messages that finally helped me find a solution weren't
being displayed under normal circumstances) that I still think
should be fixed, if possible, if only to make identifying that
problem easier if anyone else runs into it in a different
program.
Finally, if you make suggestions or pose questions, either e-mail
them to me or don't expect an immediate response. I'll try to
check this mailing list regularly, but: I'm not perfect; I don't
really want to wade through every message from this list pouring
into my mail box (though I'll browse through them just the same
via the web-available archives... the "by threads" listing of
messages is quite nice); I tend to take a while trying to work
out how to say things... in the cause of being as clear as
possible :) ..... and, finally, it appears the web access to the
archives at http://lists.freedesktop.org/archives/*/* is somewhat
messed up, and that'll probably slow me down a little as I look
for your responses.
-----------------------------------------------------------------
Actually, let's hit the list archives problem first. Has anyone
here actually tried using Google search to find messages about
problems they're looking for solutions to? It appears that (as
of October 11, 2008, when my search led to messages from March
2008) the links Google presents are nearly always to the wrong
message(s). Is the archive software renumbering existing
messages for every new message sent to the list, or is there some
other reason for this...?
-----------------------------------------------------------------
I suppose I should complain about building the X server first.
(Start at the beginning, and all that.)
First, I was not exactly happy to discover that the
"xkeyboard-config-1.4" (optional?) component requires "intltool"
be installed, regardless of if it's configure script was passed
--disable-nls or not. I had to patch intltool to make it work on
this system (not all versions of Perl 5 make mkdir()'s MODE
argument optional, and I already have the newest Perl 5 version
installed that doesn't cause severe [data-corrupting] errors in a
LOT of software on my system), which didn't make me much
happier... but intltool's not your problem. xkeyboard-config,
on the other hand...
Second, I truly wish that I had known that the xorg-server
component required that I had openssl installed. I didn't see
this dependency noted on the web site, and XOrg-R7.0 certainly
didn't require it.
-----------------------------------------------------------------
Next on my list, starting the X server. Under XOrg R7.1, R7.2,
and R7.3, my system would always freeze solid while starting the
X server upon (based on my study of the logs) loading the DRI
module. And, try though I might with "Disable" and all, the X
server under those versions absolutely insisted on loading that
module anyway. For some strange reason, this made it rather
difficult to use those versions...
Fortunately, XOrg R7.4 isn't freezing with the DRI module
disabled in my configuration file, but it appears that the X
server is ignoring my direction and loading a DRI module
anyway...?
(WW) "dri" will not be loaded unless you've specified it to be
loaded elsewhere.
(II) "dri" will be loaded even though the default is to disable
it.
(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable
(II) AIGLX: Loaded and initialized
/usr/X11R6/lib/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0
Since it's not freezing, I'm not really complaining (well, not
much, anyway), but...
-----------------------------------------------------------------
On the subject of starting the X server, here's another "What!?"
moment. According to the xorg.conf.5 manual page,
When this entry is not specified in the config file, the server
falls back to the compiled-in default font path, which contains
This (strongly) implies that, should I include font paths in my
config file, the server shouldn't use its compiled-in default
font path. Regardless, during server startup, my log shows such
gems as:
Could not init font path element /usr/X11R6/lib/X11/fonts/TTF/,
removing from list!
Could not init font path element /usr/X11R6/lib/X11/fonts/Type1/,
removing from list!
Could not init font path element /usr/X11R6/lib/X11/fonts/100dpi/,
removing from list!
Could not init font path element /usr/X11R6/lib/X11/fonts/75dpi/,
removing from list!
These aren't in my config file. Why is the server trying to use
them?
-----------------------------------------------------------------
Moving right along, my window manager allows me to set windows to
be borderless. However, when I select a window (or several
windows), the window manager increases the border width to 1 and
sets its border color to white. Similarly, it reduces such
windows' border widths back to 0 when they are unselected.
Unfortunately, the behavior under XOrg R7.4 differs from that
under XOrg R7.0. The appearance under XOrg R7.4 is... "less
desirable". The top and left-side lines are doubled in width,
and actually enter the window itself.
The attached "border-R74.xwd.bz2" is an xwd dump of the root
window after this error has occurred under XOrg R7.4.
The attached "border-R70.xwd.bz2" is an xwd dump of the root
window after the same selection, but under XOrg R7.0.
Turning off the Composite extension (as described below) has no
effect on this display oddity.
I'll note that the "error" root window dump actually ISN'T
exactly what I see on the screen in this case. In reality, there
is an extra, 1 pixel tall white line below the window, and the
single pixel that appears to be popping up above the window on
the right-hand side is actually the right edge of a line that
continues straight to the left of it to the left edge of the
white line just below it.
-----------------------------------------------------------------
While I'm already noting differences between what xwd captures
and what actually appears on the screen, here's another one.
I was switching between "pages" (i.e. the window manager was
hiding all windows on the present "page" and then unhiding all
windows on the page I was switching to) when I noticed a
redrawing error... or so it appeared. One of my windows
(imlib_config, if it matters) only partially redrew, and a window
on the page I had just left was still visible in its place.
However, xwd captured the proper image of the window that was
supposed to be there.
This was repeatable -- I switched back and forth between the
pages a few times -- but I have no idea what caused it to happen.
The page I was coming from had 4 windows open in various
positions, and the page I was moving to had 4 other windows open
in different positions. At first, the area actually redrawn was
the same; but, after a few (about a half dozen) switches, the
redrawn area started to vary. Eventually, it stopped making the
mistake. All I did was to switch pages and try to get xwd shots
of the problem...
If it helps, the window that displayed the problem was owned by
imlib_config, which was using gtk 1.2.10.
I haven't seen this problem since. Of course, since I have only
been running the new X server just long enough to check if I've
found a solution to one of the problems further below or not, I
haven't really been providing it with any opportunities to mess
up this way again since...
Further, I've since patched gtk 1.2.10 to make it work properly
(i.e. start some programs without crashing) in the presence of
an active Composite extension... so I suppose it's possible that
the absence of a compositing manager, plus some trouble between
gtk 1.2.10 and ARGB visuals, was responsible for this?
-----------------------------------------------------------------
Speaking (well, writing) of Compositing and Imlib, I use a
modified version of Eterm 0.8.10 for my terminals under X. And
one thing I like about it is the ability to set the background
to an image... and then shade and tint it.
This works fine under XOrg 7.0, and its "transparency" mode,
including shading and tinting, works properly under XOrg 7.4, but
it failed to display any selected background images, with or
without tinting, under XOrg 7.4 (instead displaying a black
background). No errors were displayed anywhere I could find.
By experimenting with imlib_config (thus precipitating the
display anomaly described above), I discovered that Eterm would
report errors only when imlib's MIT-SHM option was turned off
(though it would fail in any case).
Eterm: XError in function XChangeWindowAttributes
(request 2.0): BadMatch (invalid parameter attributes)
(error 8)
Eterm: XError in function XCopyArea (request 62.0): BadMatch
(invalid parameter attributes) (error 8)
I'd like to know why the errors were only displayed with MIT-SHM
off...
By searching the web, I discovered that other people using imlib
have also encountered this error. One example:
http://bugs.kde.org/show_bug.cgi?id=89313
One solution listed was to ensure that each window created used
the "DefaultVisual" function/macro instead of copying its visual
from its parent. I searched Eterm's source and made this change
to every window creation I could find... and it didn't work.
Fortunately, the backup plan (setting the XLIB_SKIP_ARGB_VISUALS
environmental variable) works properly, and my local version of
Eterm 0.8.10 (plus patches) putenv's it before calling
XOpenDisplay and unsetenv's it in the subprocess created to
contain the shell run inside the terminal.
-----------------------------------------------------------------
Continuing with Compositing-related problems (as it turned out),
but moving from imlib to gtk 1.2.10, I use a modified version of
gimp 1.2.3, which uses gtk 1.2 (of which I have version 1.2.10,
which appears to be the newest release).
When I started gimp-1.2 (though not gimp-2.2, which I also have
installed) under XOrg 7.4, a (black and white?) version of its
icon flashed onto the screen for a moment and then vanished, with
an error message:
Gdk-ERROR **: BadMatch (invalid parameter attributes)
serial 1285 error_code 8 request_code 62 minor_code 0
This was followed by a stack trace generated by libxcb --
something about a locking error.
A search for the locking error revealed two things -- a patch for
libxcb and libX11 to eliminate this problem and speed up xlib-
style programs at the same time; and discussion about an
environmental variable that lets programs continue despite
locking errors.
I couldn't get the patch to apply/compile, so that solution was
out. (If you're wondering, "make" insisted on changing into my
home directory and re-running "make" there for some unknown
reason.)
So I tried the LIBXCB_ALLOW_SLOPPY_LOCK environmental variable.
The outcome wasn't very impressive -- it didn't get any further.
By searching further, I discovered that the Composite extension,
and ARGB visuals, might be responsible for the problem. However,
the references I found said that the Composite extension was also
responsible for crashing Heroes of Might and Magic 3 (the port by
Loki to Linux)... but, when I tested it, it worked as well... as
it ever seems to, at least.
Still, I added the following section to my xorg.conf file
(temporarily) to see if turning off the Composite extension would
solve the problem:
Section "Extensions"
Option "Composite" "Disabled"
EndSection
It did. Other searches (related to the imlib problem) revealed
that the problem might be "ARGB visuals", so I searched for
anything about gtk 1.2.x and ARGB visuals. As a result, I found
a set of patches for gtk 1.2.10 at:
http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/gtk%2B/
One of the patches handles ARGB visuals by setting the
"XLIB_SKIP_ARGB_VISUALS" environmental variable before opening
the display. I applied all the patches at that location and
recompiled and reinstalled gtk 1.2.10 (plus patches), and tested
gimp-1.2 again... and it works properly now.
Thus, this problem is "solved". (Hopefully, the above
information will be of use to someone else with the same
problem.)
-----------------------------------------------------------------
Although it appears that X feels much faster now, and it appears
that I can play movies much better now :) , I have noticed a
small annoyance. Whenever I start a movie with MPlayer or run
SDL_image's "showimage" sample program, the screen blinks
(completely black) for a moment. Similarly, the screen also
blinks when MPlayer exits (but not when "showimage" exits).
I have to guess that this is related to the XVideo extension,
but it also happens if I start "showimage" while MPlayer is
already playing a movie, or when I start playing another movie
with another instance of MPlayer while another movie is still
running. This is only a slight annoyance, though -- each blink
lasts for less than half a second.
-----------------------------------------------------------------
And now, the last of the problems I've encountered: the
show-stopping, head-scratching, just plain WEIRD one that I just
can't seem to get to work or figure out what I could try to do
next with. Yes... the old "netscape" program.
Although I use Mozilla Seamonkey for most of my browsing needs,
I still need to be able to run the old "netscape" program.
As of XOrg 7.0, I could no longer run the glibc versions of
netscape 4.7 or 4.8 (which use the system libraries), but the
linux2.0 versions of netscape 4.6 and 4.61 work fine, though
using them has required the use of old versions of the X
libraries... and copies of libc.so.5 and libm.so.5 and friends.
The script sets LD_LIBRARY_PATH, MOZILLA_HOME, and XKEYSYMDB.
Unfortunately, no version of netscape from 4.6 to 4.8 that I've
managed to get (linux2.0 versions of 4.6 and 4.61; glibc versions
of 4.7 and 4.8) work under XOrg 7.4. I've tried to find a glibc
version of 4.61, but the only copy I've found doesn't download;
my requests to ftp://archive.netscape.com/... time out.
Perhaps it's possible to compile the X libraries in such a way
that they'll use libc.so.5 and friends and it'll work again.
Perhaps there's some way to create X .so libraries that are,
themselves, statically linked (at least as far as libc and libm
are concerned, so they don't try to pull in libc.so.6 or
libm.so.6 to the run-time linking). Unfortunately, I have no
idea how I'd do either of these to try them... Help?
> cd /usr/local/netscape-4.6
> objdump -p netscape | grep NEEDED
NEEDED libXt.so.6
NEEDED libSM.so.6
NEEDED libICE.so.6
NEEDED libXmu.so.6
NEEDED libXpm.so.4
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libdl.so.1
NEEDED libc.so.5
NEEDED libg++.so.27
NEEDED libstdc++.so.27
NEEDED libm.so.5
Running under XOrg 7.0, netscape 4.6 simply runs, with no output
to its standard error or standard output.
Running under XOrg 7.4, netscape 4.6 displays what appears to be
a warning message, and then reports a "Bus error" and exits. The
attached file "netscape-4.6-error" includes both the error
message received when run without gdb, and also the result of
a run under gdb 6.4, including a backtrace. The libraries
provided to netscape are:
32168 Feb 23 1998 libm.so.5.0.9*
81937 Apr 3 1998 libXpm.so.4.11*
394044 May 15 1998 libstdc++.so.2.8.0*
5796 May 30 1998 libdl.so.1.9.9*
906000 Jun 5 1998 libXm.so.1.2.0*
614840 Oct 5 1998 libc.so.5.4.46*
761265 Jan 4 2000 libX11.so.6.1*
48070 Jan 4 2000 libXext.so.6.3*
35187 Jan 4 2000 libSM.so.6.0*
86160 Jan 4 2000 libICE.so.6.3*
310664 Jan 4 2000 libXt.so.6.0*
85481 Jan 4 2000 libXmu.so.6.0*
13 Jul 3 09:30 libICE.so.6 -> libICE.so.6.3*
13 Jul 3 09:30 libICE.so -> libICE.so.6.3*
12 Jul 3 09:31 libXt.so.6 -> libXt.so.6.0*
12 Jul 3 09:31 libXt.so -> libXt.so.6.0*
16 Jul 3 09:32 libg++.so.27 -> libstdc++.so.2.8*
18 Jul 3 09:32 libstdc++.so.2.8 -> libstdc++.so.2.8.0*
16 Jul 3 09:32 libstdc++.so.27 -> libstdc++.so.2.8*
12 Jul 3 09:33 libSM.so.6 -> libSM.so.6.0*
12 Jul 3 09:33 libSM.so -> libSM.so.6.0*
13 Jul 3 09:33 libXmu.so.6 -> libXmu.so.6.0*
13 Jul 3 09:33 libXmu.so -> libXmu.so.6.0*
14 Jul 3 09:34 libXpm.so.4 -> libXpm.so.4.11*
14 Jul 3 09:34 libXpm.so -> libXpm.so.4.11*
14 Jul 3 09:34 libXext.so.6 -> libXext.so.6.3*
14 Jul 3 09:34 libXext.so -> libXext.so.6.3*
13 Jul 3 09:34 libX11.so.6 -> libX11.so.6.1*
13 Jul 3 09:34 libX11.so -> libX11.so.6.1*
14 Jul 3 09:35 libdl.so.1 -> libdl.so.1.9.9*
14 Jul 3 09:35 libc.so.5 -> libc.so.5.4.46*
13 Jul 3 09:35 libm.so.5 -> libm.so.5.0.9*
14 Jul 3 09:35 libXm.so.1 -> libXm.so.1.2.0*
14 Jul 3 09:35 libXm.so -> libXm.so.1.2.0*
14 Jul 3 09:36 libXm.so.1.2 -> libXm.so.1.2.0*
Netscape 4.61 for linux 2.0 uses the same set of libraries, and
crashes with the same backtrace.
The environmental variables "XLIB_SKIP_ARGB_VISUALS" and
"LIBXCB_ALLOW_SLOPPY_LOCK" make no difference to the result...
maybe because the X libraries being used ARE so old.
(Although I find it interesting that Heroes of Might and Magic 3,
the original, just-installed-from-CD, statically linked version,
_did_ run.)
Turning off the Composite extension has no effect on this
problem.
For the record, netscape 4.7 and 4.8 (glibc versions) crash the
same way under XOrg 7.0 as under XOrg 7.4, and so (especially
given the result) I have no hope of getting them to work:
> netscape-4.8
Segmentation fault
> netscape-4.8-gdb
GNU gdb 6.4
[ ... ]
(gdb) run
Starting program: /usr/local/netscape-4.8/netscape
(no debugging symbols found)
Program received signal SIGSEGV, Segmentation fault.
0x0893fa2f in PR_Start ()
(gdb) bt
#0 0x0893fa2f in PR_Start ()
#1 0x00000020 in ?? ()
Previous frame inner to this frame (corrupt stack?)
-----------------------------------------------------------------
Last, but not least, I'd like to congratulate you on your
accomplishments with XOrg 7.4:
* Unlike 7.1 through 7.3, it no longer freezes while starting
up (that DRI module problem).
* It seems to start up much faster.
(Under XOrg 7.0, my background can take up to 15 seconds to
load; under XOrg 7.4, it's done in less than 5 seconds.)
I'd like to congratulate you on more, but I'm not going to be
using it enough to say more until the problems I've presented
above are all fixed. :|
If you've read this far, thank you! I hope to read some
suggestions and solutions from you soon.
-- Steven Andreason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build-from-tarballs.sh
Type: text/x-sh
Size: 18698 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081104/f0efe999/attachment.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: results-build.bz2
Type: application/octet-stream
Size: 243557 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081104/f0efe999/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorg-R70.conf
URL: <http://lists.x.org/archives/xorg/attachments/20081104/f0efe999/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorg.conf
URL: <http://lists.x.org/archives/xorg/attachments/20081104/f0efe999/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Xorg-R70.log
URL: <http://lists.x.org/archives/xorg/attachments/20081104/f0efe999/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Xorg.0.log
URL: <http://lists.x.org/archives/xorg/attachments/20081104/f0efe999/attachment-0003.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: border-R70.xwd.bz2
Type: application/octet-stream
Size: 399687 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081104/f0efe999/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: border-R74.xwd.bz2
Type: application/octet-stream
Size: 408912 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081104/f0efe999/attachment-0002.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: netscape-4.6-error
URL: <http://lists.x.org/archives/xorg/attachments/20081104/f0efe999/attachment-0004.ksh>
More information about the xorg
mailing list