mouse driver bug in 2.6.0-test7?

mouse driver bug in 2.6.0-test7?

[4Front Technologies]

Why is the PS2 mouse tracking about 2x faster in 2.6.0-test7 compared
to 2.4.xx?. Has anybody else seen this problem?.

If I move the mouse 1 inch horizontally left-to-right on the mouse
pad, the cursor on the screen moves almost twice the distance on the
screen compared to Linux 2.4.xx

I'm using the same X11 Config in 2.6 and 2.4....


Best regards
Dev Mazumdar
-----------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
Tel: (310) 202 8530		URL: www.opensound.com
Fax: (310) 202 0496 		Email: info@opensound.com
-----------------------------------------------------------

Re: mouse driver bug in 2.6.0-test7?

[Martin Josefsson]

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

On Tue, 2003-10-14 at 20:04, 4Front Technologies wrote:
> Why is the PS2 mouse tracking about 2x faster in 2.6.0-test7 compared
> to 2.4.xx?. Has anybody else seen this problem?.
> 
> If I move the mouse 1 inch horizontally left-to-right on the mouse
> pad, the cursor on the screen moves almost twice the distance on the
> screen compared to Linux 2.4.xx

It's probably mostly because Vojtech changed the samplerate from 200 to
60. Here's a patch to change it back. I've sent it to Vojtech but he's
completely ignored it so far. This patch also readds the fallback logic
that was used before his change, although it uses the new
samplerate-table.

Without this patch my mouse is awful to use.
Vojtech, please consider this patch, at least say yay or nay.

--- linux-2.6.0-test6-mm4/drivers/input/mouse/psmouse-base.c.orig	2003-10-05 17:02:23.000000000 +0200
+++ linux-2.6.0-test6-mm4/drivers/input/mouse/psmouse-base.c	2003-10-05 17:06:55.000000000 +0200
@@ -40,7 +40,7 @@
 
 static int psmouse_noext;
 int psmouse_resolution;
-unsigned int psmouse_rate = 60;
+unsigned int psmouse_rate = 200;
 int psmouse_smartscroll = PSMOUSE_LOGITECH_SMARTSCROLL;
 unsigned int psmouse_resetafter;
 
@@ -450,6 +450,11 @@
 	int i = 0;
 
 	while (rates[i] > psmouse_rate) i++;
+
+	/* set lower rate in case requested rate fails */
+	if (rates[i])
+		psmouse_command(psmouse, rates + i + 1, PSMOUSE_CMD_SETRATE);
+
 	psmouse_command(psmouse, rates + i, PSMOUSE_CMD_SETRATE);
 }
 

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mouse driver bug in 2.6.0-test7?

[Vojtech Pavlik]

On Tue, Oct 14, 2003 at 09:18:34PM +0200, Martin Josefsson wrote:
> On Tue, 2003-10-14 at 20:04, 4Front Technologies wrote:
> > Why is the PS2 mouse tracking about 2x faster in 2.6.0-test7 compared
> > to 2.4.xx?. Has anybody else seen this problem?.
> > 
> > If I move the mouse 1 inch horizontally left-to-right on the mouse
> > pad, the cursor on the screen moves almost twice the distance on the
> > screen compared to Linux 2.4.xx
> 
> It's probably mostly because Vojtech changed the samplerate from 200 to
> 60. Here's a patch to change it back. I've sent it to Vojtech but he's
> completely ignored it so far. This patch also readds the fallback logic
> that was used before his change, although it uses the new
> samplerate-table.
> 
> Without this patch my mouse is awful to use.
> Vojtech, please consider this patch, at least say yay or nay.

Patch considered. I'll up the samplerate default to 80, but not more,
since samplerates above that cause trouble for a lot of people (keyboard
doesn't work when you're moving the mouse).

The "set lower rate in case ..." part of the patch doesn't make sense.
If the user gives a too low (less than 10) samples per second, then the
original code will try to set 0, which is stupid, but harmless. The
added code will try to access beyond the bounds of the rates[] array.

