[PATCH] mousedev: Fix scrollwheel thingy on IBM ScrollPoint mice

[PATCH] mousedev: Fix scrollwheel thingy on IBM ScrollPoint mice

[Kim Holviala]

The scrollwheel thingy (stick) on IBM ScrollPoint mice returns extremely
aggressive values even when touched lightly. This confuses XFree which
assumes the wheel values can only be 1 or -1. Incidently, it also
confuses Windows' default mouse driver which proves the problem is in
the mouse itself.

This patch limits the scroll wheel movements to be either +1 or -1 on
the event -> emulated PS/2 level. I chose to implement it there because
mousedev emulates Microsoft mice but the real ones almoust never return
a bigger value than 1 (or -1).

Kim



diff -ruN linux-2.6.8.1-original/drivers/input/Kconfig linux-2.6.8.1/drivers/input/Kconfig
--- linux-2.6.8.1-original/drivers/input/Kconfig	2004-10-26 08:42:30.000000000 +0300
+++ linux-2.6.8.1/drivers/input/Kconfig	2004-10-26 09:54:58.000000000 +0300
@@ -72,6 +72,17 @@
  	  screen resolution you are using to correctly scale the data. If
  	  you're not using a digitizer, this value is ignored.

+config INPUT_MOUSEDEV_WHEELFIX
+	bool "Limit too fast wheel movement"
+	depends on INPUT_MOUSEDEV
+	default n
+	help
+	  Say Y here if your mouse wheel only works randomly or if it scrolls
+	  too fast. Some mice, like IBM's scrollpoints, return too big wheel
+	  movement values which confuse programs like XFree.
+
+	  If your mouse wheel thingy works as advertised, say N.
+
  config INPUT_JOYDEV
  	tristate "Joystick interface"
  	depends on INPUT
diff -ruN linux-2.6.8.1-original/drivers/input/mousedev.c linux-2.6.8.1/drivers/input/mousedev.c
--- linux-2.6.8.1-original/drivers/input/mousedev.c	2004-10-26 08:42:31.000000000 +0300
+++ linux-2.6.8.1/drivers/input/mousedev.c	2004-10-26 11:21:01.000000000 +0300
@@ -137,7 +137,11 @@
  	switch (code) {
  		case REL_X:	mousedev->packet.dx += value; break;
  		case REL_Y:	mousedev->packet.dy -= value; break;
-		case REL_WHEEL:	mousedev->packet.dz -= value; break;
+		case REL_WHEEL:
+#ifdef CONFIG_INPUT_MOUSEDEV_WHEELFIX
+				if (value) { value = (value < 0 ? -1 : 1); }
+#endif /* CONFIG_INPUT_MOUSEDEV_WHEELFIX */
+				mousedev->packet.dz -= value; break;
  	}
  }

Re: [PATCH] mousedev: Fix scrollwheel thingy on IBM ScrollPoint mice

[Andrew Morton]

Kim Holviala <kim@holviala.com> wrote:
>
> The scrollwheel thingy (stick) on IBM ScrollPoint mice returns extremely
> aggressive values even when touched lightly. This confuses XFree which
> assumes the wheel values can only be 1 or -1. Incidently, it also
> confuses Windows' default mouse driver which proves the problem is in
> the mouse itself.
> 
> This patch limits the scroll wheel movements to be either +1 or -1 on
> the event -> emulated PS/2 level. I chose to implement it there because
> mousedev emulates Microsoft mice but the real ones almoust never return
> a bigger value than 1 (or -1).
> ...
> +#ifdef CONFIG_INPUT_MOUSEDEV_WHEELFIX
> +				if (value) { value = (value < 0 ? -1 : 1); }
> +#endif /* CONFIG_INPUT_MOUSEDEV_WHEELFIX */

This is really not a thing which we can put behind compile-time config.

Can we come up with a fix which works correctly on all hardware?  If not,
this workaround will need to be enabled by some sort of runtime detection.

Re: [PATCH] mousedev: Fix scrollwheel thingy on IBM ScrollPoint mice

[Dmitry Torokhov]

On Tuesday 26 October 2004 07:11 pm, Andrew Morton wrote:
> Kim Holviala <kim@holviala.com> wrote:
> >
> > The scrollwheel thingy (stick) on IBM ScrollPoint mice returns extremely
> > aggressive values even when touched lightly. This confuses XFree which
> > assumes the wheel values can only be 1 or -1. Incidently, it also
> > confuses Windows' default mouse driver which proves the problem is in
> > the mouse itself.
> > 
> > This patch limits the scroll wheel movements to be either +1 or -1 on
> > the event -> emulated PS/2 level. I chose to implement it there because
> > mousedev emulates Microsoft mice but the real ones almoust never return
> > a bigger value than 1 (or -1).
> > ...
> > +#ifdef CONFIG_INPUT_MOUSEDEV_WHEELFIX
> > +				if (value) { value = (value < 0 ? -1 : 1); }
> > +#endif /* CONFIG_INPUT_MOUSEDEV_WHEELFIX */
> 
> This is really not a thing which we can put behind compile-time config.
> 
> Can we come up with a fix which works correctly on all hardware?  If not,
> this workaround will need to be enabled by some sort of runtime detection.
> 

Unless someone (Vojtech?) has an objection I think we should always have
this workaround activated - after all mousedev provides legacy emulation
mostly for XFree/XOrg benefit anyway. Clients accessing data through evdev
will see the full picture regardless.

-- 
Dmitry

Re: [PATCH] mousedev: Fix scrollwheel thingy on IBM ScrollPoint mice

[Vojtech Pavlik]

On Tue, Oct 26, 2004 at 07:33:50PM -0500, Dmitry Torokhov wrote:

> > > This patch limits the scroll wheel movements to be either +1 or -1 on
> > > the event -> emulated PS/2 level. I chose to implement it there because
> > > mousedev emulates Microsoft mice but the real ones almoust never return
> > > a bigger value than 1 (or -1).
> > > ...
> > > +#ifdef CONFIG_INPUT_MOUSEDEV_WHEELFIX
> > > +				if (value) { value = (value < 0 ? -1 : 1); }
> > > +#endif /* CONFIG_INPUT_MOUSEDEV_WHEELFIX */
> > 
> > This is really not a thing which we can put behind compile-time config.
> > 
> > Can we come up with a fix which works correctly on all hardware?  If not,
> > this workaround will need to be enabled by some sort of runtime detection.
> > 
> 
> Unless someone (Vojtech?) has an objection I think we should always have
> this workaround activated - after all mousedev provides legacy emulation
> mostly for XFree/XOrg benefit anyway. Clients accessing data through evdev
> will see the full picture regardless.
 
We can have a workaround for XOrg, but not one like this. This will make
fast scrolling unreliable. I have standard Microsoft-compatible mice
which do report more than one scroll tick per report, if you scroll the
wheel fast enough, and this throws away the extra ticks.

We would have to split the value into multiple events which would each
report a 1 or -1.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [PATCH] mousedev: Fix scrollwheel thingy on IBM ScrollPoint mice

[Dmitry Torokhov]

On Wednesday 27 October 2004 12:51 am, Vojtech Pavlik wrote:
> On Tue, Oct 26, 2004 at 07:33:50PM -0500, Dmitry Torokhov wrote:
> 
> > > > This patch limits the scroll wheel movements to be either +1 or -1 on
> > > > the event -> emulated PS/2 level. I chose to implement it there because
> > > > mousedev emulates Microsoft mice but the real ones almoust never return
> > > > a bigger value than 1 (or -1).
> > > > ...
> > > > +#ifdef CONFIG_INPUT_MOUSEDEV_WHEELFIX
> > > > +				if (value) { value = (value < 0 ? -1 : 1); }
> > > > +#endif /* CONFIG_INPUT_MOUSEDEV_WHEELFIX */
> > > 
> > > This is really not a thing which we can put behind compile-time config.
> > > 
> > > Can we come up with a fix which works correctly on all hardware?  If not,
> > > this workaround will need to be enabled by some sort of runtime detection.
> > > 
> > 
> > Unless someone (Vojtech?) has an objection I think we should always have
> > this workaround activated - after all mousedev provides legacy emulation
> > mostly for XFree/XOrg benefit anyway. Clients accessing data through evdev
> > will see the full picture regardless.
>  
> We can have a workaround for XOrg, but not one like this. This will make
> fast scrolling unreliable. I have standard Microsoft-compatible mice
> which do report more than one scroll tick per report, if you scroll the
> wheel fast enough, and this throws away the extra ticks.
> 
> We would have to split the value into multiple events which would each
> report a 1 or -1.
> 

I have taken a look at XFree/XOrg sources and it seems that they should
not have -1/1 problem but values outside of limits allowed for Intellimouse
or Explorer protocols will cause re-evaluation of protocol mode. We probably
just clamp values to protocol limits (-8/+7 for intellimouse and explorer
modes) and be done with it.

-- 
Dmitry

Re: [PATCH] mousedev: Fix scrollwheel thingy on IBM ScrollPoint mice

[Kim Holviala]

Vojtech Pavlik wrote:

>>>>This patch limits the scroll wheel movements to be either +1 or -1 on
>>>>the event -> emulated PS/2 level. I chose to implement it there because
>>>>mousedev emulates Microsoft mice but the real ones almoust never return
>>>>a bigger value than 1 (or -1).
>>>>...
>>>>+#ifdef CONFIG_INPUT_MOUSEDEV_WHEELFIX
>>>>+				if (value) { value = (value < 0 ? -1 : 1); }
>>>>+#endif /* CONFIG_INPUT_MOUSEDEV_WHEELFIX */
>>>
>>>This is really not a thing which we can put behind compile-time config.
>>>
>>>Can we come up with a fix which works correctly on all hardware?  If not,
>>>this workaround will need to be enabled by some sort of runtime detection.
>>>
>>
>>Unless someone (Vojtech?) has an objection I think we should always have
>>this workaround activated - after all mousedev provides legacy emulation
>>mostly for XFree/XOrg benefit anyway. Clients accessing data through evdev
>>will see the full picture regardless.
> 
>  
> We can have a workaround for XOrg, but not one like this. This will make
> fast scrolling unreliable. I have standard Microsoft-compatible mice
> which do report more than one scroll tick per report, if you scroll the
> wheel fast enough, and this throws away the extra ticks.

It wasn't an optimal solution, but just a quick hack that made the 
scrollpoint usable. BTW, I've tried with about a dozen wheelmice and all 
of them needed real misuse to get a packet where the scroll amount was 
more than 1....

Not that I'm claiming that those kind of mice don't exist. They do, one 
of them is this ScrollPoint that I'm using now.

> We would have to split the value into multiple events which would each
> report a 1 or -1.

That would be the right solution - I thought about it but deciced not to 
steal any more of my employers time.... Besides, I needed to slow the 
wheel/stick action down anyway since a light touch of the stick 
generates insane scroll events. In Windows with the default driver the 
stick operated like Home/End...



Kim

Re: [PATCH] mousedev: Fix scrollwheel thingy on IBM ScrollPoint mice

[Kim Holviala]

Kim Holviala wrote:

>>>>> This patch limits the scroll wheel movements to be either +1 or -1 on
>>>>> the event -> emulated PS/2 level. I chose to implement it there 
>>>>> because
>>>>> mousedev emulates Microsoft mice but the real ones almoust never 
>>>>> return
>>>>> a bigger value than 1 (or -1).
>>>>> ...
>>>>> +#ifdef CONFIG_INPUT_MOUSEDEV_WHEELFIX
>>>>> +                if (value) { value = (value < 0 ? -1 : 1); }
>>>>> +#endif /* CONFIG_INPUT_MOUSEDEV_WHEELFIX */
>>>>
>>  
>> We can have a workaround for XOrg, but not one like this. This will make
>> fast scrolling unreliable. I have standard Microsoft-compatible mice
>> which do report more than one scroll tick per report, if you scroll the
>> wheel fast enough, and this throws away the extra ticks.

One more comment to the scrollpoint issue: if they haven't fixed it 
after 4.3.something XFree throws away all scroll events where the scroll 
amount is more than 1. So "fast scrolling" is already unreliable, this 
patch just made it work somehow instead of what it's doing now: not 
working at all.



Kim