Re: [9fans] Re: random moving of cursor arrow

Re: [9fans] Re: random moving of cursor arrow

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

I added the serial intellimouse support to sources.  I have no way to
test it so hopefully Adi (or someone else) will be able to.  After
running aux/mouse for a serial microsoft intellimouse, just
	echo intellimouse > /dev/mousectl
and it should start acting like one.

[-- Attachment #2: Type: message/rfc822, Size: 3548 bytes --]

From: Enache Adrian <enache@rdslink.ro>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: random moving of cursor arrow
Date: Sat, 26 Jul 2003 12:59:40 +0300
Message-ID: <20030726095940.GA2481@ratsnest.hole>

A question about mouse support:

Have the new changes to the serial ports & mice code added support for scroll
serial mice (aka microsoft intellimice with 5 buttons) and for shift-button3
button2 emulation ?

I'm using a rather old 4th edition plan9 (Tue Sep  3 00:36:58 2002),
and there I hacked some code in the kernel so it works fine for me now
(but no code for pnp identification in aux/mouse.c - that would be simple,
though).

It looks like this:
src/9/port/devmouse.c:
/*
 * microsoft intellimouse 3 buttons + scroll
 * 	byte 0 -	1  L  R Y7 Y6 X7 X6
 *	byte 1 -	0 X5 X4 X3 X2 X1 X0
 *	byte 2 -	0 Y5 Y4 Y3 Y2 Y1 Y0
 *	byte 3 -	0  0  M  %  %  %  %
 *
 *	%: 0xf => U , 0x1 => D
 *
 *	L: left
 *	R: right
 *	U: up
 *	D: down
 */

int
m5mouseputc(Queue*, int c)
{
	static uchar msg[3];
	static int nb;
	msg[nb++] = c & 0x7f;
	if (nb == 4) {
		schar dx,dy,newbuttons;
		dx = msg[1] | (msg[0] & 0x3) << 6;
		dy = msg[2] | (msg[0] & 0xc) << 4;
		newbuttons =
			(msg[0] & 0x10) >> (shiftpressed ? 3:2)
			| (msg[0] & 0x20) >> 5
			| ( msg[3] == 0x10 ? 0x02 :
			    msg[3] == 0x0f ? 0x08 :
			    msg[3] == 0x01 ? 0x10 : 0 );
		mousetrack(dx, dy, newbuttons, TK2MS(MACHP(0)->ticks));
		nb = 0;
	}
	return 0;
}

(I also changed 'shift' in i8042intr() to 'shiftpressed' and made it global,
 and removed 'mouseshifted' which was never set).

Thanks & Regards,
Adi

Re: [9fans] Re: random moving of cursor arrow

[Enache Adrian]

On Thu, Aug 07, 2003 a.d., David Presotto wrote:
> I added the serial intellimouse support to sources.  I have no way to
> test it so hopefully Adi (or someone else) will be able to.  After
> running aux/mouse for a serial microsoft intellimouse, just
> 	echo intellimouse > /dev/mousectl
> and it should start acting like one.

Thanks! I will try it after I update my sources and rebuild plan9.
(or download the latest .iso.bz2 snapshot is this happens not to work).

Regards,
Adi

Re: [9fans] Re: random moving of cursor arrow

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

I'm adding the serial intellimouse support.  What mousectl were you
using to set it?  Right now
	serial port#	- sets up a normal (?) serial mouse
	serial port# M	- sets up a microsoft serial mouse
I could add
	serial port# MI	- for a microsoft serial intellimouse

[-- Attachment #2: Type: message/rfc822, Size: 3548 bytes --]

From: Enache Adrian <enache@rdslink.ro>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: random moving of cursor arrow
Date: Sat, 26 Jul 2003 12:59:40 +0300
Message-ID: <20030726095940.GA2481@ratsnest.hole>

A question about mouse support:

Have the new changes to the serial ports & mice code added support for scroll
serial mice (aka microsoft intellimice with 5 buttons) and for shift-button3
button2 emulation ?

I'm using a rather old 4th edition plan9 (Tue Sep  3 00:36:58 2002),
and there I hacked some code in the kernel so it works fine for me now
(but no code for pnp identification in aux/mouse.c - that would be simple,
though).

It looks like this:
src/9/port/devmouse.c:
/*
 * microsoft intellimouse 3 buttons + scroll
 * 	byte 0 -	1  L  R Y7 Y6 X7 X6
 *	byte 1 -	0 X5 X4 X3 X2 X1 X0
 *	byte 2 -	0 Y5 Y4 Y3 Y2 Y1 Y0
 *	byte 3 -	0  0  M  %  %  %  %
 *
 *	%: 0xf => U , 0x1 => D
 *
 *	L: left
 *	R: right
 *	U: up
 *	D: down
 */

int
m5mouseputc(Queue*, int c)
{
	static uchar msg[3];
	static int nb;
	msg[nb++] = c & 0x7f;
	if (nb == 4) {
		schar dx,dy,newbuttons;
		dx = msg[1] | (msg[0] & 0x3) << 6;
		dy = msg[2] | (msg[0] & 0xc) << 4;
		newbuttons =
			(msg[0] & 0x10) >> (shiftpressed ? 3:2)
			| (msg[0] & 0x20) >> 5
			| ( msg[3] == 0x10 ? 0x02 :
			    msg[3] == 0x0f ? 0x08 :
			    msg[3] == 0x01 ? 0x10 : 0 );
		mousetrack(dx, dy, newbuttons, TK2MS(MACHP(0)->ticks));
		nb = 0;
	}
	return 0;
}

(I also changed 'shift' in i8042intr() to 'shiftpressed' and made it global,
 and removed 'mouseshifted' which was never set).

Thanks & Regards,
Adi

Re: [9fans] Re: random moving of cursor arrow

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

I tried a bundh of scenarios on some computers I had at work.  Nothing I
did would keep my 400 MHz system from losing characters on the serial
driver if I ran my cdrom full tilt and used > 38400 buad.  At or under
38400, turning on the fifo was enough, though I still saw one or two
overruns over the course of 15 minutes.  There's clearly something about
the cdrom driver that's staying at splhi way too long or causing back to
back interrupts that keep the serial interrupts from sneaking in.  At 9600
baud down (which is where the mouse should live), turning on the fifo
worked 100% of the time.

The serial driver (at least from interrupt to mouse stream interpretation)
is not  fundamentally different now than in the 3rd edition.  If the same
mouse hardware works with the 3rd edition and loses chars with the 4th I'm
moderately flabergasted.

For straight (non-mouse) serial ports, there is one difference: the 3rd ed
had much smaller queues and turned off RTS fairly often, effectively reducing
the port throughput to a fraction of what it was really set to.  It might be
that this was avoiding overruns.  I need to figure out a way to do the same
thing when the computer really can't keep up.  That should get rid of the
overruns for things like PPP.  Won't effect mice since I believe that they
ignore hardware flow control, at least the ones I have do.

The current aux/mouse on sources turns on the fifo.

[-- Attachment #2: Type: message/rfc822, Size: 3862 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: random moving of cursor arrow
Date: Mon, 28 Jul 2003 07:26:59 +0200
Message-ID: <20030728072659.B1666@cackle.proxima.alt.za>

On Fri, Jul 25, 2003 at 10:22:10PM -0400, David Presotto wrote:
>
> I'll bang at serial ports tomorrow and see if I can figure out what's happening.
> With modern machines, I shouldn't get overruns even without the fifo.  I used
> to avoid the fifo for mice because it made the mouse jerky.
>
Note that (in my recollection) the problem is more recent than the
switch to the new driver.  I have only recently migrated to an
Intellimouse and then only on my workstation and the impression I
get is that there has been a slowdown in the very recent past.  It
would be difficult for me to test this, but if we come up with no
other option, I can set up a test bench.

> Everything related has changed of course; uart driver, clock routine, and
> scheduler.  Any could be at fault.  I'll plug some machines back to back and
> see if I can cause overruns.  A mouse really shouldn't be able to though,
> it's only 9600 baud or less.  If we're missing, something is really
> screwed up.  We only use ps2 mice these days but I can scrounge up some
> serial ones.
>
I have only examined the actual driver.  I couldn't see anything
clearly suspicious in it.

> It is true that if the mouse is misidentified, it will cause exactly the
> behavior babic is seeing, i.e., if it guesses the wrong protocol.

Yes, but then echo i1 > /dev/eia0ctl wouldn't have any ameliorating
effect on it.

++L

Re: [9fans] Re: random moving of cursor arrow

[Douglas A. Gwyn]

boyd, rounin wrote:
> iirc, from the dz-kmc days you needed to manage the 'fifo' so it wouldn't
> overrun, but at the same time you needed a timer to empty it [stick on the rawq]
> so stuff just didn't get 'stuck'.

No, the problem arises when people try to set the input alarm
threshold at more than 1 character.  In the case of the DZ11
the right thing to do was to interrupt on any incoming
character and after processing (putting in the queue) wait a
tiny bit for the FIFO to trickle down then test for another
ready character, and if found don't return (context switch)
but instead go back to the start of the intr function and
process the character.  My driver did that, and on a PDP-11/34
we had a couple of dozen concurrent users of 9600bpi terminals
with great response.

I have a KMC11B sitting around, and some day I'll look into
whatever problems there might have been.  The idea of a front-
end processor was right, even if the implementation wasn't.

> how much time have i wasted with rs-232 junk?  too much.

However, it's as near to universal as one can get, even today.
I have a paper tape reader and an Apple IIGS attached to my
PCs via RS-232-C.  (The magtape is on SCSI.)

Re: [9fans] Re: random moving of cursor arrow

[Lucio De Re]

On Mon, Jul 28, 2003 at 07:26:59AM +0200, Lucio De Re wrote:
> >
> Note that (in my recollection) the problem is more recent than the
> switch to the new driver.  I have only recently migrated to an
> Intellimouse and then only on my workstation and the impression I
> get is that there has been a slowdown in the very recent past.  It
> would be difficult for me to test this, but if we come up with no
> other option, I can set up a test bench.
>
Oops, what I meant(and left out!) was that mostly I use serial mice, I
only have one PS/2 mouse.  In fact, I can even compare the two on the
same hardware.

++L

Re: [9fans] Re: random moving of cursor arrow

[Lucio De Re]

On Fri, Jul 25, 2003 at 10:22:10PM -0400, David Presotto wrote:
>
> I'll bang at serial ports tomorrow and see if I can figure out what's happening.
> With modern machines, I shouldn't get overruns even without the fifo.  I used
> to avoid the fifo for mice because it made the mouse jerky.
>
Note that (in my recollection) the problem is more recent than the
switch to the new driver.  I have only recently migrated to an
Intellimouse and then only on my workstation and the impression I
get is that there has been a slowdown in the very recent past.  It
would be difficult for me to test this, but if we come up with no
other option, I can set up a test bench.

> Everything related has changed of course; uart driver, clock routine, and
> scheduler.  Any could be at fault.  I'll plug some machines back to back and
> see if I can cause overruns.  A mouse really shouldn't be able to though,
> it's only 9600 baud or less.  If we're missing, something is really
> screwed up.  We only use ps2 mice these days but I can scrounge up some
> serial ones.
>
I have only examined the actual driver.  I couldn't see anything
clearly suspicious in it.

> It is true that if the mouse is misidentified, it will cause exactly the
> behavior babic is seeing, i.e., if it guesses the wrong protocol.

Yes, but then echo i1 > /dev/eia0ctl wouldn't have any ameliorating
effect on it.

++L

Re: [9fans] Re: random moving of cursor arrow

[Richard Miller]

> It is true that if the mouse is misidentified, it will cause exactly the
> behavior babic is seeing, i.e., if it guesses the wrong protocol.

... for example, if you happen to move the mouse during boot-up just as the
aux/mouse command is executed.  Eventually I've learned to keep my hand off
until the rio screen appears.

-- Richard

Re: [9fans] Re: random moving of cursor arrow

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

We had a long history of 16[54]xx chips with buggy fifos
and/or unchangeable length fifos.  At 1200 baud, these
guys used to delay mouse actions 1/7 of a second during
a sweep and as much as 1/4 second at the end of the sweep.
The sweep delay was barely perceptible but the mouse movement
just as you were taking your hand off the mouse bothered
people.  We had similar problems with uarts on MIPS/SGI
machines.  All those machines should have died years ago,
but since I don't normally use a serial port mouse (all ours are
PS/2) I just haven't bothered.  I'll make fifo on the default
for serial mice.

However, that really doesn't explain what's going on.  Unless the
people seeing these problems are on sub 100 megahz machines, we're
really screwing up if we can't keep up with 120 or 240 interrupts
per second.  Something must have broken when we changed to a common
model for all the uarts (or changed the scheduler).  I'll go into
work today and bang at some machines and see if I can recreate/fix
the problem.  I'm back for a way or two to rest up and serial
ports are about as restful as it gets.

[-- Attachment #2: Type: message/rfc822, Size: 1921 bytes --]

From: C H Forsyth <forsyth@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: random moving of cursor arrow
Date: Sat, 26 Jul 2003 09:37:12 +0100
Message-ID: <29ce300d69819f673d96bbd7d9ae9302@vitanuova.com>

>>I used to avoid the fifo for mice because it made the mouse jerky.

i never really understood that: i switched on the uart fifo at the start on a system
i did and it handled a mouse without fuss.

Re: [9fans] Re: random moving of cursor arrow

[Enache Adrian]

A question about mouse support:

Have the new changes to the serial ports & mice code added support for scroll
serial mice (aka microsoft intellimice with 5 buttons) and for shift-button3
button2 emulation ?

I'm using a rather old 4th edition plan9 (Tue Sep  3 00:36:58 2002),
and there I hacked some code in the kernel so it works fine for me now
(but no code for pnp identification in aux/mouse.c - that would be simple,
though).

It looks like this:
src/9/port/devmouse.c:
/*
 * microsoft intellimouse 3 buttons + scroll
 * 	byte 0 -	1  L  R Y7 Y6 X7 X6
 *	byte 1 -	0 X5 X4 X3 X2 X1 X0
 *	byte 2 -	0 Y5 Y4 Y3 Y2 Y1 Y0
 *	byte 3 -	0  0  M  %  %  %  %
 *
 *	%: 0xf => U , 0x1 => D
 *
 *	L: left
 *	R: right
 *	U: up
 *	D: down
 */

int
m5mouseputc(Queue*, int c)
{
	static uchar msg[3];
	static int nb;
	msg[nb++] = c & 0x7f;
	if (nb == 4) {
		schar dx,dy,newbuttons;
		dx = msg[1] | (msg[0] & 0x3) << 6;
		dy = msg[2] | (msg[0] & 0xc) << 4;
		newbuttons =
			(msg[0] & 0x10) >> (shiftpressed ? 3:2)
			| (msg[0] & 0x20) >> 5
			| ( msg[3] == 0x10 ? 0x02 :
			    msg[3] == 0x0f ? 0x08 :
			    msg[3] == 0x01 ? 0x10 : 0 );
		mousetrack(dx, dy, newbuttons, TK2MS(MACHP(0)->ticks));
		nb = 0;
	}
	return 0;
}

(I also changed 'shift' in i8042intr() to 'shiftpressed' and made it global,
 and removed 'mouseshifted' which was never set).

Thanks & Regards,
Adi

Re: [9fans] Re: random moving of cursor arrow

[boyd, rounin]

> >>I used to avoid the fifo for mice because it made the mouse jerky.
>
> i never really understood that: i switched on the uart fifo at the start on a
system
> i did and it handled a mouse without fuss.

no, it makes perfect sense [some random floyd/waters quote] 'cos if you don't
fill/empty it right all sorts of 'orrible stuff can happen.

iirc, from the dz-kmc days you needed to manage the 'fifo' so it wouldn't
overrun, but at the same time you needed a timer to empty it [stick on the rawq]
so stuff just didn't get 'stuck'.

how much time have i wasted with rs-232 junk?  too much.

Re: [9fans] Re: random moving of cursor arrow

[C H Forsyth]

>>I used to avoid the fifo for mice because it made the mouse jerky.

i never really understood that: i switched on the uart fifo at the start on a system
i did and it handled a mouse without fuss.

Re: [9fans] Re: random moving of cursor arrow

[David Presotto]

I'll bang at serial ports tomorrow and see if I can figure out what's happening.
With modern machines, I shouldn't get overruns even without the fifo.  I used
to avoid the fifo for mice because it made the mouse jerky.

Everything related has changed of course; uart driver, clock routine, and
scheduler.  Any could be at fault.  I'll plug some machines back to back and
see if I can cause overruns.  A mouse really shouldn't be able to though,
it's only 9600 baud or less.  If we're missing, something is really
screwed up.  We only use ps2 mice these days but I can scrounge up some
serial ones.

It is true that if the mouse is misidentified, it will cause exactly the
behavior babic is seeing, i.e., if it guesses the wrong protocol.

[9fans] Re: random moving of cursor arrow

[sasa]

to boyd:
>the only thing i know about serial ports is that i don't to know
>anything about them -- ghastly, just ghastly ...

hahahaha, you made me laugh. you're right about serial ports,
but i have old hardware.

sasa babic.

Re: [9fans] Re: random moving of cursor arrow

[boyd, rounin]

> sorry not for telling the mouse type.
> it's serial mouse in port 0.

that woulda helped a lot.  i'd say the serial port is dropping chars,
which could be a hardware or a driver problem.

the only thing i know about serial ports is that i don't want to know
anything about them -- ghastly, just ghastly ...

[9fans] Re: random moving of cursor arrow

[sasa]

sorry not for telling the mouse type.
it's serial mouse in port 0.

sasa.

[9fans] Re: random moving of cursor arrow

[sasa]

second description:
when i touch the mouse, the cursor starts to randomly
fly around the screen and without touching buttons
sometimes the new window appears.

sasa.

[9fans] Re: random moving of cursor arrow

[sasa]

thank you all very much for help.
i'll try 'echo i1 > /dev/eia0ctl'.

alexandr "sasa" babic.