subject:"Re\: Touchpad problems with 2.6.11\-rc2"

On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote:
> Vojtech Pavlik <[EMAIL PROTECTED]> 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(>dev, ABS_X, 0, 1023, 0, 0);
>   input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0);
>   input_set_abs_params(>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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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 <[EMAIL PROTECTED]>
 
Thanks, applied.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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 [EMAIL PROTECTED]
 
Thanks, applied.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote:
 Vojtech Pavlik [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

Vojtech Pavlik <[EMAIL PROTECTED]> writes:

> On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote:
> > Vojtech Pavlik <[EMAIL PROTECTED]> 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(>dev, ABS_X, 0, 1023, 0, 0);
> > input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0);
> > input_set_abs_params(>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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote:
> Vojtech Pavlik <[EMAIL PROTECTED]> 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(>dev, ABS_X, 0, 1023, 0, 0);
>   input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0);
>   input_set_abs_params(>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.0 +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(>dev, ABS_X, 0, 1023, 0, 0);
> - input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0);
> + input_set_abs_params(>dev, ABS_Y, 0, 767, 0, 0);
>   input_set_abs_params(>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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

Vojtech Pavlik <[EMAIL PROTECTED]> 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(>dev, ABS_X, 0, 1023, 0, 0);
input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0);
input_set_abs_params(>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.0 +0100
+++ linux/drivers/input/mouse/alps.c2005-02-04 07:38:12.203436768 +0100
@@ -394,7 +394,7 @@
 
psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS);
input_set_abs_params(>dev, ABS_X, 0, 1023, 0, 0);
-   input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0);
+   input_set_abs_params(>dev, ABS_Y, 0, 767, 0, 0);
input_set_abs_params(>dev, ABS_PRESSURE, 0, 127, 0, 0);
 
psmouse->dev.keybit[LONG(BTN_TOUCH)] |= BIT(BTN_TOUCH);

-- 
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote:
> Vojtech Pavlik <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>

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

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

Vojtech Pavlik <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
---

 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-roundoff2005-02-02 
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c   2005-02-03 22:41:41.0 
+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, _mix.packet.buttons);
}
mousedev->touch = mousedev->pkt_count = 0;
+   mousedev->frac_dx = 0;
+   mousedev->frac_dy = 0;
}
else
if (!mousedev->touch)
_

-- 
Peter Osterlund - [EMAIL PROTECTED]

Re: Touchpad problems with 2.6.11-rc2

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=com_mode=2003=11=3
 
Maybe that's why IBM calls their Synaptics touchpad + IBM touchpoint
solution "IBM UltrNav(tm)"? ;)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

2005-02-03 Thread Dmitry Torokhov

On Thu, 03 Feb 2005 07:22:40 -0800 (PST), Alexandre Oliva
<[EMAIL PROTECTED]> wrote:
> On Feb  3, 2005, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, Feb 03, 2005 at 06:30:14AM -0200, Alexandre Oliva wrote:
> >> On Feb  2, 2005, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> >>
> >> > On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 
> >> > 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=com_mode=2003=11=3

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Feb  3, 2005, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:

> On Thu, Feb 03, 2005 at 06:30:14AM -0200, Alexandre Oliva wrote:
>> On Feb  2, 2005, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
>> 
>> > On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 
>> > 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   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

2005-02-03 Thread 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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Thu, Feb 03, 2005 at 06:30:14AM -0200, Alexandre Oliva wrote:
> On Feb  2, 2005, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Feb  2, 2005, Pete Zaitcev <[EMAIL PROTECTED]> wrote:

> On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 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   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Feb  2, 2005, Pete Zaitcev [EMAIL PROTECTED] wrote:

 On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik [EMAIL PROTECTED] 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   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Thu, Feb 03, 2005 at 06:30:14AM -0200, Alexandre Oliva wrote:
 On Feb  2, 2005, Pete Zaitcev [EMAIL PROTECTED] wrote:
 
  On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

