Re: mouse problems in 2.4.2 -> lost byte

Re: mouse problems in 2.4.2 -> lost byte

[James Simmons]

>This is easily explained: some byte of the mouse protocol was lost.
>(Some mouse protocols are even designed to allow
>easy resync/recovery by fixed bit patterns!)
>
>Write an intelligent mouse driver for XFree86 to compensate for
>lost bytes.

Or write a kernel input device driver. In fact I probable have a mouse
driver for you. What kind of mouse do you have? Then set your X config to
have the following:

Section "Pointer"
            Protocol    "ImPS/2"
            Device      "/dev/input/mice"
            ZAxisMapping 4 5
EndSection

This way you don't have to wait a few months before the bug is fixed by
XFree86.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: mouse problems in 2.4.2 -> lost byte

[Gunther Mayer]

James Simmons wrote:
> 
> >This is easily explained: some byte of the mouse protocol was lost.
> >(Some mouse protocols are even designed to allow
> >easy resync/recovery by fixed bit patterns!)
> >
> >Write an intelligent mouse driver for XFree86 to compensate for
> >lost bytes.
> 
> Or write a kernel input device driver. In fact I probable have a mouse
> driver for you. 

Where can I get your driver?


>        What kind of mouse do you have? Then set your X config to
> have the following:
> 
> Section "Pointer"
>             Protocol    "ImPS/2"
>             Device      "/dev/input/mice"

What is better in using /dev/input/mice than /dev/psaux
on this problem exactly?

Re: mouse problems in 2.4.2 -> lost byte

[linas]

It's been rumoured that James Simmons said:
> 
> 
> >This is easily explained: some byte of the mouse protocol was lost.
> >(Some mouse protocols are even designed to allow
> >easy resync/recovery by fixed bit patterns!)
> >
> >Write an intelligent mouse driver for XFree86 to compensate for
> >lost bytes.
> 
> Or write a kernel input device driver. In fact I probable have a mouse
> driver for you. What kind of mouse do you have? 

logitech trackman marble wheel. 

send me the driver.  Are you working on getting the thing incorporated
into xf86? should I pester someone over there about it?  should I assume
that 'everything will be OK', if I wait long enough?

--linas

Re: mouse problems in 2.4.2 -> lost byte

[James Simmons]

>> 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?

Its more than a few hundred lines. Mind you it wouldn't be hard to patch
2.4.X to use the new PS/2 drivers but it is a pretty big change. I
seriously don't it would go in. Your welcomed to try out these drivers. I
have personally been using these new PS/2 drivers for several months now
with now problems. In fact this driver can trick my i8042 chipset to allow
me to plug two PS/2 keyboards in :-)

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: mouse problems in 2.4.2 -> lost byte

[James Simmons]

>So you recommend to connect the mouse to USB (instead of psaux) because
>psaux+Xfree86 are losing bytes under circumstances (e.g. some load
>pattern).
>
>This is a fine solution for users with dual protocol mice, but doesn't
>resolve the problem for other poor ps/2 mouse owners !

You misunderstood me. For 2.4.X it is:

Real PS/2 mouse -> /dev/psaux -> PS/2 protocol -> X server

All mice using /dev/input/mice -> PS/2 protocol -> X server

