this is similar to bug #10186. i'm making a new bug because while xfree-4.2.1-r1 has an app-default/XTerm that exposes this bug, i think the bug is deeper than just changing a config file. on PPC with xfree-4.2.1-r1, xterm exits immediately with: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/8 (your /dev/pts may vary) changing *VT100*eightBitInput: false to *VT100*eightBitInput: true fixes the problem. however, changing this setting works perfectly fine on x86 i'm not sure if this is an XFree problem or a kernel problem. there are definitely discrepencies between /usr/src/linux/include/asm-ppc/termbits.h and /usr/src/linux/include/asm-i386/termbits.h, but i don't know if this is a problem. from reading mailing lists, it seems this is a long standing problem. it would be nice if we could fix it. here's an URL with some more detail: http://www.geocrawler.com/archives/3/3/2001/9/100/6633199/
changing this to Gentoo Linux/PPC.
This should be fixed in 4.2.1-r1 in just a bit. The kernel side of things you guys will have to sort out though ...
Fixed. Added 109_ppc_4.2.1-xterm-eightBitInput-fix.patch if ARCH="ppc".
Thanks azarah Unfortunately our kernel (as usual) is problematic, I'll try and look into this when I have the time
Ok i can confirm this is now ok, built 4.2.1-r1 today and no xterm problems. Nall: should we keep this open while it's under investigation for the kernel stuffs?
dug around a bit and figured this out. i'm posting a full explanation here because i haven't found a satisfactory one anywhere and i think this should be documented _somewhere_. 

xterm craps out due to the following call:
ioctl(tty,TCSETS,&tio); when it's trying to set the terminal characteristics to 7bit input.

i'm not sure what went on in days of yore, but currently xterms in linux are always pty's which can only handle 8 bits. indeed, in /usr/src/linux/drivers/char/pty.c change_termios() ignores whatever size the user requests and forces 8 bits. 

PPC glibc overrides ioctl and diverts the various terminal ioctls (TCGETS, TCSETS, etc) to their POSIX equivalents (tcgetattr, tcsetattr, etc), which use the linux versions. this linux version of tcsetattr.c returns -EINVAL if the input size doesn't "stick". therefore, when xterm calls the ioctl with a request for 7bit input and the pty driver forces 8 bits, a mismatch occurs and -EINVAL is returned, resulting in the message:
xterm: fatal pty error 23 (errno=22) on tty /dev/pts/X

this is truly a linux kernel bug. if the pty driver is called with a request to change to 7bit input, it should return -EINVAL. this would allow all arches to have the same default behavior.

closing this one as fixed.
that'll teach me to try and writeup a bug description from dillo... let's try again. dug around a bit and figured this out. i'm posting a full explanation here because i haven't found a satisfactory one anywhere and i think this should be documented _somewhere_. xterm craps out due to the following call: ioctl(tty,TCSETS,&tio); when it's trying to set the terminal characteristics to 7bit input. i'm not sure what went on in days of yore, but currently xterms in linux are always pty's which can only handle 8 bits. indeed, in /usr/src/linux/drivers/char/pty.c change_termios() ignores whatever size the user requests and forces 8 bits. PPC glibc overrides ioctl and diverts the various terminal ioctls (TCGETS, TCSETS, etc) to their POSIX equivalents (tcgetattr, tcsetattr, etc), which use the linux versions. this linux version of tcsetattr.c returns -EINVAL if the input size doesn't "stick". therefore, when xterm calls the ioctl with a request for 7bit input and the pty driver forces 8 bits, a mismatch occurs and -EINVAL is returned, resulting in the message: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/X this is truly a linux kernel bug. if the pty driver is called with a request to change to 7bit input, it should return -EINVAL. this would allow all arches to have the same default behavior. closing this one as fixed.
