Touchpad problems with 2.6.11-rc2

Touchpad problems with 2.6.11-rc2

[Pete Zaitcev]

Hi, Vojtech:

Since the 2.6.11-rc2, I encounter problems with touchpad and keyboard 
on my laptop, Dell Lattitude D600. The following patch appears to be
the culprit:

diff -urp -X dontdiff linux-2.6.11-rc1/drivers/input/mouse/psmouse-base.c linux-2.6.11-rc2/drivers/input/mouse/psmouse-base.c
--- linux-2.6.11-rc1/drivers/input/mouse/psmouse-base.c	2005-01-12 16:20:42.000000000 -0800
+++ linux-2.6.11-rc2/drivers/input/mouse/psmouse-base.c	2005-01-22 14:54:14.000000000 -0800
@@ -451,14 +451,16 @@ static int psmouse_extensions(struct psm
 /*
  * Try ALPS TouchPad
  */
-	if (max_proto > PSMOUSE_IMEX && alps_detect(psmouse, set_properties) == 0) {
-		if (!set_properties || alps_init(psmouse) == 0)
-			return PSMOUSE_ALPS;
-
+	if (max_proto > PSMOUSE_IMEX) {
+		ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS);
+		if (alps_detect(psmouse, set_properties) == 0) {
+			if (!set_properties || alps_init(psmouse) == 0)
+				return PSMOUSE_ALPS;
 /*
  * Init failed, try basic relative protocols
  */
-		max_proto = PSMOUSE_IMEX;
+			max_proto = PSMOUSE_IMEX;
+		}
 	}
 
 	if (max_proto > PSMOUSE_IMEX && genius_detect(psmouse, set_properties) == 0)

Without the patch, touchpad is not detected as such. Instead, dmesg shows:

input: PS/2 Generic Mouse on isa0060/serio1

With this patch, I see this:

ALPS Touchpad (Dualpoint) detected
  Disabling hardware tapping
input: AlpsPS/2 ALPS TouchPad on isa0060/serio1

Looks like detection is correct, however either ALPS specific code doesn't work
right, or it sets wrong parameters, I cannot tell. Here's the list of problems,
from worst to least annoying:

- Very often, keyboard stops working after a click. Typing anything has no effect.
  However, any smallest pointer movement will restore keyboard, and then an
  application receives all buffered characters. This is very bad.

- Double-click sometimes fails to work. I have to wait a second and retry it.
  Retrying right away is likely not to work again.

- Slow motion of finger produces no motion, then a jump. So, it's very hard to
  target smaller UI elements and some web links.

I do not use the nipple, so I cannot tell if that one works or worked before.

Not everything is bad. For example, old input code (in 2.6.10) sometimes "warped"
mouse to the bottom of the screen, or confused motion with clicks. This problem
appears to be gone now. It would be just great if you could look into keyboard
stoppages, too.

Have a great day,
-- Pete

P.S. I hate the tap, so keep it disabled by default, please :-)

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

Pete Zaitcev <zaitcev@redhat.com> writes:

> Since the 2.6.11-rc2, I encounter problems with touchpad and keyboard 
> on my laptop, Dell Lattitude D600. The following patch appears to be
> the culprit:

[alps touchpad detection fix patch]

> Without the patch, touchpad is not detected as such. Instead, dmesg shows:
> 
> input: PS/2 Generic Mouse on isa0060/serio1
> 
> With this patch, I see this:
> 
> ALPS Touchpad (Dualpoint) detected
>   Disabling hardware tapping
> input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
> 
> Looks like detection is correct, however either ALPS specific code doesn't work
> right, or it sets wrong parameters, I cannot tell. Here's the list of problems,
> from worst to least annoying:

I have posted 4 patches to LKML earlier today. Some of them might fix
some of your problems.

> - Very often, keyboard stops working after a click. Typing anything has no effect.
>   However, any smallest pointer movement will restore keyboard, and then an
>   application receives all buffered characters. This is very bad.

It would be interesting to know at which level the problem appears.
Can you reproduce the problem using "xev"? If xev works as expected,
the problem is possibly that the left mouse button gets stuck and
stops your application from accepting keyboard input. This patch fixes
the button stuck problem:

        [PATCH 1/4] Make mousedev.c report all events to user space immediately

If the keyboard gets stuck also using "xev", the problem is at a lower
level. Enable i8042_debug in drivers/input/serio/i8042.c to see if the
keyboards produces any data in the stuck state.

> - Double-click sometimes fails to work. I have to wait a second and retry it.
>   Retrying right away is likely not to work again.

Probably fixed by this patch:

        [PATCH 2/4] Enable hardware tapping for ALPS touchpads

> - Slow motion of finger produces no motion, then a jump. So, it's very hard to
>   target smaller UI elements and some web links.

I see this too when I don't use the X touchpad driver. With the X
driver there is no problem. I think the problem is that mousedev.c in
the kernel has to use integer arithmetic, so probably small movements
are rounded off to 0. I'll try to come up with a fix for this.

> P.S. I hate the tap, so keep it disabled by default, please :-)

You can disable tapping by setting the tap_time parameter for
mousedev.c to 0. The default value is 200ms.

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Pete Zaitcev]

Hello, Peter:

The keyboard seems to work now, but I stepped on a very strange condition.
Suddenly, touchpad motions started to cause wild movements in it became
impossible to do anything due to a focus loss (of course, I had plenty of
modified files open :-)

The dmesg looked like this:

psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.

Now I'm afraid to run that kernel again (2.6.11-rc2 + your patches
1/4 and 2/4).

I run that kernel with hardware tap disabled (tap_time = 0).

-- Pete

Re: Touchpad problems with 2.6.11-rc2

[Dmitry Torokhov]

On Monday 31 January 2005 18:15, Pete Zaitcev wrote:
> Hello, Peter:
> 
> The keyboard seems to work now, but I stepped on a very strange condition.
> Suddenly, touchpad motions started to cause wild movements in it became
> impossible to do anything due to a focus loss (of course, I had plenty of
> modified files open :-)
> 
> The dmesg looked like this:
> 
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> 

1. Have you tried using external PS/2 mouse?
2. Have you plugged/unplugged into a port replicator?

2nd can be cured with psmouse.resetafter=3 (at least until we get
dock support in ACPI as pluggin/unplugging resets keyboard controller
and all devices without telling anyone), first one seems to be hopeless.
External device in Dells (at least in my Inspiron 8100) completely
shadows touchpad.

-- 
Dmitry

Re: Touchpad problems with 2.6.11-rc2

[Pete Zaitcev]

On Mon, 31 Jan 2005 22:40:35 -0500, Dmitry Torokhov <dtor_core@ameritech.net> wrote:

> > Suddenly, touchpad motions started to cause wild movements in it became
> > impossible to do anything due to a focus loss (of course, I had plenty of
> > modified files open :-)

> > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> > psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> > psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.

> 1. Have you tried using external PS/2 mouse?
> 2. Have you plugged/unplugged into a port replicator?

I have Dell Latitude D600, which does not have an external PS/2 port.

But actually, I was caught away from home, working from a library, so I did
not have either PS/2 or USB mouse. I moved the cursor persistently for a
few minutes until I managed to raise a window in such way that it got the
focus, then I saved all files and closed all windows from the keyboard,
so no harm done, no problem.

The kernel was running without resetafter set, unfortunately.

If you have a patch which prints offending data from pktbuffer, I can
run that next time.

Have a great day,
-- Pete

Re: Touchpad problems with 2.6.11-rc2

[Dmitry Torokhov]

On Tuesday 01 February 2005 00:06, Pete Zaitcev wrote:
> On Mon, 31 Jan 2005 22:40:35 -0500, Dmitry Torokhov <dtor_core@ameritech.net> wrote:
> 
> > > Suddenly, touchpad motions started to cause wild movements in it became
> > > impossible to do anything due to a focus loss (of course, I had plenty of
> > > modified files open :-)
> 
> > > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> > > psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> > > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 3
> > > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> > > psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> > > psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
> 
> > 1. Have you tried using external PS/2 mouse?
> > 2. Have you plugged/unplugged into a port replicator?
> 
> I have Dell Latitude D600, which does not have an external PS/2 port.
> 
> But actually, I was caught away from home, working from a library, so I did
> not have either PS/2 or USB mouse. I moved the cursor persistently for a
> few minutes until I managed to raise a window in such way that it got the
> focus, then I saved all files and closed all windows from the keyboard,
> so no harm done, no problem.
> 
> The kernel was running without resetafter set, unfortunately.
> 
> If you have a patch which prints offending data from pktbuffer, I can
> run that next time.
> 

No I don't but by the looks of it (constant stream of bad data) it looks
like somehow the touhcpad was reset back into PS/2 compatibility mode.
resetafter would catch it and reinitialize touchpad restoring proper
protocol.

-- 
Dmitry

Re: Touchpad problems with 2.6.11-rc2

[Pete Zaitcev]

On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <petero2@telia.com> wrote:

> > - Slow motion of finger produces no motion, then a jump. So, it's very hard to
> >   target smaller UI elements and some web links.
> 
> I see this too when I don't use the X touchpad driver. With the X
> driver there is no problem. I think the problem is that mousedev.c in
> the kernel has to use integer arithmetic, so probably small movements
> are rounded off to 0. I'll try to come up with a fix for this.