Yes mice. I have had 5 mice attached and going to the X server. It was no
problem. Multiple keyboards, well that is another story :-( It doesn't
matter to the X server if two different devices are sending the same
protocol. Since the protocol is coming in from two different devices theri
is no conflict. I believe we was having problems with another type of
mouse.

>Even with PS/2 mouse support in the "new input" driver I wouldn't expect
>the psaux-byte-lost bug to disappear magically.

I see Vojtech has answered this already.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: mouse problems in 2.4.2 -> lost byte

[James Simmons]

>Where can I get your driver?

I attach it to the other posting to this thread. I also have it in CVS at
http://linuxconsole.sourceforge.net with a bunch of other input drivers.

>> Section "Pointer"
>>             Protocol    "ImPS/2"
>>             Device      "/dev/input/mice"
>
>What is better in using /dev/input/mice than /dev/psaux
>on this problem exactly?

The reason to use /dev/input/mice is the PS/2 mouse driver itself has not
been ported over to the input suite for 2.4.X. You can use the above for
the USB mouse now. Now if you have a USB mouse plus a PS/2 mouse then
having both use /dev/psaux would require a reworking of the PS/2 driver.
I rather port over the PS/2 mouse to use /dev/input/mice. I have done this
for my CVS but since the PS/2 mouse shares the same chipset as the PS/2
keyboard you have to use both input drivers. It would be better if XFree86
would have a /dev/eventX driver but we would wait a long time for that to
happen :-(

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: mouse problems in 2.4.2 -> lost byte

[Gunther Mayer]

James Simmons wrote:
> 
> >Where can I get your driver?
> 
> I attach it to the other posting to this thread. I also have it in CVS at
> http://linuxconsole.sourceforge.net with a bunch of other input drivers.
> 
> >> Section "Pointer"
> >>             Protocol    "ImPS/2"
> >>             Device      "/dev/input/mice"
> >
> >What is better in using /dev/input/mice than /dev/psaux
> >on this problem exactly?
> 
> The reason to use /dev/input/mice is the PS/2 mouse driver itself has not
                    ^^^^^^^^^^^^^^^

So you recommend to connect the mouse to USB (instead of psaux) because
psaux+Xfree86 are losing bytes under circumstances (e.g. some load pattern).

This is a fine solution for users with dual protocol mice, but doesn't
resolve the problem for other poor ps/2 mouse owners !

> been ported over to the input suite for 2.4.X. You can use the above for
> the USB mouse now. Now if you have a USB mouse plus a PS/2 mouse then
> having both use /dev/psaux would require a reworking of the PS/2 driver.
> I rather port over the PS/2 mouse to use /dev/input/mice. I have done this
> for my CVS but since the PS/2 mouse shares the same chipset as the PS/2
> keyboard you have to use both input drivers. It would be better if XFree86
> would have a /dev/eventX driver but we would wait a long time for that to
> happen :-(

Even with PS/2 mouse support in the "new input" driver I wouldn't expect the 
psaux-byte-lost bug to disappear magically.
-

Gunther

Re: mouse problems in 2.4.2 -> lost byte

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1003 bytes --]



>logitech trackman marble wheel.
>
>send me the driver.

Attached :-) I'm assuming you use the logitech busmouse driver. Logitech
makes many kinds of mice.

>Are you working on getting the thing incorporated
>into xf86? should I pester someone over there about it?  should I assume
>that 'everything will be OK', if I wait long enough?

This is a kernel driver so it is independent of XFree86. Use the
configuration I told you about with X and it will work. Well as long as
XFree86 doesn't break its PS/2 driver.

If you have any problems setting it up let me know.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

[-- Attachment #2: Type: TEXT/plain, Size: 5167 bytes --]

/*
 * $Id: logibm.c,v 1.7 2000/05/29 11:19:51 vojtech Exp $
 *
 *  Copyright (c) 1999-2000 Vojtech Pavlik
 *
 *  Based on the work of:
 *	James Banks		Matthew Dillon
 *	David Giller		Nathan Laredo
 *	Linus Torvalds		Johan Myreen
 *	Cliff Matthews		Philip Blundell
 *	Russell King
 *
 *  Sponsored by SuSE
 */

/*
 * Logitech Bus Mouse Driver for Linux
 */

/*
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or 
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 * 
 * Should you need to contact me, the author, you can do so either by
 * e-mail - mail your message to <vojtech@ucw.cz>, or by paper mail:
 * Vojtech Pavlik, Ucitelska 1576, Prague 8, 182 00 Czech Republic
 */

#include <asm/io.h>
#include <asm/irq.h>

#include <linux/module.h>
#include <linux/delay.h>
#include <linux/ioport.h>
#include <linux/init.h>
#include <linux/input.h>

#define	LOGIBM_BASE		0x23c
#define	LOGIBM_EXTENT		4

#define	LOGIBM_DATA_PORT	LOGIBM_BASE + 0
#define	LOGIBM_SIGNATURE_PORT	LOGIBM_BASE + 1
#define	LOGIBM_CONTROL_PORT	LOGIBM_BASE + 2
#define	LOGIBM_CONFIG_PORT	LOGIBM_BASE + 3

#define	LOGIBM_ENABLE_IRQ	0x00
#define	LOGIBM_DISABLE_IRQ	0x10
#define	LOGIBM_READ_X_LOW	0x80
#define	LOGIBM_READ_X_HIGH	0xa0
#define	LOGIBM_READ_Y_LOW	0xc0
#define	LOGIBM_READ_Y_HIGH	0xe0

#define LOGIBM_DEFAULT_MODE	0x90
#define LOGIBM_CONFIG_BYTE	0x91
#define LOGIBM_SIGNATURE_BYTE	0xa5

#define LOGIBM_IRQ		5

MODULE_PARM(logibm_irq, "i");

static int logibm_irq = LOGIBM_IRQ;
static int logibm_used = 0;

static void logibm_interrupt(int irq, void *dev_id, struct pt_regs *regs);

static int logibm_open(struct input_dev *dev)
{
	if (logibm_used++)
		return 0;
	if (request_irq(logibm_irq, logibm_interrupt, 0, "logibm", NULL)) {
		logibm_used--;
		printk(KERN_ERR "logibm.c: Can't allocate irq %d\n", logibm_irq);
		return -EBUSY;
	}
	outb(LOGIBM_ENABLE_IRQ, LOGIBM_CONTROL_PORT);
	return 0;
}

static void logibm_close(struct input_dev *dev)
{
	if (--logibm_used)
		return;
	outb(LOGIBM_DISABLE_IRQ, LOGIBM_CONTROL_PORT);
	free_irq(logibm_irq, NULL);
}

static struct input_dev logibm_dev = {
	evbit:		{ BIT(EV_KEY) | BIT(EV_REL) },
	keybit: 	{ [LONG(BTN_LEFT)] = BIT(BTN_LEFT) | BIT(BTN_MIDDLE) | BIT(BTN_RIGHT) },
	relbit:		{ BIT(REL_X) | BIT(REL_Y) },
	open:		logibm_open,
	close:		logibm_close,
	name:		"Logitech bus mouse",
	idbus:		BUS_ISA,
	idvendor:	0x0002,
	idproduct:	0x0001,
	idversion:	0x0100,
};

static void logibm_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
	char dx, dy;
	unsigned char buttons;

	outb(LOGIBM_READ_X_LOW, LOGIBM_CONTROL_PORT);
	dx = (inb(LOGIBM_DATA_PORT) & 0xf);
	outb(LOGIBM_READ_X_HIGH, LOGIBM_CONTROL_PORT);
	dx |= (inb(LOGIBM_DATA_PORT) & 0xf) << 4;
	outb(LOGIBM_READ_Y_LOW, LOGIBM_CONTROL_PORT);
	dy = (inb(LOGIBM_DATA_PORT) & 0xf);
	outb(LOGIBM_READ_Y_HIGH, LOGIBM_CONTROL_PORT);
	buttons = inb(LOGIBM_DATA_PORT);
	dy |= (buttons & 0xf) << 4;
	buttons = ~buttons;

	input_report_rel(&logibm_dev, REL_X, dx);
	input_report_rel(&logibm_dev, REL_Y, 255 - dy);
	input_report_key(&logibm_dev, BTN_MIDDLE, buttons & 1);
	input_report_key(&logibm_dev, BTN_LEFT,   buttons & 2);
	input_report_key(&logibm_dev, BTN_RIGHT,  buttons & 4);
}

#ifndef MODULE
static int __init logibm_setup(char *str)
{
        int ints[4];
        str = get_options(str, ARRAY_SIZE(ints), ints);
        if (ints[0] > 0) logibm_irq = ints[1];
        return 1;
}
__setup("logibm_irq=", logibm_setup);
#endif

static int __init logibm_init(void)
{
	if (request_region(LOGIBM_BASE, LOGIBM_EXTENT, "logibm")) {
		printk(KERN_ERR "logibm.c: Can't allocate ports at %#x\n", LOGIBM_BASE);
		return -EBUSY;
	}

	outb(LOGIBM_CONFIG_BYTE, LOGIBM_CONFIG_PORT);
	outb(LOGIBM_SIGNATURE_BYTE, LOGIBM_SIGNATURE_PORT);
	udelay(100);

	if (inb(LOGIBM_SIGNATURE_PORT) != LOGIBM_SIGNATURE_BYTE) {
		release_region(LOGIBM_BASE, LOGIBM_EXTENT);
		printk(KERN_ERR "logibm.c: Didn't find Logitech busmouse at %#x\n", LOGIBM_BASE);
		return -ENODEV;
	}

	outb(LOGIBM_DEFAULT_MODE, LOGIBM_CONFIG_PORT);
	outb(LOGIBM_DISABLE_IRQ, LOGIBM_CONTROL_PORT);

	input_register_device(&logibm_dev);

	printk(KERN_INFO "input%d: Logitech bus mouse at %#x irq %d\n",
		logibm_dev.number, LOGIBM_BASE, logibm_irq);

	return 0;
}

static void __exit logibm_exit(void)
{
	input_unregister_device(&logibm_dev);
	release_region(LOGIBM_BASE, LOGIBM_EXTENT);
}

module_init(logibm_init);
module_exit(logibm_exit);

mouse problems in 2.4.2

[linas]

Hi,

I am experiencing debilitating intermittent mouse problems & was about 
to dive into the kernel to see if I could debug it.  But first, I thought
a quick note to the mailing list may help.

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 did not occur with 2.4.0test2 or 2.2.16 (to the best of my
recollection) and first showed up in 2.4.0test7 or 2.4.1 (not sure).
With 2.4.2, the symptoms seem slightly different (almost all pointer
movement events seem to be lost; although spurious button-press events
still happen).

Mouse is a logitech trackman marble, with USB connector to
logitech-supplied USB to ps/2 DIN plug.  Configured as a PS/2 mouse.
Motherboard is a Athalon/VIA Apollo KA7.

Unplugging mouse for 10 seconds sometimes fixes the problem on the sixth
try, sometimes. 

Switching to virtual terminal running gpm, and back to X11 used to fix
the problem, sometimes, after some magic incantations, unplugging,
starting gpm, moving mouse, etc.  This no longer does the trick w/
2.4.2.

Rebooting X11 frequently, but not always, fixed the problem.

The *only* sure-fire fix is to reboot the system. 

Sometimes, the mouse seemed usable with gpm even as it wasn't with X11;
sometimes it had the same bad behaviour (scooting to the corner,
spurious button-press) even under gpm.

Changing mouse protocols to imps2 from ps2 in gpm/X11 seems to make no
difference.

Disabling power management in kernel and bios to various degrees (including 
disabling *all* power management) doesn't seem to fix anything.  (It
was suggested to me that this was an APM bug; indeed, an early
manifestation of the bug seemed to be that it triggered if/when I moved
the mouse just as the video-powersave triggered. )

