I'm using 1.3.71 at the moment, as is someone else I know, and we've
both noticed a problem with mouse-driver code using Microsoft/MouseMan
dual-protocol serial mice. These are normally MS, but become MM when
the DTR modem-control line is held LOW.
The problem exhibits with SVGAlib and gpm, but not XF86, which drives
these mice in MM mode properly with no modification.
Here is a section of code from svgalib-1.2.10/src/mouse/ms.c, in the
mouse initialisation code: (badly mangled but you get the picture)
---------------------------------------------------------------------
ioctl(__svgalib_mouse_fd,TIOCMGET, &modem_info);
modem_info &= ~TIOCM_DTR; /*set DTR as ordered.. */
ioctl(__svgalib_mouse_fd, TIOCMSET, &modem_info)
for ( ; a_few_times ; ) {
tcgetattr(__svgalib_mouse_fd, &tty);
tty.c_iflag = IGNBRK | IGNPAR;
tty.c_oflag = 0;
tty.c_lflag = 0;
tty.c_line = 0;
tty.c_cc[VTIME] = 0;
tty.c_cc[VMIN] = 1;
tty.c_cflag = c_cflag | speed_setting;
c = "*x"; /* where '*x' is a command to the mouse */
write(__svgalib_mouse_fd, c, 2);
usleep(10000);
tcsetattr(__svgalib_mouse_fd, TCSAFLUSH, &tty);
}
---------------------------------------------------------------------
The problem being that although we are correctly clearing DTR at the
start, once we've finished doing the tcsetattr()s, DTR has become high
again. The driver still considers the mouse to be in MM mode (an
utterly incompatible protocol to MS-mode) and so falls completely flat
on its face.
If the ioctl(TIOCMSET) is moved to *after* the line-speed changing
commands, the mouse will work fine, in MM mode, therefore with DTR still
clear. (I haven't got round to checking the gpm source code but it
probably does much the same thing.)
Now, this could be an error in the driver - that is if the tcsetattr()
is *supposed* to reset DTR/RTS to their default state. Or it could be
a kernel serial driver bug, if we're bashing these signals when they
should be being preserved.
Like I say, XF86 works with this mouse, so either it's not provoking
the bug, or it's doing something right which gpm and SVGAlib are
getting wrong... (If you 'steal' the mouse in an xterm by opening the
mouse device again, the control lines are reset and the mouse goes
haywire, but normal operation works fine.)
Also, putting a ioctl(TIOCMGET) and looking at DTR in the main mouse
event loop seems to yield completely random results...
Thoughts?
John
-- But it's much too late, you say, for doing this now We should have done it then, well it just goes to show How wrong you can be, and how you really should know That it's never too late, to get up and go <p><a href="http://callisto.girton.cam.ac.uk/users/js10039/">Me.</a>