Thanks for the hint. I tried various schemes and mathematical transformations
and found one which gives unquestionably the best result, with smoothest, most
precise and comfortable pointer movement:

--- linux-2.6.11-rc2/drivers/input/mousedev.c	2005-01-22 14:54:14.000000000 -0800
+++ linux-2.6.11-rc2-lem/drivers/input/mousedev.c	2005-02-01 23:20:19.000000000 -0800
@@ -122,19 +122,19 @@ static void mousedev_touchpad_event(stru
 	if (mousedev->touch) {
 		switch (code) {
 			case ABS_X:
-				size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
-				if (size == 0) size = xres;
 				fx(0) = value;
 				if (mousedev->pkt_count >= 2)
-					mousedev->packet.dx = ((fx(0) - fx(1)) / 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+					mousedev->packet.dx = (value - fx(2)) / 2;
+				else if (mousedev->pkt_count == 1)
+					mousedev->packet.dx = value - fx(1);
 				break;
 
 			case ABS_Y:
-				size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];
-				if (size == 0) size = yres;
 				fy(0) = value;
 				if (mousedev->pkt_count >= 2)
-					mousedev->packet.dy = -((fy(0) - fy(1)) / 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+					mousedev->packet.dy = (fy(2) - value) / 2;
+				else if (mousedev->pkt_count == 1)
+					mousedev->packet.dy = fy(1) - value;
 				break;
 		}
 	}

I'm not kidding. Someone obviously outsmarted himself when programming this.

-- Pete

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Tue, Feb 01, 2005 at 11:41:48PM -0800, Pete Zaitcev wrote:
> On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <petero2@telia.com> wrote:
> 
> > > - Slow motion of finger produces no motion, then a jump. So, it's very hard to
> > >   target smaller UI elements and some web links.
> > 
> > I see this too when I don't use the X touchpad driver. With the X
> > driver there is no problem. I think the problem is that mousedev.c in
> > the kernel has to use integer arithmetic, so probably small movements
> > are rounded off to 0. I'll try to come up with a fix for this.
> 
> Thanks for the hint. I tried various schemes and mathematical transformations
> and found one which gives unquestionably the best result, with smoothest, most
> precise and comfortable pointer movement:

Well, you removed the scaling to the touchpad resolution, which will
cause ALPS touchpad to be significantly slower than Synaptics touchpads.
Similarly, the screen size used to be taken into account, but probably
that was a mistake, since the value is usually left at default and
doesn't correspond to the real screen size.

> --- linux-2.6.11-rc2/drivers/input/mousedev.c	2005-01-22 14:54:14.000000000 -0800
> +++ linux-2.6.11-rc2-lem/drivers/input/mousedev.c	2005-02-01 23:20:19.000000000 -0800
> @@ -122,19 +122,19 @@ static void mousedev_touchpad_event(stru
>  	if (mousedev->touch) {
>  		switch (code) {
>  			case ABS_X:
> -				size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
> -				if (size == 0) size = xres;
>  				fx(0) = value;
>  				if (mousedev->pkt_count >= 2)
> -					mousedev->packet.dx = ((fx(0) - fx(1)) / 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
> +					mousedev->packet.dx = (value - fx(2)) / 2;
> +				else if (mousedev->pkt_count == 1)
> +					mousedev->packet.dx = value - fx(1);
>  				break;
>  
>  			case ABS_Y:
> -				size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];
> -				if (size == 0) size = yres;
>  				fy(0) = value;
>  				if (mousedev->pkt_count >= 2)
> -					mousedev->packet.dy = -((fy(0) - fy(1)) / 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
> +					mousedev->packet.dy = (fy(2) - value) / 2;
> +				else if (mousedev->pkt_count == 1)
> +					mousedev->packet.dy = fy(1) - value;
>  				break;
>  		}
>  	}
> 
> I'm not kidding. Someone obviously outsmarted himself when programming this.
 
-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Dmitry Torokhov]

On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> On Tue, Feb 01, 2005 at 11:41:48PM -0800, Pete Zaitcev wrote:
> > On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <petero2@telia.com> wrote:
> >
> > > > - Slow motion of finger produces no motion, then a jump. So, it's very hard to
> > > >   target smaller UI elements and some web links.
> > >
> > > I see this too when I don't use the X touchpad driver. With the X
> > > driver there is no problem. I think the problem is that mousedev.c in
> > > the kernel has to use integer arithmetic, so probably small movements
> > > are rounded off to 0. I'll try to come up with a fix for this.
> >
> > Thanks for the hint. I tried various schemes and mathematical transformations
> > and found one which gives unquestionably the best result, with smoothest, most
> > precise and comfortable pointer movement:
> 
> Well, you removed the scaling to the touchpad resolution, which will
> cause ALPS touchpad to be significantly slower than Synaptics touchpads.

Yep, Synaptics I think has 4-5x higher resolution.

> Similarly, the screen size used to be taken into account, but probably
> that was a mistake, since the value is usually left at default and
> doesn't correspond to the real screen size.

I wonder if we should just add speed factor (along with tap distance)
options to mousedev. Vojtech, will you take such patch? I know you
want to drop mousedev and have everyone use evdev but, although people
started switching, it will not happen until distributions (or
XOrg/XFree themselves) have these drivers available straight out of
the box.

-- 
Dmitry

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Wed, Feb 02, 2005 at 10:51:38AM -0500, Dmitry Torokhov wrote:

> I wonder if we should just add speed factor (along with tap distance)
> options to mousedev. Vojtech, will you take such patch? I know you
> want to drop mousedev and have everyone use evdev but, although people
> started switching, it will not happen until distributions (or
> XOrg/XFree themselves) have these drivers available straight out of
> the box.
 
I would be OK with that if we take the default from the touchpad
resolution, so that the driver uses a reasonable value without having to
use the speed parameter.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Pete Zaitcev]

On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:

> Well, you removed the scaling to the touchpad resolution, which will
> cause ALPS touchpad to be significantly slower than Synaptics touchpads.
> Similarly, the screen size used to be taken into account, but probably
> that was a mistake, since the value is usually left at default and
> doesn't correspond to the real screen size.

Exactly. And it works much better now.

-- Pete

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote:
> On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> 
> > Well, you removed the scaling to the touchpad resolution, which will
> > cause ALPS touchpad to be significantly slower than Synaptics touchpads.
> > Similarly, the screen size used to be taken into account, but probably
> > that was a mistake, since the value is usually left at default and
> > doesn't correspond to the real screen size.
> 
> Exactly. And it works much better now.
 
With a Synaptics I suppose? You wouldn't like it with an ALPS.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Pete Zaitcev]

On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:

> On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote:
> > On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> > 
> > > Well, you removed the scaling to the touchpad resolution, which will
> > > cause ALPS touchpad to be significantly slower than Synaptics touchpads.
> > > Similarly, the screen size used to be taken into account, but probably
> > > that was a mistake, since the value is usually left at default and
> > > doesn't correspond to the real screen size.
> > 
> > Exactly. And it works much better now.
>  
> With a Synaptics I suppose? You wouldn't like it with an ALPS.

No, it's a Dualpoint, and so ALPS. But never mind that, I think I see
your point.

However, while I see a possibility of serious regressions with the other
variety, but isn't it striking that result is so radical? With all the
arithmetics still in place I can move my finger all across the pad without
causing any motions. We are not talking about ballistics or any fine tuning,
simply the calculations are wrong.

Let me add more, too. As long as the touchpad code in mousedev.c converts
absolute mode data into relative events, there's no reason to scale
_to the size of the screen_. Don't you see? User needs a scaling to
the sensitivity, not the screen size. I have never seen a touchpad which
allowed you to cross the screen in one motion if you moved it slowly,
this is why acceleration feature exists. It's completely bogus.

Scaling to the size of the screen would have made sense if we used touchpad
to generate absolute events, as some sort of a miniature Wacom pad. In such
a case, you wouldn't be able to reach corners of the screen without scaling.
But a touchpad is operated in entirely different way.

If Synaptics delivers much bigger deltas for small motions, it's up to the
Synapics mode of alps.c to make them reasonable, if that. There's no need
to penalize ALPS. But I seriously doubt that Synaptics can be so broken.
I wish Peter tested the removal of scaling with his Synaptics. If he
(and Dmitry) insist on running a special code in X, that's fine. But honestly,
I expect that things will go well for them.

-- Pete

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Wed, Feb 02, 2005 at 09:58:51AM -0800, Pete Zaitcev wrote:
> On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> 
> > On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote:
> > > On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> > > 
> > > > Well, you removed the scaling to the touchpad resolution, which will
> > > > cause ALPS touchpad to be significantly slower than Synaptics touchpads.
> > > > Similarly, the screen size used to be taken into account, but probably
> > > > that was a mistake, since the value is usually left at default and
> > > > doesn't correspond to the real screen size.
> > > 
> > > Exactly. And it works much better now.
> >  
> > With a Synaptics I suppose? You wouldn't like it with an ALPS.
> 
> No, it's a Dualpoint, and so ALPS. But never mind that, I think I see
> your point.
> 
> However, while I see a possibility of serious regressions with the other
> variety, but isn't it striking that result is so radical? With all the
> arithmetics still in place I can move my finger all across the pad without
> causing any motions. We are not talking about ballistics or any fine tuning,
> simply the calculations are wrong.

Sorry for that. It's not my code (except to the pad resolution scaling). ;)

> Let me add more, too. As long as the touchpad code in mousedev.c converts
> absolute mode data into relative events, there's no reason to scale
> _to the size of the screen_.

Well, there is a reason. You usually want to be able to get to the other
edge of the screen with a few moves of the finger. So the preferred
final sensitivity depends on the screen size.

But, since we don't know the screen size, we can't do this properly and
thus it's better not to do it at all.

> Don't you see? User needs a scaling to
> the sensitivity, not the screen size. I have never seen a touchpad which
> allowed you to cross the screen in one motion if you moved it slowly,
> this is why acceleration feature exists. It's completely bogus.

I agree. We should give it the same perceived resolution as a standard
400 DPI mouse (which is what the firmware does in mouse emulation mode)
regardless of the screen size. That's actually the only way how it can
mix with normal mouse data properly.

> Scaling to the size of the screen would have made sense if we used touchpad
> to generate absolute events, as some sort of a miniature Wacom pad. In such
> a case, you wouldn't be able to reach corners of the screen without scaling.
> But a touchpad is operated in entirely different way.
> 
> If Synaptics delivers much bigger deltas for small motions,

It's different hardware. While the ALPS pad delivers X axis in the range
of 0 to 1000, the Synaptics pad will give X axis values from approx 1500
to approx 5500. This is four times the resolution - the size of the pad
is mostly the same.

Synaptics or ALPS don't deliver deltas in native mode. They deliver
absolute coordinates of the finger touching. That's why there is any
math delivered at all.

> it's up to the
> Synapics mode of alps.c to make them reasonable, if that.

The policy of input drivers is not to scale or otherwise modify the
data. That's why the input_dev struct contains the ranges of the axes.

Btw, what do you mean by "synaptics mode of alps"?

> There's no need
> to penalize ALPS. But I seriously doubt that Synaptics can be so broken.

Neither are broken. But mousedev.c (and similarly the X touchpad driver)
must take the pad resolution into account, otherwise the cursor will
move four times faster with Synaptics than with ALPS.

> I wish Peter tested the removal of scaling with his Synaptics. If he
> (and Dmitry) insist on running a special code in X, that's fine. But honestly,
> I expect that things will go well for them.

I added the scaling code, because my ALPS pad was *unbearably* slow.
The original code in mousedev divided by 8 (instead of 2), because it
was tuned for Synaptics.

We need to divide by 2 for ALPS and by 8 for Synaptics, and that's
basically all we need to do. But we must not do that by checking the pad
manufacturer, because when a third pad type comes in (Say Logitech
TouchPad 3), we shouldn't need to modify mousedev.c

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Dmitry Torokhov]

On Wed, 2 Feb 2005 09:58:51 -0800, Pete Zaitcev <zaitcev@redhat.com> wrote:
> On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> 
> > On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote:
> > > On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> > >
> > > > Well, you removed the scaling to the touchpad resolution, which will
> > > > cause ALPS touchpad to be significantly slower than Synaptics touchpads.
> > > > Similarly, the screen size used to be taken into account, but probably
> > > > that was a mistake, since the value is usually left at default and
> > > > doesn't correspond to the real screen size.
> > >
> > > Exactly. And it works much better now.
> >
> > With a Synaptics I suppose? You wouldn't like it with an ALPS.
> 
> No, it's a Dualpoint, and so ALPS. But never mind that, I think I see
> your point.
> 
> However, while I see a possibility of serious regressions with the other
> variety, but isn't it striking that result is so radical? With all the
> arithmetics still in place I can move my finger all across the pad without
> causing any motions. We are not talking about ballistics or any fine tuning,
> simply the calculations are wrong.
> 

It works fine for my Synaptics with default resolution, I don't have
ALPS to try but I think Peter tried to make it behave similarly.
Still, I agree that relying on the screen coordinates is a bad idea.

> If Synaptics delivers much bigger deltas for small motions, it's up to the
> Synapics mode of alps.c to make them reasonable, if that. There's no need
> to penalize ALPS. But I seriously doubt that Synaptics can be so broken.

Why is that having 5x better resolution is considered broken? And how
synaptics should "make them reasonable"? Driver emits pretty much raw
coordinate values and it is up to the consumer to make sense of them.

> I wish Peter tested the removal of scaling with his Synaptics. If he
> (and Dmitry) insist on running a special code in X, that's fine.

Yes, because there are other things we can do in that special code. Do
you like default tochpad sensitivity? What if someone does not? Do you
like verical and horisontal scrolling? Circular scrolling?
multi-finger tappng (synaptics only)? Corner tapping? What about
rebooting every time you change an option?

>  But honestly, I expect that things will go well for them.

Well, your code will make my touchpad (Synaptics) go ballistic. It
really has resolution of about 4000 points across.

-- 
Dmitry

Re: Touchpad problems with 2.6.11-rc2

[Pete Zaitcev]

On Wed, 2 Feb 2005 20:11:35 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:

> It's different hardware. While the ALPS pad delivers X axis in the range
> of 0 to 1000, the Synaptics pad will give X axis values from approx 1500
> to approx 5500. This is four times the resolution - the size of the pad
> is mostly the same.

> We need to divide by 2 for ALPS and by 8 for Synaptics, and that's
> basically all we need to do. But we must not do that by checking the pad
> manufacturer, because when a third pad type comes in (Say Logitech
> TouchPad 3), we shouldn't need to modify mousedev.c

What you say is valid. I see now that this is what had to be addressed by
this statement:
  size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];