Sometimes, the problem seems to be associated with moving the mouse
during CPU-intensive or disk-i/o intensive operations (e.g. a large 
file copy, compile; or system activity during mp3 playing) Lost
interrupt?

On rare ocasions, its associated with system lockup.  (specifically,
some keyboard buffer seems to fill up, and everything seems hung,  
not even ctrl-alt-del works).  (I haven't checked to see if I can 
still telnet in). 

I've been living with this problem for 6+ months, and it is getting to
be infuriating.  As you can see above, all sorts of different attempts
above make subtle variations in the symptoms, but no fixes.  

I conclude that this is probably a hardware (motherboard chipset)
bug, that its rare (google/deja  searches are unfruitful) and that 
the only place to hunt is in the kernel. 

---------------
So: any advice, comments, suggestions before I embark on a long and
possibly fruitless hunt?  Any recommendations for best tools/proceedures
to catch it 'in the act'?  

--linas

p.s. direct replies to linas@linas.org appreciated.

Re: mouse problems in 2.4.2 -> lost byte

[Gunther Mayer]

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

linas@linas.org wrote:

> 
> 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.
(Some mouse protocols are even designed to allow
 easy resync/recovery by fixed bit patterns!)

Write an intelligent mouse driver for XFree86 to compensate for
lost bytes. 

