Messages in this thread | | | Date | Tue, 21 May 1996 03:50:40 +0100 (BST) | From | John Sullivan <> | Subject | Problems with modem control-line control |
| |
I'm sorry if this has already been discussed/sorted out, but I haven't seen it mentioned here, so it's probably best if it is noticed before proper 2.0 comes out...
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>
| |