[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Xorg segfaulting and other problems
Jukka Salmi --> tech-x11 (2009-01-19 22:00:14 +0100):
> after successfully running XFree86 on a NetBSD/i386 current system for
> years I recently decided to give the in-tree Xorg a try. Using binaries
> built from sources as of 2009-01-02 I noticed several problems:
Finally all those problems seem to be fixed or at least not reproducable
anymore. At least on a 5.0_STABLE system; I didn't try with -current,
but since the problems are identical I'm quite sure the fixes also make
a -current Xorg system work. Since none of those fixes have been
committed yet I'll summarise them here:
> - When using another window manager where moving windows is done
> "opaque" (i.e. not just their borders are shown as with twm),
> moving windows was extremely slow (CPU intensive!). Furthermore,
> xterm generally was slow, e.g. a visual bell was more like a black
> waterfall than a dark flash... But rxvt-unicode was fast as usual.
This is fixed by building mga(4) with USE_XAA defined. See here for
> - With XFree86 I'm using a Matrox G450 card with a dual head setup.
> This works fine. Of course I want to do the same with Xorg. Thus
> the first thing I did was running xorgconfig(1) and manually porting
> various parts like the dual screen configuration from XF86Config(5) to
> xorg.conf(5). But running startx(1) afterwards resulted in Xorg dumping
> core; a gdb bt shows:
> #13 0x0809769d in ddxGiveUp ()
> #14 0x0809769d in ddxGiveUp ()
> #15 0x08179f07 in AbortServer ()
> #16 0x0817a345 in FatalError ()
> #17 0x080a46f9 in xf86SigHandler ()
> #18 0xbba49d20 in setusershell () from /usr/lib/libc.so.12
> #19 0xbb68fc49 in ?? ()
> #20 0xbb72a800 in ?? ()
> #21 0x00000000 in ?? ()
> After removing xorg.conf startx was successful. Xorg also started
> successfully after just removing the second screen configuration part
> from xorg.conf. However, more problems followed (see below).
This is magically "fixed" by the USE_XAA fix referenced above. Ok, it's
probably not fixed, but I can't reproduce the crash with an XAA enabled
mga(4), and my original dual head setup works fine again.
> - Starting xterm(1) resulted in
> Failed to open input method
> being printed, and then it took several seconds until xterm eventually
> appeared. This was probably due to `LC_CTYPE' being set to `en_US.UTF-8';
> at least the message was not printed and the delay went away after I
> set LC_CTYPE=en_US.ISO8859-1.
> - Starting twm(1) failed with
> unable to open fontset "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*"
> while `LC_CTYPE' was `en_US.UTF-8'; xlsfonts(1) showed fonts matching
> the above pattern. However, setting it to `en_US.ISO8859-1' worked
> around this problem, i.e. it made twm start.
Those two problems are fixed by a change to
/usr/X11R7/lib/X11/locale/en_US.UTF-8/XI18N_OBJS. See here for
This email fills a much-needed gap in the archives.
Main Index |
Thread Index |