2005-02-03 Thread 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)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Feb  3, 2005, Vojtech Pavlik [EMAIL PROTECTED] wrote:

 On Thu, Feb 03, 2005 at 06:30:14AM -0200, Alexandre Oliva wrote:
 On Feb  2, 2005, Pete Zaitcev [EMAIL PROTECTED] wrote:
 
  On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik [EMAIL PROTECTED] 
  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   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

2005-02-03 Thread Dmitry Torokhov

On Thu, 03 Feb 2005 07:22:40 -0800 (PST), Alexandre Oliva
[EMAIL PROTECTED] wrote:
On Feb 3, 2005, Vojtech Pavlik [EMAIL PROTECTED] wrote:

On Thu, Feb 03, 2005 at 06:30:14AM -0200, Alexandre Oliva wrote:
On Feb 2, 2005, Pete Zaitcev [EMAIL PROTECTED] wrote:

On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik [EMAIL PROTECTED]
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=englishcountry=comtop_mode=2003productId=11varietyId=3

--
Dmitry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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=englishcountry=comtop_mode=2003productId=11varietyId=3
 
Maybe that's why IBM calls their Synaptics touchpad + IBM touchpoint
solution IBM UltrNav(tm)? ;)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

Vojtech Pavlik [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
---

 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-roundoff2005-02-02 
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c   2005-02-03 22:41:41.0 
+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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line

Re: Touchpad problems with 2.6.11-rc2

On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote:
 Vojtech Pavlik [EMAIL PROTECTED] 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 [EMAIL PROTECTED]

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

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

Vojtech Pavlik [EMAIL PROTECTED] 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.0 +0100
+++ linux/drivers/input/mouse/alps.c2005-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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote:
 Vojtech Pavlik [EMAIL PROTECTED] 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.0 +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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

Vojtech Pavlik [EMAIL PROTECTED] writes:

 On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote:
  Vojtech Pavlik [EMAIL PROTECTED] 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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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
> > <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 23:58:05 +0100 (CET), Peter Osterlund <[EMAIL PROTECTED]> 
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005, Pete Zaitcev wrote:

> On 02 Feb 2005 21:57:39 +0100, Peter Osterlund <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005, Dmitry Torokhov wrote:

> On Wed, 02 Feb 2005 13:52:03 -0800 (PST), Peter Osterlund
> <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On 02 Feb 2005 21:57:39 +0100, Peter Osterlund <[EMAIL PROTECTED]> 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.0 
-0800
+++ linux-2.6.11-rc2-lem/drivers/input/mousedev.c   2005-02-02 
14:03:07.0 -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, _mix.packet.buttons);
}
mousedev->touch = mousedev->pkt_count = 0;
+   mousedev->frac_dx = 0;
+   mousedev->frac_dy = 0;
}
else
if (!mousedev->touch)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 02 Feb 2005 13:52:03 -0800 (PST), Peter Osterlund
<[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

Dmitry Torokhov <[EMAIL PROTECTED]> writes:

> On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
---

 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-roundoff2005-02-02 
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c   2005-02-02 22:20:15.0 
+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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

2005-02-02 Thread David Ford

What does one need to do to:
a) put tapping back in, and
b) fix the severe jerkiness with small movements
Thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
<[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

Pete Zaitcev <[EMAIL PROTECTED]> writes:

> On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
---

 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-roundoff2005-02-02 
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c   2005-02-02 21:42:39.0 
+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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 20:11:35 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, Feb 02, 2005 at 11:39:29AM -0800, Pete Zaitcev wrote:
> On Wed, 2 Feb 2005 20:11:35 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 09:58:51 -0800, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 
> > > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, Feb 02, 2005 at 09:58:51AM -0800, Pete Zaitcev wrote:
> On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 
> > > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote:
> On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 01, 2005 at 11:41:48PM -0800, Pete Zaitcev wrote:
> > On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Tue, Feb 01, 2005 at 11:41:48PM -0800, Pete Zaitcev wrote:
> On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <[EMAIL PROTECTED]> 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.0 
> -0800
> +++ linux-2.6.11-rc2-lem/drivers/input/mousedev.c 2005-02-01 
> 23:20:19.0 -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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Tue, Feb 01, 2005 at 11:41:48PM -0800, Pete Zaitcev wrote:
 On 30 Jan 2005 12:10:34 +0100, Peter Osterlund [EMAIL PROTECTED] 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.0 
 -0800
 +++ linux-2.6.11-rc2-lem/drivers/input/mousedev.c 2005-02-01 
 23:20:19.0 -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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
 On Tue, Feb 01, 2005 at 11:41:48PM -0800, Pete Zaitcev wrote:
  On 30 Jan 2005 12:10:34 +0100, Peter Osterlund [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote:
 On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, Feb 02, 2005 at 09:58:51AM -0800, Pete Zaitcev wrote:
 On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 
   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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 09:58:51 -0800, Pete Zaitcev [EMAIL PROTECTED] wrote:
 On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 
   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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, Feb 02, 2005 at 11:39:29AM -0800, Pete Zaitcev wrote:
 On Wed, 2 Feb 2005 20:11:35 +0100, Vojtech Pavlik [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 20:11:35 +0100, Vojtech Pavlik [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

Pete Zaitcev [EMAIL PROTECTED] writes:

 On 30 Jan 2005 12:10:34 +0100, Peter Osterlund [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
---

 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-roundoff2005-02-02 
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c   2005-02-02 21:42:39.0 
+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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
[EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

2005-02-02 Thread David Ford

What does one need to do to:
a) put tapping back in, and
b) fix the severe jerkiness with small movements
Thanks
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

Dmitry Torokhov [EMAIL PROTECTED] writes:

 On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
---

 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-roundoff2005-02-02 
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c   2005-02-02 22:20:15.0 
+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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 02 Feb 2005 13:52:03 -0800 (PST), Peter Osterlund
[EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On 02 Feb 2005 21:57:39 +0100, Peter Osterlund [EMAIL PROTECTED] 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.0 
-0800
+++ linux-2.6.11-rc2-lem/drivers/input/mousedev.c   2005-02-02 
14:03:07.0 -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)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005, Dmitry Torokhov wrote:

 On Wed, 02 Feb 2005 13:52:03 -0800 (PST), Peter Osterlund
 [EMAIL PROTECTED] 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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005, Pete Zaitcev wrote:

 On 02 Feb 2005 21:57:39 +0100, Peter Osterlund [EMAIL PROTECTED] 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 - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Wed, 2 Feb 2005 23:58:05 +0100 (CET), Peter Osterlund [EMAIL PROTECTED] 
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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
  [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

2005-02-01 Thread Pete Zaitcev

On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <[EMAIL PROTECTED]> 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.0 
-0800
+++ linux-2.6.11-rc2-lem/drivers/input/mousedev.c   2005-02-01 
23:20:19.0 -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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

2005-02-01 Thread Pete Zaitcev

On 30 Jan 2005 12:10:34 +0100, Peter Osterlund [EMAIL PROTECTED] 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.0 
-0800
+++ linux-2.6.11-rc2-lem/drivers/input/mousedev.c   2005-02-01 
23:20:19.0 -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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Tuesday 01 February 2005 00:06, Pete Zaitcev wrote:
> On Mon, 31 Jan 2005 22:40:35 -0500, Dmitry Torokhov <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Mon, 31 Jan 2005 22:40:35 -0500, Dmitry Torokhov <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Mon, 31 Jan 2005 13:46:08 -0800, Pete Zaitcev <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Tue, 25 Jan 2005 16:30:15 -0500, Dmitry Torokhov <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Tue, 25 Jan 2005 16:30:15 -0500, Dmitry Torokhov [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Mon, 31 Jan 2005 13:46:08 -0800, Pete Zaitcev [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2

On Mon, 31 Jan 2005 22:40:35 -0500, Dmitry Torokhov [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Touchpad problems with 2.6.11-rc2