Regards, Gunther

APPENDIX
========

Output ot litte test program:
> a.out
Simulating 1 lost byte
    1 -- ff 00 08 ---   -256 : -248   Buttons=MRL Overflow/errors:XY 
    2 -- 00 04 08 ---      4 :    8   Buttons=    Overflow/errors:  T
    3 -- 00 04 08 ---      4 :    8   Buttons=    Overflow/errors:  T
    4 -- 00 03 08 ---      3 :    8   Buttons=    Overflow/errors:  T
    5 -- 00 03 18 ---      3 :   24   Buttons=    Overflow/errors:  T
    6 -- ff 02 08 ---   -254 : -248   Buttons=MRL Overflow/errors:XY 
    7 -- 00 02 08 ---      2 :    8   Buttons=    Overflow/errors:  T
    8 -- 00 03 18 ---      3 :   24   Buttons=    Overflow/errors:  T
    9 -- ff 03 18 ---   -253 : -232   Buttons=MRL Overflow/errors:XY 
   10 -- ff 03 08 ---   -253 : -248   Buttons=MRL Overflow/errors:XY 
...

Probably XFree ignores data packets with XY overflow set. All other
packets move you to top-right corner.

Moving your mouse will quickly show button mania, as described by your post.

[-- Attachment #2: gm_psauxprint.c --]
[-- Type: application/octet-stream, Size: 771 bytes --]

// show effects of lost bytes on ps/2 mouse protocol 
#include <stdio.h>
#include <errno.h>
int main(void)
{ 
	FILE *f;
	int i=0,x,a,y, xo,yo,xs,ys,r,m,l,t,dx,dy;

	f=fopen("/dev/psaux","r");
	if(f==NULL) strerror(errno);

 //printf("Simulating 2 lost bytes\n");
 //a=fgetc(f); a=fgetc(f);

 printf("Simulating 1 lost byte\n");
 a=fgetc(f);
	while (1) {
		a=fgetc(f);
		x=fgetc(f);
		y=fgetc(f);
		i++;
		printf("%5d -- %02x %02x %02x",i,a,x,y);

		yo=a&0x80;
		xo=a&0x40;
		ys=a&0x20;
		xs=a&0x10;
		t=a&0x08;
		m=a&0x04;
		r=a&0x02;
		l=a&0x01;

		dx=x;
		dy=y;
		if(xs) dx=x-256;
		if(ys) dy=y-256;
		printf(" ---   %4d : %4d   Buttons=%s%s%s Overflow/errors:%s%s%s\n",
			dx,dy,m?"M":" ", r?"R":" ", l?"L":" ",
			xo?"X":" ", yo?"Y":" ", t?" ":"T");
	}
	return 0;
}	

Re: mouse problems in 2.4.2 -> lost byte

[linas]

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 ...  
I'm still investigating to see if the kernel buffer is overflowing ...


--linas

Re: mouse problems in 2.4.2 -> lost byte

[Gunther Mayer]

linas@linas.org 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.

Re: mouse problems in 2.4.2 -> lost byte

[Vojtech Pavlik]

On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote:
> linas@linas.org 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

Re: mouse problems in 2.4.2 -> lost byte

[linas]

It's been rumoured that Vojtech Pavlik said:
> On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote:
> > linas@linas.org wrote:
> > > It's been rumoured that Gunther Mayer said:
> > > > linas@linas.org 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

Re: mouse problems in 2.4.2 -> lost byte

[Vojtech Pavlik]

On Wed, Mar 28, 2001 at 05:19:33PM -0600, linas@linas.org wrote:
> It's been rumoured that Vojtech Pavlik said:
> > On Wed, Mar 28, 2001 at 08:31:52PM +0200, Gunther Mayer wrote:
> > > linas@linas.org wrote:
> > > > It's been rumoured that Gunther Mayer said:
> > > > > linas@linas.org 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