> --- linux-2.6.0-test6-mm4/drivers/input/mouse/psmouse-base.c.orig	2003-10-05 17:02:23.000000000 +0200
> +++ linux-2.6.0-test6-mm4/drivers/input/mouse/psmouse-base.c	2003-10-05 17:06:55.000000000 +0200
> @@ -40,7 +40,7 @@
>  
>  static int psmouse_noext;
>  int psmouse_resolution;
> -unsigned int psmouse_rate = 60;
> +unsigned int psmouse_rate = 200;
>  int psmouse_smartscroll = PSMOUSE_LOGITECH_SMARTSCROLL;
>  unsigned int psmouse_resetafter;
>  
> @@ -450,6 +450,11 @@
>  	int i = 0;
>  
>  	while (rates[i] > psmouse_rate) i++;
> +
> +	/* set lower rate in case requested rate fails */
> +	if (rates[i])
> +		psmouse_command(psmouse, rates + i + 1, PSMOUSE_CMD_SETRATE);
> +
>  	psmouse_command(psmouse, rates + i, PSMOUSE_CMD_SETRATE);
>  }
>  
> 
> -- 
> /Martin



-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: mouse driver bug in 2.6.0-test7?

[4Front Technologies]

Vojtech Pavlik wrote:
> On Tue, Oct 14, 2003 at 09:18:34PM +0200, Martin Josefsson wrote:
> 
>>On Tue, 2003-10-14 at 20:04, 4Front Technologies wrote:
>>
>>>Why is the PS2 mouse tracking about 2x faster in 2.6.0-test7 compared
>>>to 2.4.xx?. Has anybody else seen this problem?.
>>>
>>>If I move the mouse 1 inch horizontally left-to-right on the mouse
>>>pad, the cursor on the screen moves almost twice the distance on the
>>>screen compared to Linux 2.4.xx
>>
>>It's probably mostly because Vojtech changed the samplerate from 200 to
>>60. Here's a patch to change it back. I've sent it to Vojtech but he's
>>completely ignored it so far. This patch also readds the fallback logic
>>that was used before his change, although it uses the new
>>samplerate-table.
>>
>>Without this patch my mouse is awful to use.
>>Vojtech, please consider this patch, at least say yay or nay.
> 
> 
> Patch considered. I'll up the samplerate default to 80, but not more,
> since samplerates above that cause trouble for a lot of people (keyboard
> doesn't work when you're moving the mouse).
> 
> The "set lower rate in case ..." part of the patch doesn't make sense.
> If the user gives a too low (less than 10) samples per second, then the
> original code will try to set 0, which is stupid, but harmless. The
> added code will try to access beyond the bounds of the rates[] array.


Hi Martin/Vojtech,

Martin, many thanks for your fix - it works perfectly now.

Oddly enough the sample rate of 200 seems to have fixed the problem.
Vojetech,  Martin's fixes are fully functional. If you want to keep it at 80,
I'd recommend that you make the sample rate a module config option so that
users may be able to tweak this for their systems.

The default of 200 has been tested on VIA400 and IntelICH5 systems that I have.
One running Redhat9/2.6.0-test7 and the other running Gentoo 1.4/2.6.0-test7



best regards

Dev Mazumdar
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530   Fax: 310 202 0496   URL: http://www.opensound.com
---------------------------------------------------------------------

Re: mouse driver bug in 2.6.0-test7?

[Vojtech Pavlik]

On Tue, Oct 14, 2003 at 01:04:03PM -0700, 4Front Technologies wrote:

> >Patch considered. I'll up the samplerate default to 80, but not more,
> >since samplerates above that cause trouble for a lot of people (keyboard
> >doesn't work when you're moving the mouse).
> >
> >The "set lower rate in case ..." part of the patch doesn't make sense.
> >If the user gives a too low (less than 10) samples per second, then the
> >original code will try to set 0, which is stupid, but harmless. The
> >added code will try to access beyond the bounds of the rates[] array.
> 
> 
> Hi Martin/Vojtech,
> 
> Martin, many thanks for your fix - it works perfectly now.
> 
> Oddly enough the sample rate of 200 seems to have fixed the problem.
> Vojetech,  Martin's fixes are fully functional.