Removing that was my mistake and I wish I had a different pad for testing.
I'll do some measurements here and return something of that nature into
the patched code and give it a try.

But I still think that using yres here is wrong. It may be a fine idea,
but adding another divisor here ruined the precision of small movements.
This was my problem. Trying to line up two windows was hugely frustrating
with 2.6.11-rc2 & Peter's patches. But also, it was unnecessary to use yres,
because the reach or maximum moving distance is to be accomplished with
ballistics, not scaling.

There's nothing new about the pad being too small, actually. Old Logitech
Genius mouse in 1992 ran out of its green pad easily. The answer was
to accelerate the movement. If you moved quicker, you crossed whole screen.
The good news is that this adjustment is individual for the user and is
easily configurable.

-- Pete

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Wed, Feb 02, 2005 at 11:39:29AM -0800, Pete Zaitcev wrote:
> On Wed, 2 Feb 2005 20:11:35 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> 
> > It's different hardware. While the ALPS pad delivers X axis in the range
> > of 0 to 1000, the Synaptics pad will give X axis values from approx 1500
> > to approx 5500. This is four times the resolution - the size of the pad
> > is mostly the same.
> 
> > We need to divide by 2 for ALPS and by 8 for Synaptics, and that's
> > basically all we need to do. But we must not do that by checking the pad
> > manufacturer, because when a third pad type comes in (Say Logitech
> > TouchPad 3), we shouldn't need to modify mousedev.c
> 
> What you say is valid. I see now that this is what had to be addressed by
> this statement:
>   size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];
> 
> Removing that was my mistake and I wish I had a different pad for testing.
> I'll do some measurements here and return something of that nature into
> the patched code and give it a try.

OK.

> But I still think that using yres here is wrong. It may be a fine idea,
> but adding another divisor here ruined the precision of small movements.
> This was my problem. Trying to line up two windows was hugely frustrating
> with 2.6.11-rc2 & Peter's patches. But also, it was unnecessary to use yres,
> because the reach or maximum moving distance is to be accomplished with
> ballistics, not scaling.

I agree. If one wants full precision even at the ballistic speeds of
movement (and Synaptics can do that simply by not dividing the values),
one can use the special X driver.

No need to be overclever in mousedev.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

Pete Zaitcev <zaitcev@redhat.com> writes:

> On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <petero2@telia.com> wrote:
> 
> > > - Slow motion of finger produces no motion, then a jump. So, it's very hard to
> > >   target smaller UI elements and some web links.
> > 
> > I see this too when I don't use the X touchpad driver. With the X
> > driver there is no problem. I think the problem is that mousedev.c in
> > the kernel has to use integer arithmetic, so probably small movements
> > are rounded off to 0. I'll try to come up with a fix for this.
> 
> Thanks for the hint. I tried various schemes and mathematical transformations
> and found one which gives unquestionably the best result, with smoothest, most
> precise and comfortable pointer movement:

Please try this patch instead. It works well with my alps touchpad. (I
don't have a synaptics touchpad.) It does the following:

* Compensates for the lack of floating point arithmetic by keeping
  track of remainders from the integer divisions.
* Removes the xres/yres scaling so that you get the same speed in the
  X and Y directions even if your screen is not square.
* Sets scale factors so that the speed for synaptics and alps should
  be equal to each other and equal to the synaptics speed from 2.6.10.

Signed-off-by: Peter Osterlund <petero2@telia.com>
---

 linux-petero/drivers/input/mousedev.c |   26 +++++++++++++++++---------
 1 files changed, 17 insertions(+), 9 deletions(-)

diff -puN drivers/input/mousedev.c~mousedev-roundoff drivers/input/mousedev.c
--- linux/drivers/input/mousedev.c~mousedev-roundoff	2005-02-02 20:54:23.000000000 +0100
+++ linux-petero/drivers/input/mousedev.c	2005-02-02 21:42:39.000000000 +0100
@@ -71,6 +71,7 @@ struct mousedev {
 	struct mousedev_hw_data packet;
 	unsigned int pkt_count;
 	int old_x[4], old_y[4];
+	int frac_dx, frac_dy;
 	unsigned long touch;
 };
 
@@ -117,24 +118,31 @@ static struct mousedev mousedev_mix;
 
 static void mousedev_touchpad_event(struct input_dev *dev, struct mousedev *mousedev, unsigned int code, int value)
 {
-	int size;
+	int size, tmp;
+#define FRACTION_DENOM 100
 
 	if (mousedev->touch) {
+		size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
+		if (size == 0) size = xres;
 		switch (code) {
 			case ABS_X:
-				size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
-				if (size == 0) size = xres;
 				fx(0) = value;
-				if (mousedev->pkt_count >= 2)
-					mousedev->packet.dx = ((fx(0) - fx(1)) / 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+				if (mousedev->pkt_count >= 2) {
+					tmp = ((fx(0) - fx(2)) * (250 * FRACTION_DENOM)) / size;
+					tmp += mousedev->frac_dx;
+					mousedev->packet.dx = tmp / FRACTION_DENOM;
+					mousedev->frac_dx = tmp - mousedev->packet.dx * FRACTION_DENOM;
+				}
 				break;
 
 			case ABS_Y:
-				size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];
-				if (size == 0) size = yres;
 				fy(0) = value;
-				if (mousedev->pkt_count >= 2)
-					mousedev->packet.dy = -((fy(0) - fy(1)) / 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+				if (mousedev->pkt_count >= 2) {
+					tmp = -((fy(0) - fy(2)) * (250 * FRACTION_DENOM)) / size;
+					tmp += mousedev->frac_dy;
+					mousedev->packet.dy = tmp / FRACTION_DENOM;
+					mousedev->frac_dy = tmp - mousedev->packet.dy * FRACTION_DENOM;
+				}
 				break;
 		}
 	}
_

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Dmitry Torokhov]

On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
<petero2@telia.com> wrote:
> +                               if (mousedev->pkt_count >= 2) {
> +                                       tmp = ((fx(0) - fx(2)) * (250 * FRACTION_DENOM)) / size;
> +                                       tmp += mousedev->frac_dx;
> +                                       mousedev->packet.dx = tmp / FRACTION_DENOM;
> +                                       mousedev->frac_dx = tmp - mousedev->packet.dx * FRACTION_DENOM;
> +                               }

What about setting scale to 256 and fractions to 128 - that should
save some cycles? Or it will be too much?

-- 
Dmitry

Re: Touchpad problems with 2.6.11-rc2

[David Ford]

What does one need to do to:

a) put tapping back in, and
b) fix the severe jerkiness with small movements

Thanks

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:

> On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
> <petero2@telia.com> wrote:
> > +                               if (mousedev->pkt_count >= 2) {
> > +                                       tmp = ((fx(0) - fx(2)) * (250 * FRACTION_DENOM)) / size;
> > +                                       tmp += mousedev->frac_dx;
> > +                                       mousedev->packet.dx = tmp / FRACTION_DENOM;
> > +                                       mousedev->frac_dx = tmp - mousedev->packet.dx * FRACTION_DENOM;
> > +                               }
> 
> What about setting scale to 256 and fractions to 128 - that should
> save some cycles? Or it will be too much?

It at least saves 32 bytes of object code. The mouse pointer speed
increase will only be 256/250, or 2.4%, so shouldn't be a problem.
Setting FRACTION_DENOM to a larger value is actually a good thing as
long as it doesn't cause arithmetic overflow.

Here is an updated patch:

Signed-off-by: Peter Osterlund <petero2@telia.com>
---

 linux-petero/drivers/input/mousedev.c |   26 +++++++++++++++++---------
 1 files changed, 17 insertions(+), 9 deletions(-)

diff -puN drivers/input/mousedev.c~mousedev-roundoff drivers/input/mousedev.c
--- linux/drivers/input/mousedev.c~mousedev-roundoff	2005-02-02 20:54:23.000000000 +0100
+++ linux-petero/drivers/input/mousedev.c	2005-02-02 22:20:15.000000000 +0100
@@ -71,6 +71,7 @@ struct mousedev {
 	struct mousedev_hw_data packet;
 	unsigned int pkt_count;
 	int old_x[4], old_y[4];
+	int frac_dx, frac_dy;
 	unsigned long touch;
 };
 
