Programs that output Japanese text (kterm, galeon/Netscape on Japanese web
pages, kinput2 kanji selection, gjiten etc.) hang frequently on a
two-monitor Xinerama display. Easiest way to reproduce:
1. Open kterm
2. Enter "cat /lib/libc.so.6"
The output stops after a few lines and the kterm application is completely
unresponsive (it doesn't use any CPU time and can be killed with SIGINT
but doesn't refresh the window contents any more). xfs is not affected and
one can open another kterm and try again (it will hang at a different point
in the output, then).
When the X server has been started without the +xinerama option (but still
in dual-head mode), the problem doesn't appear. No other XFree86 settings
seem to have an effect. It appears to be Xinerama that causes it to fail.
Duron 700MHz, Gigabyte GA-7IXE4 mainboard (AMD 750 chipset),
Matrox G450 LE AGP graphics card using BETA 1.2.0 XFree86 drivers from
www.matrox.com (also tried with RedHat-supplied mga_drv.o + Matrox
This is not a supported configuration. Xinerama is included but is not
something completely stable or tested. The G450 driver is also new
that is only supported in singlehead configurations. It may or may not
work dualheaded, but is only supported singlehead. This may change in
a future release once XFree86 4.x matures.
The Matrox proprietary drivers are not supported.
This is most likely a bug in kterm however, and not in X, so I'm reassigning
to kterm, as I do not consider it a supported problem if it is a bug in
As mentioned in the original report, the bug affects all programs I have tested
that output Japanese text (galeon, gjiten etc.), not just kterm. kterm was only
given as an example that was easy to reproduce. So I don't understand why this
has now been reassigned as a kterm bug. It definitely looks like an X11 font
handling or rendering problem.
Upgrading to XFree86-4.1.0-0.8.6 from rawhide fixed this problem.
I'm closing this now.