Not completely. One reason wht the sample rate of 200 probably fixed the
problem is that you have very high acceleration settings in X.

Since with report rate 200 you get a medium speed movement as

+1 +1 +1 +1 +1 +1 +1 +1 +1

events, and with report rate 60 you get

       +3      +3       +3

and the X mouse acceleration code is stupid enough to judge the mouse
speed from the event VALUE only, it thinks the mouse is moving much
faster in the second case.

You need to up the acceleration threshold (or disable acceleration
completely).

This also means that with report rate of 200, mouse acceleration is more
or less disabled, since you get +1's only even at quite high speeds of
mouse movement.

> If you want to keep it at 80,

I don't want to. I like the feel of a mouse at 200 samples per second,
however it causes problems on some hardware, which means I have to stay
with a more reasonable default.

> I'd recommend that you make the sample rate a module config option so that
> users may be able to tweak this for their systems.

It already is. Only the code to make it a kernel command line parameter
(when psmouse is compiled into the kernel) is missing.

> The default of 200 has been tested on VIA400 and IntelICH5 systems that I 
> have.

Yes, new boards don't have any problems with it. It's the older ones
that do.

> One running Redhat9/2.6.0-test7 and the other running Gentoo 1.4/2.6.0-test7

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: mouse driver bug in 2.6.0-test7?

[Martin Josefsson]

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

On Tue, 2003-10-14 at 22:13, Vojtech Pavlik wrote:

> > I'd recommend that you make the sample rate a module config option so that
> > users may be able to tweak this for their systems.
> 
> It already is. Only the code to make it a kernel command line parameter
> (when psmouse is compiled into the kernel) is missing.

If you fix that I'd be happy and I'll stop sending that patch over and
over again... :)

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mouse driver bug in 2.6.0-test7?

[Mika Penttilä]

Why not use the new style module_param thing, goes for compiled-in and 
module stuff.

--Mika


Martin Josefsson wrote:

>On Tue, 2003-10-14 at 22:13, Vojtech Pavlik wrote:
>
>  
>
>>>I'd recommend that you make the sample rate a module config option so that
>>>users may be able to tweak this for their systems.
>>>      
>>>
>>It already is. Only the code to make it a kernel command line parameter
>>(when psmouse is compiled into the kernel) is missing.
>>    
>>
>
>If you fix that I'd be happy and I'll stop sending that patch over and
>over again... :)
>
>  
>

Re: mouse driver bug in 2.6.0-test7?

[4Front Technologies]

Vojtech Pavlik wrote:
> On Tue, Oct 14, 2003 at 01:04:03PM -0700, 4Front Technologies wrote:
> 
> 
>>>Patch considered. I'll up the samplerate default to 80, but not more,
>>>since samplerates above that cause trouble for a lot of people (keyboard
>>>doesn't work when you're moving the mouse).
>>>
>>>The "set lower rate in case ..." part of the patch doesn't make sense.
>>>If the user gives a too low (less than 10) samples per second, then the
>>>original code will try to set 0, which is stupid, but harmless. The
>>>added code will try to access beyond the bounds of the rates[] array.
>>
>>
>>Hi Martin/Vojtech,
>>
>>Martin, many thanks for your fix - it works perfectly now.
>>
>>Oddly enough the sample rate of 200 seems to have fixed the problem.
>>Vojetech,  Martin's fixes are fully functional.
> 
> 
> Not completely. One reason wht the sample rate of 200 probably fixed the
> problem is that you have very high acceleration settings in X.
> 
> Since with report rate 200 you get a medium speed movement as
> 
> +1 +1 +1 +1 +1 +1 +1 +1 +1
> 
> events, and with report rate 60 you get
> 
>        +3      +3       +3
> 
> and the X mouse acceleration code is stupid enough to judge the mouse
> speed from the event VALUE only, it thinks the mouse is moving much
> faster in the second case.
> 
> You need to up the acceleration threshold (or disable acceleration
> completely).
> 
> This also means that with report rate of 200, mouse acceleration is more
> or less disabled, since you get +1's only even at quite high speeds of
> mouse movement.
> 