@@ -117,24 +118,31 @@ static struct mousedev mousedev_mix;
 
 static void mousedev_touchpad_event(struct input_dev *dev, struct mousedev *mousedev, unsigned int code, int value)
 {
-	int size;
+	int size, tmp;
+#define FRACTION_DENOM 128
 
 	if (mousedev->touch) {
+		size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
+		if (size == 0) size = xres;
 		switch (code) {
 			case ABS_X:
-				size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
-				if (size == 0) size = xres;
 				fx(0) = value;
-				if (mousedev->pkt_count >= 2)
-					mousedev->packet.dx = ((fx(0) - fx(1)) / 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+				if (mousedev->pkt_count >= 2) {
+					tmp = ((fx(0) - fx(2)) * (256 * FRACTION_DENOM)) / size;
+					tmp += mousedev->frac_dx;
+					mousedev->packet.dx = tmp / FRACTION_DENOM;
+					mousedev->frac_dx = tmp - mousedev->packet.dx * FRACTION_DENOM;
+				}
 				break;
 
 			case ABS_Y:
-				size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];
-				if (size == 0) size = yres;
 				fy(0) = value;
-				if (mousedev->pkt_count >= 2)
-					mousedev->packet.dy = -((fy(0) - fy(1)) / 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+				if (mousedev->pkt_count >= 2) {
+					tmp = -((fy(0) - fy(2)) * (256 * FRACTION_DENOM)) / size;
+					tmp += mousedev->frac_dy;
+					mousedev->packet.dy = tmp / FRACTION_DENOM;
+					mousedev->frac_dy = tmp - mousedev->packet.dy * FRACTION_DENOM;
+				}
 				break;
 		}
 	}
_

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Dmitry Torokhov]

On Wed, 02 Feb 2005 13:52:03 -0800 (PST), Peter Osterlund
<petero2@telia.com> wrote:
> 
>        if (mousedev->touch) {
> +               size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
> +               if (size == 0) size = xres;

Sorry, missed this piece first time around. Since we don't want to
rely on screen size anymore I think we should set size = 256 *
FRACTION_DENOM / 2 if device limits are not set up to just report raw
coords. What do you think?

-- 
Dmitry

Re: Touchpad problems with 2.6.11-rc2

[Pete Zaitcev]

On 02 Feb 2005 21:57:39 +0100, Peter Osterlund <petero2@telia.com> wrote:

> Please try this patch instead. It works well with my alps touchpad. (I
> don't have a synaptics touchpad.) It does the following:
> 
> * Compensates for the lack of floating point arithmetic by keeping
>   track of remainders from the integer divisions.
> * Removes the xres/yres scaling so that you get the same speed in the
>   X and Y directions even if your screen is not square.
> * Sets scale factors so that the speed for synaptics and alps should
>   be equal to each other and equal to the synaptics speed from 2.6.10.

Thanks a lot, Peter. I think I like the result even better than the one
after the simple-minded removal that I posted. It's possible that when
I accepted the case of (pktcount == 1) it hurt smoothness.

Do you think it makes sense to zero fractions when pktcount is dropped?
Also, I think the extra unary minus is uncoth.

-- Pete

--- linux-2.6.11-rc2/drivers/input/mousedev.c	2005-01-22 14:54:14.000000000 -0800
+++ linux-2.6.11-rc2-lem/drivers/input/mousedev.c	2005-02-02 14:03:07.000000000 -0800
@@ -71,6 +71,7 @@
 	struct mousedev_hw_data packet;
 	unsigned int pkt_count;
 	int old_x[4], old_y[4];
+	int frac_dx, frac_dy;
 	unsigned long touch;
 };
 
@@ -117,24 +118,31 @@
 
 static void mousedev_touchpad_event(struct input_dev *dev, struct mousedev *mousedev, unsigned int code, int value)
 {
-	int size;
+	int size, tmp;
+	enum {  FRACTION_DENOM = 100 };
 
 	if (mousedev->touch) {
+		size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
+		if (size == 0) size = xres;
 		switch (code) {
 			case ABS_X:
-				size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
-				if (size == 0) size = xres;
 				fx(0) = value;
-				if (mousedev->pkt_count >= 2)
-					mousedev->packet.dx = ((fx(0) - fx(1)) / 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+				if (mousedev->pkt_count >= 2) {
+					tmp = ((value - fx(2)) * (250 * FRACTION_DENOM)) / size;
+					tmp += mousedev->frac_dx;
+					mousedev->packet.dx = tmp / FRACTION_DENOM;
+					mousedev->frac_dx = tmp - mousedev->packet.dx * FRACTION_DENOM;
+				}
 				break;
 
 			case ABS_Y:
-				size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];
-				if (size == 0) size = yres;
 				fy(0) = value;
-				if (mousedev->pkt_count >= 2)
-					mousedev->packet.dy = -((fy(0) - fy(1)) / 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+				if (mousedev->pkt_count >= 2) {
+					tmp = ((fy(2) - value) * (250 * FRACTION_DENOM)) / size;
+					tmp += mousedev->frac_dy;
+					mousedev->packet.dy = tmp / FRACTION_DENOM;
+					mousedev->frac_dy = tmp - mousedev->packet.dy * FRACTION_DENOM;
+				}
 				break;
 		}
 	}
@@ -268,6 +276,8 @@
 			clear_bit(0, &mousedev_mix.packet.buttons);
 		}
 		mousedev->touch = mousedev->pkt_count = 0;
+		mousedev->frac_dx = 0;
+		mousedev->frac_dy = 0;
 	}
 	else
 		if (!mousedev->touch)

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

On Wed, 2 Feb 2005, Dmitry Torokhov wrote:

> On Wed, 02 Feb 2005 13:52:03 -0800 (PST), Peter Osterlund
> <petero2@telia.com> wrote:
> >
> >        if (mousedev->touch) {
> > +               size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
> > +               if (size == 0) size = xres;
>
> Sorry, missed this piece first time around. Since we don't want to
> rely on screen size anymore I think we should set size = 256 *
> FRACTION_DENOM / 2 if device limits are not set up to just report raw
> coords. What do you think?

I think that this case can't happen until we add support for some other
touchpad that doesn't set the absmin/absmax variables. Both alps and
synaptics currently set them.

However, the fallback value should definitely not depend on
FRACTION_DENOM, since this constant doesn't affect the mouse speed at all.
It only affects how accurately we store the fractional part of dx and dy.
Ideally FRACTION_DENOM should be as large as possible without causing
arithmetic overflow. In practice, 128 seemed to be plenty enough.

So, the fallback value should be set to the estimated absmax-absmin value
for the hypothetical future touchpad driver that also hypothetically
doesn't set this value itself. I have no idea how to estimate this value
though, which is why I just used xres. ;)

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

On Wed, 2 Feb 2005, Pete Zaitcev wrote:

> On 02 Feb 2005 21:57:39 +0100, Peter Osterlund <petero2@telia.com> wrote:
>
> > Please try this patch instead. It works well with my alps touchpad. (I
> > don't have a synaptics touchpad.) It does the following:
> >
> > * Compensates for the lack of floating point arithmetic by keeping
> >   track of remainders from the integer divisions.
> > * Removes the xres/yres scaling so that you get the same speed in the
> >   X and Y directions even if your screen is not square.
> > * Sets scale factors so that the speed for synaptics and alps should
> >   be equal to each other and equal to the synaptics speed from 2.6.10.
>
> Thanks a lot, Peter. I think I like the result even better than the one
> after the simple-minded removal that I posted. It's possible that when
> I accepted the case of (pktcount == 1) it hurt smoothness.
>
> Do you think it makes sense to zero fractions when pktcount is dropped?

In practice I don't think it will make any significant difference. What
the code should do depends on what you want to happen if you move the
mouse pointer 1/2 pixel with one finger stroke, then move it another 1/2
pixel with a second stroke. The patch I posted will move the pointer one
pixel in this case and your code will move it 0 pixels. (The X driver does
not reset the fractions, but that doesn't of course mean that it's the
only right thing to do.)

> Also, I think the extra unary minus is uncoth.

The code was written like that to emphasize the fact that X and Y use the
same formula, with the only difference that the kernel Y axis is mirrored
compared to the touchpad Y axis.

It didn't make any difference for the generated assembly code though,
using gcc 3.4.2 from Fedora Core 3.

> +	enum {  FRACTION_DENOM = 100 };

The enum is much nicer than my #define.

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Wed, Feb 02, 2005 at 11:58:05PM +0100, Peter Osterlund wrote:

> In practice I don't think it will make any significant difference. What
> the code should do depends on what you want to happen if you move the
> mouse pointer 1/2 pixel with one finger stroke, then move it another 1/2
> pixel with a second stroke. The patch I posted will move the pointer one
> pixel in this case and your code will move it 0 pixels. (The X driver does
> not reset the fractions, but that doesn't of course mean that it's the
> only right thing to do.)
> 
> > Also, I think the extra unary minus is uncoth.
> 
> The code was written like that to emphasize the fact that X and Y use the
> same formula, with the only difference that the kernel Y axis is mirrored
> compared to the touchpad Y axis.
> 
> It didn't make any difference for the generated assembly code though,
> using gcc 3.4.2 from Fedora Core 3.
> 
> > +	enum {  FRACTION_DENOM = 100 };
> 
> The enum is much nicer than my #define.

OK. I like this patch, too. Can you guys send me a final version
incorporating the changes of you both for inclusion in the input tree?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Pete Zaitcev]

On Wed, 2 Feb 2005 23:58:05 +0100 (CET), Peter Osterlund <petero2@telia.com> wrote:

> It didn't make any difference for the generated assembly code though,
> using gcc 3.4.2 from Fedora Core 3.

OK, unary minus is fine then.

What about using 'value' in place of 'fx(0)'?

-- Pete

Re: Touchpad problems with 2.6.11-rc2

[Dmitry Torokhov]

On Wednesday 02 February 2005 17:27, Peter Osterlund wrote:
> On Wed, 2 Feb 2005, Dmitry Torokhov wrote:
> 
> > On Wed, 02 Feb 2005 13:52:03 -0800 (PST), Peter Osterlund
> > <petero2@telia.com> wrote:
> > >
> > >        if (mousedev->touch) {
> > > +               size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
> > > +               if (size == 0) size = xres;
> >
> > Sorry, missed this piece first time around. Since we don't want to
> > rely on screen size anymore I think we should set size = 256 *
> > FRACTION_DENOM / 2 if device limits are not set up to just report raw
> > coords. What do you think?
> 
> I think that this case can't happen until we add support for some other
> touchpad that doesn't set the absmin/absmax variables. Both alps and
> synaptics currently set them.
> 
> However, the fallback value should definitely not depend on
> FRACTION_DENOM, since this constant doesn't affect the mouse speed at all.

Oh, yes, we divide by FRACTION_DENOM later. So having size = 256 * 2
should undo all scaling and report coordinates one for one which I think
is a reasonable solution if device did not set it's size.

-- 
Dmitry

Re: Touchpad problems with 2.6.11-rc2

[Alexandre Oliva]

On Feb  2, 2005, Pete Zaitcev <zaitcev@redhat.com> wrote:

> On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:

>> With a Synaptics I suppose? You wouldn't like it with an ALPS.

> No, it's a Dualpoint, and so ALPS.

Err...  That doesn't follow.  My Dell Inspiron 8000 has a Synaptics
touchpad as part of the Dualpoint pointing devices.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Thu, Feb 03, 2005 at 06:30:14AM -0200, Alexandre Oliva wrote:
> On Feb  2, 2005, Pete Zaitcev <zaitcev@redhat.com> wrote:
> 
> > On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> 
> >> With a Synaptics I suppose? You wouldn't like it with an ALPS.
> 
> > No, it's a Dualpoint, and so ALPS.
> 
> Err...  That doesn't follow.  My Dell Inspiron 8000 has a Synaptics
> touchpad as part of the Dualpoint pointing devices.
 
Dualpoint (tm) is a trademark of ALPS, so in your case you have both a
touchpoint and a touchpad, but it's not called a Dualpoint in this case,
because it's two separate devices.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Giuseppe Bilotta]

Dmitry Torokhov wrote:
> No I don't but by the looks of it (constant stream of bad data) it looks
> like somehow the touhcpad was reset back into PS/2 compatibility mode.
> resetafter would catch it and reinitialize touchpad restoring proper
> protocol.

My Dell Inspiron 8200 shows very sluggish keyboad AND Touchpad 
responsiveness *under Windows* after plugging (and subsequently 
unplugging) an external PS/2 device (mouse OR keyboard) (I have 
never tried this under Linux though), so it might be a hardware 
issue.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: Touchpad problems with 2.6.11-rc2

[Alexandre Oliva]

On Feb  3, 2005, Vojtech Pavlik <vojtech@suse.cz> wrote:

> On Thu, Feb 03, 2005 at 06:30:14AM -0200, Alexandre Oliva wrote:
>> On Feb  2, 2005, Pete Zaitcev <zaitcev@redhat.com> wrote:
>> 
>> > On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
>> 
>> >> With a Synaptics I suppose? You wouldn't like it with an ALPS.
>> 
>> > No, it's a Dualpoint, and so ALPS.
>> 
>> Err...  That doesn't follow.  My Dell Inspiron 8000 has a Synaptics
>> touchpad as part of the Dualpoint pointing devices.
 
> Dualpoint (tm) is a trademark of ALPS,

Interesting...  Dell DualPoint is the way the pointing devices are
described in that notebook's documentation, and I remember all the way
from back when I purchased the notebook: I really wanted the two
pointing devices.  If you search the web for Dell Inspiron 8000
DualPoint, you'll get a number of hits referring to `Dell's DualPoint
technology'.  I don't see them referred to as DualPoint(TM), but I
vaguely remember having seen something like that in Dell's web site
back then.

Maybe ALPS bought the trademark from Dell, or Dell hadn't actually
registered the trademark, or they somehow managed to get the
trademarks registered with a case difference (DualPoint vs Dualpoint)?

> so in your case you have both a touchpoint and a touchpad, but it's
> not called a Dualpoint in this case, because it's two separate
> devices.

Indeed, it's called Dell DualPoint.  Sorry about the confusion.  Not
really my fault, I think :-) :-)

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Touchpad problems with 2.6.11-rc2

[Dmitry Torokhov]

On Thu, 03 Feb 2005 07:22:40 -0800 (PST), Alexandre Oliva
<aoliva@redhat.com> wrote:
> On Feb  3, 2005, Vojtech Pavlik <vojtech@suse.cz> wrote:
> 
> > On Thu, Feb 03, 2005 at 06:30:14AM -0200, Alexandre Oliva wrote:
> >> On Feb  2, 2005, Pete Zaitcev <zaitcev@redhat.com> wrote:
> >>
> >> > On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> >>
> >> >> With a Synaptics I suppose? You wouldn't like it with an ALPS.
> >>
> >> > No, it's a Dualpoint, and so ALPS.
> >>
> >> Err...  That doesn't follow.  My Dell Inspiron 8000 has a Synaptics
> >> touchpad as part of the Dualpoint pointing devices.
> 
> > Dualpoint (tm) is a trademark of ALPS,
> 
> Interesting...  Dell DualPoint is the way the pointing devices are
> described in that notebook's documentation, and I remember all the way
> from back when I purchased the notebook: I really wanted the two
> pointing devices.  If you search the web for Dell Inspiron 8000
> DualPoint, you'll get a number of hits referring to `Dell's DualPoint
> technology'.  I don't see them referred to as DualPoint(TM), but I
> vaguely remember having seen something like that in Dell's web site
> back then.
> 
> Maybe ALPS bought the trademark from Dell, or Dell hadn't actually
> registered the trademark, or they somehow managed to get the
> trademarks registered with a case difference (DualPoint vs Dualpoint)?
> 

I am not sure but on this page ALPS states that they have trademark on
DualPoint (TM):

http://www3.alps.co.jp/cgi-bin/WebObjects/catalog.woa/wa/varietyList?language=english&country=com&top_mode=2003&productId=11&varietyId=3

-- 
Dmitry

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Thu, Feb 03, 2005 at 10:28:58AM -0500, Dmitry Torokhov wrote:

> > > Dualpoint (tm) is a trademark of ALPS,
> > 
> > Interesting...  Dell DualPoint is the way the pointing devices are
> > described in that notebook's documentation, and I remember all the way
> > from back when I purchased the notebook: I really wanted the two
> > pointing devices.  If you search the web for Dell Inspiron 8000
> > DualPoint, you'll get a number of hits referring to `Dell's DualPoint
> > technology'.  I don't see them referred to as DualPoint(TM), but I
> > vaguely remember having seen something like that in Dell's web site
> > back then.
> > 
> > Maybe ALPS bought the trademark from Dell, or Dell hadn't actually
> > registered the trademark, or they somehow managed to get the
> > trademarks registered with a case difference (DualPoint vs Dualpoint)?
> > 
> 
> I am not sure but on this page ALPS states that they have trademark on
> DualPoint (TM):
> 
> http://www3.alps.co.jp/cgi-bin/WebObjects/catalog.woa/wa/varietyList?language=english&country=com&top_mode=2003&productId=11&varietyId=3
 
Maybe that's why IBM calls their Synaptics touchpad + IBM touchpoint
solution "IBM UltrNav(tm)"? ;)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

