[email protected] wrote:
>
> It's been rumoured that Gunther Mayer said:
> >
> > > I am experiencing debilitating intermittent mouse problems & was about
> > ...
> > > Symptoms:
> > > After a long time of flawless operation (ranging from nearly a week to
> > > as little as five minutes), the X11 pointer flies up to top-right corner,
> > ^^^^^^^^^^^^^^^^
> > > and mostly wants to stay there. Moving the mouse causes a cascade of
> > > spurious button-press events get generated.
> >
> > This is easily explained: some byte of the mouse protocol was lost.
>
> Bing!
>
> That's it! This would also explain why gpm seems to work i.e. correctly
> process the events, even when X11 can't. I will take this up on the
> Xf86 lists ...
>
> > (Some mouse protocols are even designed to allow
> > easy resync/recovery by fixed bit patterns!)
>
> This mouse seems to set every fourth byte to zero, which should allow
> syncing ...
The fourth byte is propably the wheel or 5 button support, see
http://www.microsoft.com/hwdev/input/5b_wheel.htm
to get a hint about mouse protocol variations.
Getting resync right is not as easy as detecting zero bytes. You
should account for wild protocol variations in the world wide mouse
population, too.
It's been rumoured that Vojtech Pavlik said:
> On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote:
> > [email protected] wrote:
> > > It's been rumoured that Gunther Mayer said:
> > > > [email protected] wrote:
> > > > >
> > > > > I am experiencing debilitating intermittent mouse problems & was about
> > > >
> > > > This is easily explained: some byte of the mouse protocol was lost.
> > >
> > Getting resync right is not as easy as detecting zero bytes. You
> > should account for wild protocol variations in the world wide mouse
> > population, too.
>
> The new input psmouse driver can resync when bytes are lost and also
> shouldn't lose any bytes if there are not transmission problems on the
> wire. But this is 2.5 stuff.
umm linux kernel 2.5? Umm, given that a stable linux 2.6/3.0 might be
years away ... and this seems 'minor', wouldn't it be better to
submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x
patch? e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something? I mean this
cant be more than a few hundred lines of code? Requireing no other
changes to the kernel?
--linas
On Wed, Mar 28, 2001 at 05:19:33PM -0600, [email protected] wrote:
> It's been rumoured that Vojtech Pavlik said:
> > On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote:
> > > [email protected] wrote:
> > > > It's been rumoured that Gunther Mayer said:
> > > > > [email protected] wrote:
> > > > > >
> > > > > > I am experiencing debilitating intermittent mouse problems & was about
> > > > >
> > > > > This is easily explained: some byte of the mouse protocol was lost.
> > > >
> > > Getting resync right is not as easy as detecting zero bytes. You
> > > should account for wild protocol variations in the world wide mouse
> > > population, too.
> >
> > The new input psmouse driver can resync when bytes are lost and also
> > shouldn't lose any bytes if there are not transmission problems on the
> > wire. But this is 2.5 stuff.
>
> umm linux kernel 2.5? Umm, given that a stable linux 2.6/3.0 might be
> years away ... and this seems 'minor', wouldn't it be better to
> submit this as a teeny-weeny new kind of mouse device driver as a 2.4.x
> patch? e.g. CONFIG_MOUSE_PSAUX_SUPERSYNC or something? I mean this
> cant be more than a few hundred lines of code? Requireing no other
> changes to the kernel?
To work correctly, this requires to kill the current psaux and keyboard
driver, and those two are one file, and are very very builtin into the
console system.
Thus it's a patch of almost thousand lines to pc_keyb.c and keyboard.c
and can't easily added as a CONFIG_ option.
Plus, it's very likely the new PS/2 code will break on some systems that
have not-so-compatible i8042 chips, so it is really something that can't
go in 2.4. And I would love to have it in 2.4, really.
--
Vojtech Pavlik
SuSE Labs
On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote:
> [email protected] wrote:
> >
> > It's been rumoured that Gunther Mayer said:
> > >
> > > > I am experiencing debilitating intermittent mouse problems & was about
> > > ...
> > > > Symptoms:
> > > > After a long time of flawless operation (ranging from nearly a week to
> > > > as little as five minutes), the X11 pointer flies up to top-right corner,
> > > ^^^^^^^^^^^^^^^^
> > > > and mostly wants to stay there. Moving the mouse causes a cascade of
> > > > spurious button-press events get generated.
> > >
> > > This is easily explained: some byte of the mouse protocol was lost.
> >
> > Bing!
> >
> > That's it! This would also explain why gpm seems to work i.e. correctly
> > process the events, even when X11 can't. I will take this up on the
> > Xf86 lists ...
> >
> > > (Some mouse protocols are even designed to allow
> > > easy resync/recovery by fixed bit patterns!)
> >
> > This mouse seems to set every fourth byte to zero, which should allow
> > syncing ...
>
> The fourth byte is propably the wheel or 5 button support, see
> http://www.microsoft.com/hwdev/input/5b_wheel.htm
> to get a hint about mouse protocol variations.
>
> Getting resync right is not as easy as detecting zero bytes. You
> should account for wild protocol variations in the world wide mouse
> population, too.
The new input psmouse driver can resync when bytes are lost and also
shouldn't lose any bytes if there are not transmission problems on the
wire. But this is 2.5 stuff.
--
Vojtech Pavlik
SuSE Labs
Original Problem: PS/2 mouse pointer goes upper right corner and stays there.
Diagnosis: one byte was lost and this is fatal for the mouse driver.
Various people wrote:
>
> On Wed, Mar 28, 2001 at 05:19:33PM -0600, [email protected] wrote:
..
> > > > > > > I am experiencing debilitating intermittent mouse problems & was about
> > > > > >
> > > > > > This is easily explained: some byte of the mouse protocol was lost.
>
> Plus, it's very likely the new PS/2 code will break on some systems that
> have not-so-compatible i8042 chips, so it is really something that can't
Losing bytes on psaux is a bug!
We must first understand, how bytes can be lost (most probable first):
- transmission error on the line can easily happen in noisy environments
and is _not_ handled correctly by linux (i.e. should do RESEND)
- 0xAA is always handled as reconnect, if the mouse generates this byte,
Linux will de-sync the mouse driver
- Mouse is defective or keyboard controller defective
- An error in the linux kbd/mouse driver (e.g. triggered by X11<->console switching)
This patch printk's necessary information on the first 2 cases and
should be applied to the stable kernel, as this will help to resolve a severe bug !
Regards, Gunther
P.S.
These messages can be generated:
Apr 8 21:49:23 linux kernel: psaux: reconnect 0xAA detected
Apr 8 21:49:42 linux kernel: pc_keyb: mouse error (0x75), byte ignored(ff).
Apr 8 21:49:43 linux kernel: psaux: reconnect 0xAA detected
--- linux-2.4.3-orig/drivers/char/pc_keyb.c Wed Apr 4 19:46:42 2001
+++ linux/drivers/char/pc_keyb.c Sun Apr 8 21:45:37 2001
@@ -404,6 +404,11 @@
mouse_reply_expected = 0;
}
else if(scancode == AUX_RECONNECT){
+ // Under normal operation most mice don't generate 0xAA.
+ // But, Other devices might be unusable with this policy.
+ // (My mouse easily generates 0xAAs on rapid movements,
+ // when set to 10 samples/sec.)
+ printk("psaux: reconnect detected(0xaa), sending AUX_ENABLE.\n");
queue->head = queue->tail = 0; /* Flush input queue */
__aux_write_ack(AUX_ENABLE_DEV); /* ping the mouse :) */
return;
@@ -420,6 +425,9 @@
kill_fasync(&queue->fasync, SIGIO, POLL_IN);
wake_up_interruptible(&queue->proc_list);
}
+ else
+ // 2K buffer is enough for about 10 sec under normal operations, here.
+ printk("psaux: buffer overflow, byte dropped.\n");
}
#endif
}
@@ -465,6 +473,11 @@
else
handle_keyboard_event(scancode);
}
+ else
+ // Fixme: Ignoring bytes will de-sync mouse protocol.
+ printk("pc_keyb: %s error (0x%02x), byte ignored(%02x).\n",
+ (status & KBD_STAT_MOUSE_OBF)?"mouse":"kbd",status,scancode);
+
status = kbd_read_status();
}