9545a0eaa4
and xdm, possibly in general. What was happening was that the server was doing a tcsetattr(.. TCSADRAIN) on the mouse fd after a write. Since /dev/sysmouse had a null t_oproc, the drain failed with EIO. Somehow this spammed XFree86 (!@&^#%*& binary release!!), and the driver was left in a bogus state (ie: switch_in_progress permanently TRUE). The simplest way out was to implement a dummy scmousestart() routine to accept any characters from the tty system and toss them into the void. It would probably be more correct to intercept scwrite()'s to the mouse device, but that's executed for every single write to the screen. Supplying a start routine to eat the characters is only executed for the mouse port during startup/shutdown, so it should be faster. |
||
|---|---|---|
| .. | ||
| apm | ||
| bios | ||
| boot | ||
| conf | ||
| eisa | ||
| i386 | ||
| ibcs2 | ||
| include | ||
| isa | ||
| linux | ||
| pci | ||
| scsi | ||
| Makefile | ||