Vojtech Pavlik <vojtech@suse.cz> writes:

> On Wed, Feb 02, 2005 at 11:58:05PM +0100, Peter Osterlund wrote:
> 
> > In practice I don't think it will make any significant difference. What
> > the code should do depends on what you want to happen if you move the
> > mouse pointer 1/2 pixel with one finger stroke, then move it another 1/2
> > pixel with a second stroke. The patch I posted will move the pointer one
> > pixel in this case and your code will move it 0 pixels. (The X driver does
> > not reset the fractions, but that doesn't of course mean that it's the
> > only right thing to do.)
> > 
> > > Also, I think the extra unary minus is uncoth.
> > 
> > The code was written like that to emphasize the fact that X and Y use the
> > same formula, with the only difference that the kernel Y axis is mirrored
> > compared to the touchpad Y axis.
> > 
> > It didn't make any difference for the generated assembly code though,
> > using gcc 3.4.2 from Fedora Core 3.
> > 
> > > +	enum {  FRACTION_DENOM = 100 };
> > 
> > The enum is much nicer than my #define.
> 
> OK. I like this patch, too. Can you guys send me a final version
> incorporating the changes of you both for inclusion in the input tree?

Here it is, with the suggestions from Pete and Dmitry included. The
patch does the following:

* Compensates for the lack of floating point arithmetic by keeping
  track of remainders from the integer divisions.
* Removes the xres/yres scaling so that you get the same speed in the
  X and Y directions even if your screen is not square.
* Sets scale factors to make the speed for synaptics and alps equal to
  each other and equal to the synaptics speed from 2.6.10.

Signed-off-by: Peter Osterlund <petero2@telia.com>
---

 linux-petero/drivers/input/mousedev.c |   28 +++++++++++++++++++---------
 1 files changed, 19 insertions(+), 9 deletions(-)

diff -puN drivers/input/mousedev.c~mousedev-roundoff drivers/input/mousedev.c
--- linux/drivers/input/mousedev.c~mousedev-roundoff	2005-02-02 20:54:23.000000000 +0100
+++ linux-petero/drivers/input/mousedev.c	2005-02-03 22:41:41.000000000 +0100
@@ -71,6 +71,7 @@ struct mousedev {
 	struct mousedev_hw_data packet;
 	unsigned int pkt_count;
 	int old_x[4], old_y[4];
+	int frac_dx, frac_dy;
 	unsigned long touch;
 };
 
@@ -117,24 +118,31 @@ static struct mousedev mousedev_mix;
 
 static void mousedev_touchpad_event(struct input_dev *dev, struct mousedev *mousedev, unsigned int code, int value)
 {
-	int size;
+	int size, tmp;
+	enum { FRACTION_DENOM = 128 };
 
 	if (mousedev->touch) {
+		size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
+		if (size == 0) size = 256 * 2;
 		switch (code) {
 			case ABS_X:
-				size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
-				if (size == 0) size = xres;
 				fx(0) = value;
-				if (mousedev->pkt_count >= 2)
-					mousedev->packet.dx = ((fx(0) - fx(1)) / 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+				if (mousedev->pkt_count >= 2) {
+					tmp = ((value - fx(2)) * (256 * FRACTION_DENOM)) / size;
+					tmp += mousedev->frac_dx;
+					mousedev->packet.dx = tmp / FRACTION_DENOM;
+					mousedev->frac_dx = tmp - mousedev->packet.dx * FRACTION_DENOM;
+				}
 				break;
 
 			case ABS_Y:
-				size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];
-				if (size == 0) size = yres;
 				fy(0) = value;
-				if (mousedev->pkt_count >= 2)
-					mousedev->packet.dy = -((fy(0) - fy(1)) / 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+				if (mousedev->pkt_count >= 2) {
+					tmp = -((value - fy(2)) * (256 * FRACTION_DENOM)) / size;
+					tmp += mousedev->frac_dy;
+					mousedev->packet.dy = tmp / FRACTION_DENOM;
+					mousedev->frac_dy = tmp - mousedev->packet.dy * FRACTION_DENOM;
+				}
 				break;
 		}
 	}
@@ -268,6 +276,8 @@ static void mousedev_touchpad_touch(stru
 			clear_bit(0, &mousedev_mix.packet.buttons);
 		}
 		mousedev->touch = mousedev->pkt_count = 0;
+		mousedev->frac_dx = 0;
+		mousedev->frac_dy = 0;
 	}
 	else
 		if (!mousedev->touch)
_

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote:
> Vojtech Pavlik <vojtech@suse.cz> writes:
> 
> > On Wed, Feb 02, 2005 at 11:58:05PM +0100, Peter Osterlund wrote:
> > 
> > > In practice I don't think it will make any significant difference. What
> > > the code should do depends on what you want to happen if you move the
> > > mouse pointer 1/2 pixel with one finger stroke, then move it another 1/2
> > > pixel with a second stroke. The patch I posted will move the pointer one
> > > pixel in this case and your code will move it 0 pixels. (The X driver does
> > > not reset the fractions, but that doesn't of course mean that it's the
> > > only right thing to do.)
> > > 
> > > > Also, I think the extra unary minus is uncoth.
> > > 
> > > The code was written like that to emphasize the fact that X and Y use the
> > > same formula, with the only difference that the kernel Y axis is mirrored
> > > compared to the touchpad Y axis.
> > > 
> > > It didn't make any difference for the generated assembly code though,
> > > using gcc 3.4.2 from Fedora Core 3.
> > > 
> > > > +	enum {  FRACTION_DENOM = 100 };
> > > 
> > > The enum is much nicer than my #define.
> > 
> > OK. I like this patch, too. Can you guys send me a final version
> > incorporating the changes of you both for inclusion in the input tree?
> 
> Here it is, with the suggestions from Pete and Dmitry included. The
> patch does the following:
> 
> * Compensates for the lack of floating point arithmetic by keeping
>   track of remainders from the integer divisions.

This was likely the main cause of the slow motion problems.

> * Removes the xres/yres scaling so that you get the same speed in the
>   X and Y directions even if your screen is not square.

The old code assumed that both the pad and the screen are 4:3, not
square. It was wrong still.

> * Sets scale factors to make the speed for synaptics and alps equal to
>   each other and equal to the synaptics speed from 2.6.10.
> 
> Signed-off-by: Peter Osterlund <petero2@telia.com>

OK. I'll add it to my tree today.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

Vojtech Pavlik <vojtech@suse.cz> writes:

> On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote:
> 
> > * Removes the xres/yres scaling so that you get the same speed in the
> >   X and Y directions even if your screen is not square.
> 
> The old code assumed that both the pad and the screen are 4:3, not
> square. It was wrong still.

alps.c currently contains:

	psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS);
	input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0);
	input_set_abs_params(&psmouse->dev, ABS_Y, 0, 1023, 0, 0);
	input_set_abs_params(&psmouse->dev, ABS_PRESSURE, 0, 127, 0, 0);