Vojtec/Martin

You're right, the original problem still remains. The tracking is still
2x compared to Linux 2.4.

Here's how I did the measurement.
Get a foot-scale and start xev. Ajust xev so that the coordiates of the
window are 0,y (y is y-axis - don't care) in the X root window (my res is 1024x768).

Now align the mouse so that it shows 0,0 on the top left corner in the xev window
and move the mouse exactly one 1 inch and you'll see that under Linux 2.6.0-test7
the x axis position is at something like 325. However repeating the same test under
Linux 2.4.22 puts the mouse at x axis position 170 (gives me a accelearation factor
of about 2x).

This is a horribly crude test but it explains my problem that the mouse driver isn't
tracking correctly.


Hope this helps figuring out the problem.


best regards

Dev Mazumdar
---------------------------------------------------------------------
4Front Technologies
4035 Lafayette Place, Unit F, Culver City, CA 90232, USA
Tel: 310 202 8530   Fax: 310 202 0496   URL: http://www.opensound.com
---------------------------------------------------------------------

Re: mouse driver bug in 2.6.0-test7?

[Eric Wong]

Vojtech Pavlik <vojtech@suse.cz> wrote:
> On Tue, Oct 14, 2003 at 01:04:03PM -0700, 4Front Technologies wrote:
> > I'd recommend that you make the sample rate a module config option so that
> > users may be able to tweak this for their systems.
> 
> It already is. Only the code to make it a kernel command line parameter
> (when psmouse is compiled into the kernel) is missing.

I could've sworn I had this in one of the patches I sent you, but
perhaps not.

--- drivers/input/mouse/psmouse-base.c~	2003-10-13 06:13:52.000000000 +0000
+++ drivers/input/mouse/psmouse-base.c	2003-10-15 00:21:59.000000000 +0000
@@ -651,10 +651,17 @@
 	return 1;
 }
 
+static int __init psmouse_rate_setup(char *str)
+{
+	get_option(&str, &psmouse_rate);
+	return 1;
+}
+
 __setup("psmouse_noext", psmouse_noext_setup);
 __setup("psmouse_resolution=", psmouse_resolution_setup);
 __setup("psmouse_smartscroll=", psmouse_smartscroll_setup);
 __setup("psmouse_resetafter=", psmouse_resetafter_setup);
+__setup("psmouse_rate=", psmouse_rate_setup);
 
 #endif
 
-- 
Eric Wong

Re: mouse driver bug in 2.6.0-test7?

[Vojtech Pavlik]

On Wed, Oct 15, 2003 at 12:48:37AM +0000, Eric Wong wrote:

> Vojtech Pavlik <vojtech@suse.cz> wrote:
> > On Tue, Oct 14, 2003 at 01:04:03PM -0700, 4Front Technologies wrote:
> > > I'd recommend that you make the sample rate a module config option so that
> > > users may be able to tweak this for their systems.
> > 
> > It already is. Only the code to make it a kernel command line parameter
> > (when psmouse is compiled into the kernel) is missing.
> 
> I could've sworn I had this in one of the patches I sent you, but
> perhaps not.

Most likely you did. I'll be making a fix-only patch set for Linus today.

> --- drivers/input/mouse/psmouse-base.c~	2003-10-13 06:13:52.000000000 +0000
> +++ drivers/input/mouse/psmouse-base.c	2003-10-15 00:21:59.000000000 +0000
> @@ -651,10 +651,17 @@
>  	return 1;
>  }
>  
> +static int __init psmouse_rate_setup(char *str)
> +{
> +	get_option(&str, &psmouse_rate);
> +	return 1;
> +}
> +
>  __setup("psmouse_noext", psmouse_noext_setup);
>  __setup("psmouse_resolution=", psmouse_resolution_setup);
>  __setup("psmouse_smartscroll=", psmouse_smartscroll_setup);
>  __setup("psmouse_resetafter=", psmouse_resetafter_setup);
> +__setup("psmouse_rate=", psmouse_rate_setup);
>  
>  #endif
>  
> -- 
> Eric Wong

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR