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. System information: 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 mga_hal_drv.o)
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 XFree86.
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.