Maybe it should set the ABS_Y max value to 767 in that case.

--- linux/drivers/input/mouse/alps.c~	2005-01-12 22:02:19.000000000 +0100
+++ linux/drivers/input/mouse/alps.c	2005-02-04 07:38:12.203436768 +0100
@@ -394,7 +394,7 @@
 
 	psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS);
 	input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0);
-	input_set_abs_params(&psmouse->dev, ABS_Y, 0, 1023, 0, 0);
+	input_set_abs_params(&psmouse->dev, ABS_Y, 0, 767, 0, 0);
 	input_set_abs_params(&psmouse->dev, ABS_PRESSURE, 0, 127, 0, 0);
 
 	psmouse->dev.keybit[LONG(BTN_TOUCH)] |= BIT(BTN_TOUCH);

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote:
> Vojtech Pavlik <vojtech@suse.cz> writes:
> 
> > On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote:
> > 
> > > * Removes the xres/yres scaling so that you get the same speed in the
> > >   X and Y directions even if your screen is not square.
> > 
> > The old code assumed that both the pad and the screen are 4:3, not
> > square. It was wrong still.

> alps.c currently contains:
> 
> 	psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS);
> 	input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0);
> 	input_set_abs_params(&psmouse->dev, ABS_Y, 0, 1023, 0, 0);
> 	input_set_abs_params(&psmouse->dev, ABS_PRESSURE, 0, 127, 0, 0);
> 
> Maybe it should set the ABS_Y max value to 767 in that case.

Yes, and no. It could have been 1023, if it was 3:4 in size, but not in
maximum values. See the real values below, though, it seems the
resolution in X and Y is indeed the same.

> --- linux/drivers/input/mouse/alps.c~	2005-01-12 22:02:19.000000000 +0100
> +++ linux/drivers/input/mouse/alps.c	2005-02-04 07:38:12.203436768 +0100
> @@ -394,7 +394,7 @@
>  
>  	psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS);
>  	input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0);
> -	input_set_abs_params(&psmouse->dev, ABS_Y, 0, 1023, 0, 0);
> +	input_set_abs_params(&psmouse->dev, ABS_Y, 0, 767, 0, 0);
>  	input_set_abs_params(&psmouse->dev, ABS_PRESSURE, 0, 127, 0, 0);
>  
>  	psmouse->dev.keybit[LONG(BTN_TOUCH)] |= BIT(BTN_TOUCH);
 
My ALPS gives values:

	X: 90-1019
	Y: 100-749
 Pressure: 0,34-108

So 0-1024, 0-768, 0-127 are probably the maximum theoretical ranges, and
the rest are likely the mechanical mounting limitations of the notebook
(the ridge around the pad is not rectangular).

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

Vojtech Pavlik <vojtech@suse.cz> writes:

> On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote:
> > Vojtech Pavlik <vojtech@suse.cz> writes:
> > 
> > > On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote:
> > > 
> > > > * Removes the xres/yres scaling so that you get the same speed in the
> > > >   X and Y directions even if your screen is not square.
> > > 
> > > The old code assumed that both the pad and the screen are 4:3, not
> > > square. It was wrong still.
> 
> > alps.c currently contains:
> > 
> > 	psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS);
> > 	input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0);
> > 	input_set_abs_params(&psmouse->dev, ABS_Y, 0, 1023, 0, 0);
> > 	input_set_abs_params(&psmouse->dev, ABS_PRESSURE, 0, 127, 0, 0);
> > 
> > Maybe it should set the ABS_Y max value to 767 in that case.
> 
> Yes, and no. It could have been 1023, if it was 3:4 in size, but not in
> maximum values. See the real values below, though, it seems the
> resolution in X and Y is indeed the same.
...
> My ALPS gives values:
> 
> 	X: 90-1019
> 	Y: 100-749
>  Pressure: 0,34-108

I get similar values:

        X: 40 - 984
        Y: 97 - 732
        Z: 0, 19 - 127

> So 0-1024, 0-768, 0-127 are probably the maximum theoretical ranges, and
> the rest are likely the mechanical mounting limitations of the notebook
> (the ridge around the pad is not rectangular).

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote:

> Here it is, with the suggestions from Pete and Dmitry included. The
> patch does the following:
> 
> * Compensates for the lack of floating point arithmetic by keeping
>   track of remainders from the integer divisions.
> * Removes the xres/yres scaling so that you get the same speed in the
>   X and Y directions even if your screen is not square.
> * Sets scale factors to make the speed for synaptics and alps equal to
>   each other and equal to the synaptics speed from 2.6.10.
> 
> Signed-off-by: Peter Osterlund <petero2@telia.com>
 
Thanks, applied.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Vojtech Pavlik]

On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote:
> Vojtech Pavlik <vojtech@suse.cz> writes:
> 
> > On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote:
> > 
> > > * Removes the xres/yres scaling so that you get the same speed in the
> > >   X and Y directions even if your screen is not square.
> > 
> > The old code assumed that both the pad and the screen are 4:3, not
> > square. It was wrong still.
> 
> alps.c currently contains:
> 
> 	psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS);
> 	input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0);
> 	input_set_abs_params(&psmouse->dev, ABS_Y, 0, 1023, 0, 0);
> 	input_set_abs_params(&psmouse->dev, ABS_PRESSURE, 0, 127, 0, 0);
> 
> Maybe it should set the ABS_Y max value to 767 in that case.

Applied.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Touchpad problems with 2.6.11-rc2

[Stephane Raimbault]

> That's a different bug that has already been fixed in 2.6.11-rc3-bk6.
> 
> http://linus.bkbits.net:8080/linux-2.5/cset@42079714WEG-WI7P2exv58htWhdGDA?nav=index.html|ChangeSet@-4d
> 

Works fine, thanks.

Stephane

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

Stephane Raimbault <stephane.raimbault@free.fr> writes:

> > Does the "Enable hardware tapping for ALPS touchpads" patch help?
> > 
> >         http://marc.theaimsgroup.com/?l=linux-kernel&m=110708138225873&w=2
> > 
> 
> Yes, works really better but the release event is sent only if I move
> the pointer. It's as if I still put my finger on the touchpad.

That's a different bug that has already been fixed in 2.6.11-rc3-bk6.

http://linus.bkbits.net:8080/linux-2.5/cset@42079714WEG-WI7P2exv58htWhdGDA?nav=index.html|ChangeSet@-4d

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Stephane Raimbault]

> 
> Does the "Enable hardware tapping for ALPS touchpads" patch help?
> 
>         http://marc.theaimsgroup.com/?l=linux-kernel&m=110708138225873&w=2
> 

Yes, works really better but the release event is sent only if I move
the pointer. It's as if I still put my finger on the touchpad.

Stephane

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

Stephane Raimbault <stephane.raimbault@free.fr> writes:

> I'm using 2.6.11-rc3 + Peter's patch and xorg from Fedora Core 3, I
> still have touchpad problems.
>  
> Tapping and focus work fine with 2.6.10 and 2.6.11-rc1 but not with :
> - 2.6.11-rc2
> - 2.6.11-rc3
> I read a similar report on LKML from David Ford.
> Only one tap on 30 is received and focus is really strange.
> 
> Like said in previous mails, small movements are rounded off to 0 but
> the Peter Osterlund's patch resolves this problem (tested with rc3).
> 
> Hardware
> kernel: input: AlpsPS/2 ALPS TouchPad on isa0 060/serio1
> Vaio GRT916V
> 
> In my xorg.conf :
> Driver      "mouse"
> Option      "Protocol" "IMPS/2"

Does the "Enable hardware tapping for ALPS touchpads" patch help?

        http://marc.theaimsgroup.com/?l=linux-kernel&m=110708138225873&w=2

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Stephane Raimbault]

Hi,

I'm using 2.6.11-rc3 + Peter's patch and xorg from Fedora Core 3, I
still have touchpad problems.
 
Tapping and focus work fine with 2.6.10 and 2.6.11-rc1 but not with :
- 2.6.11-rc2
- 2.6.11-rc3
I read a similar report on LKML from David Ford.
Only one tap on 30 is received and focus is really strange.

Like said in previous mails, small movements are rounded off to 0 but
the Peter Osterlund's patch resolves this problem (tested with rc3).

Hardware
kernel: input: AlpsPS/2 ALPS TouchPad on isa0 060/serio1
Vaio GRT916V

In my xorg.conf :
Driver      "mouse"
Option      "Protocol" "IMPS/2"

Bye,

Stephane Raimbault

Re: Touchpad problems with 2.6.11-rc2

[Dmitry Torokhov]

On Mon, 31 Jan 2005 13:46:08 -0800, Pete Zaitcev <zaitcev@redhat.com> wrote:
> 
> Can you tell me exactly how I go about "trying out Synaptics X driver"?
> 

Peter's page is here:
http://web.telia.com/~u89404340/touchpad/

Just do "yum update synaptics" and then Adjust your xorg.conf to use
"synaptics" driver. Start with the defaults as shown in the doc
directory. I recommend setting protocol to "auto-dev". Make sure both
psmouse and evdev are loaded.

-- 
Dmitry

Re: Touchpad problems with 2.6.11-rc2

[Pete Zaitcev]

On Tue, 25 Jan 2005 16:30:15 -0500, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> > The more serious one is that sometimes it seems to spontaneously emit click
> > events while I'm moving finger across pad.  Which means I've had to learn to
> > plan my "mouse" motions to avoid areas where clicking could have bad effects.
> > But that's not always possible ...

> That is default sensitivity not suiting your habits I think. I would
> recomment trying out Synaptics X driver (which also does ALPS) so you
> will be able adjust sensitivity the way you like it.

Curiously enough, I did not see this effect until I applied Peter's patches
1 and 2. In sum, for a D600 with both nipple and trackpad (so, DualPoint):

2.6.10: ALPS not detected. Normal motion. No issues with sporadic tap.
No issuses with keyboard. Cursor warps to the edge of the screen.
2.6.11-rc2: ALPS detected. Issues that I listed, keyboard dying is the worst.
Warps still present (I wrote that they went away, but I was wrong).
2.6.11-rc1 + Peter's 1/4 and 1/2: Keyboard seems fixed by patch 1/4.
The missing slow motion still present. New issue: sporadic (left button only)
clicks generated by motions.

Can you tell me exactly how I go about "trying out Synaptics X driver"?

-- Pete

Re: Touchpad problems with 2.6.11-rc2

[David Brownell]

On Sunday 30 January 2005 3:20 am, Peter Osterlund wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
> > On Tue, 25 Jan 2005 11:55:20 -0800, David Brownell <david-b@pacbell.net> wrote:

> > > The more serious one is that sometimes it seems to spontaneously emit click
> > > events while I'm moving finger across pad.  Which means I've had to learn to
> > > plan my "mouse" motions to avoid areas where clicking could have bad effects.
> > > But that's not always possible ...
> > 
> > That is default sensitivity not suiting your habits I think.

That answer isn't good.  No defaults should be that dangerous!
But I suspect that's not really the issue...


> > I would 
> > recomment trying out Synaptics X driver (which also does ALPS) so you
> > will be able adjust sensitivity the way you like it.

With the Synaptics X driver (as supplied by SuSE -- but NOT configured
automatically by the system install tool) and the ALPS parameters in the
README.alps from synaptics-0.14.0, and kernel parameters "usb-handoff"
and "mousedev.tap_time=0", I'm getting somewhat better results in this
particular area.

I see some new "mouse"-specific failure modes though:

  (a) Sometimes tapping automagically generates extra clicks.  For
      example, pressing the delete button once will delete two or more
      mail messages.  Unfortunately it's not actually smart enough to
      only kick in for spam!  (I think this is exclusively when using
      the touchpad itself.)

  (b) Sometimes tapping the left button seems to start half a drag event.
      For example a GUI button's menu pops up rather than performing the
      action associated with the button.  That could be some funky UI
      settings, but it's not consistent ... and I've observed this with
      very quick button presses.  So I think something else is afoot.

  (c) Sometimes tapping seems to only generate a "down" event ... until
      I move the cursor, the "up" doesn't happen.  Again, this is with
      the left button, not the touchpad itself.

I haven't recently seen that nasty "motion emits random mouseclicks"
behavior, but given the way the hardware programs/trains user behavior,
it's hard to say for sure quite yet.

I've not done enough with non-GUI keyboard interactions to say if that
nasty keyboard blockage issue is gone or not; I wouldn't have seen it.


> I think the problem is that the tap detection in mousedev.c is very
> simplistic. It always generates a button click if the time between
> "finger down" and "finger up" is small enough, even if the finger was
> moved a large x/y distance. The X driver handles this with another
> parameter that specifies the maximum allowed distance. If the finger
> moved more than this distance, no button event is generated.

Sounds like "dueling heuristics" here!

I think the behavior I'm now seeing supports that hypothesis.  But
it's hard to say without knowing more about how all the pieces fit
together.

- Dave

Re: Touchpad problems with 2.6.11-rc2

[Peter Osterlund]

Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:

> On Tue, 25 Jan 2005 11:55:20 -0800, David Brownell <david-b@pacbell.net> wrote:
> > The more serious one is that sometimes it seems to spontaneously emit click
> > events while I'm moving finger across pad.  Which means I've had to learn to
> > plan my "mouse" motions to avoid areas where clicking could have bad effects.
> > But that's not always possible ...
> 
> That is default sensitivity not suiting your habits I think. I would
> recomment trying out Synaptics X driver (which also does ALPS) so you
> will be able adjust sensitivity the way you like it.

I think the problem is that the tap detection in mousedev.c is very
simplistic. It always generates a button click if the time between
"finger down" and "finger up" is small enough, even if the finger was
moved a large x/y distance. The X driver handles this with another
parameter that specifies the maximum allowed distance. If the finger
moved more than this distance, no button event is generated.

-- 
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340

Re: Touchpad problems with 2.6.11-rc2

[Dmitry Torokhov]

On Tue, 25 Jan 2005 11:55:20 -0800, David Brownell <david-b@pacbell.net> wrote:
> Quoth Pete Zaitcev:
> > ALPS Touchpad (Dualpoint) detected
> >   Disabling hardware tapping
> > input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
> 
> I have problems with an ALPS on serio4 ... different ones though.  And
> it may be that RC2 is a bit better here than previous kernels.
> 
> For example, it says it disabled tapping -- but it's still active.
> Evidently there are model-specific differences that the ALPS driver
> doesn't handle correctly.
>

Note that it says "Disabling hardware tapping". mousedev module still
does software tap emulation which can be turned off with
mousedev.tap_time = 0

> 
> > Looks like detection is correct, however either ALPS specific code doesn't work
> > right, or it sets wrong parameters, I cannot tell. Here's the list of problems,
> > from worst to least annoying:
> >
> > - Very often, keyboard stops working after a click. Typing anything has no effect.

I am not quite sure about the keyboard iteractions but all-in-all I
don't think ALPS support is really ready for prime-time yet, there
some issues with tap and double-tap detection. I think Peter has some
patches improving it though, but for now I recommend
psmouse.proto=imps.

> 
> The more serious one is that sometimes it seems to spontaneously emit click
> events while I'm moving finger across pad.  Which means I've had to learn to
> plan my "mouse" motions to avoid areas where clicking could have bad effects.
> But that's not always possible ...
> 

That is default sensitivity not suiting your habits I think. I would
recomment trying out Synaptics X driver (which also does ALPS) so you
will be able adjust sensitivity the way you like it.

-- 
Dmitry

Re: Touchpad problems with 2.6.11-rc2

[David Brownell]

Quoth Pete Zaitcev:
> ALPS Touchpad (Dualpoint) detected
>   Disabling hardware tapping
> input: AlpsPS/2 ALPS TouchPad on isa0060/serio1

I have problems with an ALPS on serio4 ... different ones though.  And
it may be that RC2 is a bit better here than previous kernels.

For example, it says it disabled tapping -- but it's still active.
Evidently there are model-specific differences that the ALPS driver
doesn't handle correctly.


> Looks like detection is correct, however either ALPS specific code doesn't work
> right, or it sets wrong parameters, I cannot tell. Here's the list of problems,
> from worst to least annoying:
> 
> - Very often, keyboard stops working after a click. Typing anything has no effect.
>   However, any smallest pointer movement will restore keyboard, and then an
>   application receives all buffered characters. This is very bad.

I've got similar interactions between keyboard and touchpad -- no-effect, than
after magic to unblock, a flood of characters.  The Way To Fix It is different
though.  There seems to be an interaction with window focus, since another
symptom is that for example there's no cursor in the active window ... until
it's fixed.  Sometimes things like newlines will cause scrolling, without any
other characters appearing... maybe there's a KDE/x86_64 interaction too.

 
> - Double-click sometimes fails to work. I have to wait a second and retry it.
>   Retrying right away is likely not to work again.
> 
> - Slow motion of finger produces no motion, then a jump. So, it's very hard to
>   target smaller UI elements and some web links.

I don't think I've seen either of those two problems.


I have two problems during mouse motion.  One of them is that sometimes it seems
to stop working or go into ultra-slow tracking mode.  Workaround:  wait a second,
start again; it's as if there's some timed mode that it automagically enters/exits.

The more serious one is that sometimes it seems to spontaneously emit click
events while I'm moving finger across pad.  Which means I've had to learn to
plan my "mouse" motions to avoid areas where clicking could have bad effects.
But that's not always possible ...

- Dave