Trying out 2.6.11-rc5, I discovered my ALPS touchpad misbehaving. After
reading several threads related to the topic, noe seemed to resolve my
issue.
The pad has always worked fine as a plain PS/2 mouse, from 2.4.0 through
2.6.10.
This change fixes the problem by NOT disabling hardware tapping:
--- linux-2.6.11-rc5/drivers/input/mouse/alps.c~ 2005-02-24 18:16:03.000000000 -0500
+++ linux-2.6.11-rc5/drivers/input/mouse/alps.c 2005-02-24 18:16:03.000000000 -0500
@@ -334,8 +334,8 @@
if (alps_get_status(psmouse, param))
return -1;
- if (param[0] & 0x04)
- alps_tap_mode(psmouse, 0);
+// if (param[0] & 0x04)
+// alps_tap_mode(psmouse, 0);
if (alps_absolute_mode(psmouse)) {
printk(KERN_ERR "alps.c: Failed to enable absolute mode\n");
@@ -372,11 +372,11 @@
return -1;
}
- if (param[0] & 0x04) {
- printk(KERN_INFO " Disabling hardware tapping\n");
- if (alps_tap_mode(psmouse, 0))
- printk(KERN_WARNING "alps.c: Failed to disable hardware tapping\n");
- }
+// if (param[0] & 0x04) {
+// printk(KERN_INFO " Disabling hardware tapping\n");
+// if (alps_tap_mode(psmouse, 0))
+// printk(KERN_WARNING "alps.c: Failed to disable hardware tapping\n");
+// }
if (alps_absolute_mode(psmouse)) {
printk(KERN_ERR "alps.c: Failed to enable absolute mode\n");
So now, can anyone explain what bit 3 of param[0] does, and why you would
want to disable hardware tapping support when it's set? My pad (ALPS
56AAA1760C on a Sager NP8560V) has always worked with hardware tapping as a
plain PS/2 mouse, no special ALPS support req'd.
Can this disabling of hardware tapping support be made optional (boot time
param or other)? I don't want to have to patch every kernel from here on
out.
Regards,
Ian Morgan
--
-------------------------------------------------------------------
Ian E. Morgan Vice President & C.O.O. Webcon, Inc.
imorgan at webcon dot ca PGP: #2DA40D07 http://www.webcon.ca
* Customized Linux Network Solutions for your Business *
-------------------------------------------------------------------
On Thursday 24 February 2005 18:29, Ian E. Morgan wrote:
> Trying out 2.6.11-rc5, I discovered my ALPS touchpad misbehaving. After
> reading several threads related to the topic, noe seemed to resolve my
> issue.
>
> The pad has always worked fine as a plain PS/2 mouse, from 2.4.0 through
> 2.6.10.
>
> This change fixes the problem by NOT disabling hardware tapping:
>
> --- linux-2.6.11-rc5/drivers/input/mouse/alps.c~ 2005-02-24 18:16:03.000000000 -0500
> +++ linux-2.6.11-rc5/drivers/input/mouse/alps.c 2005-02-24 18:16:03.000000000 -0500
> @@ -334,8 +334,8 @@
> if (alps_get_status(psmouse, param))
> return -1;
>
> - if (param[0] & 0x04)
> - alps_tap_mode(psmouse, 0);
> +// if (param[0] & 0x04)
> +// alps_tap_mode(psmouse, 0);
>
> if (alps_absolute_mode(psmouse)) {
> printk(KERN_ERR "alps.c: Failed to enable absolute mode\n");
> @@ -372,11 +372,11 @@
> return -1;
> }
>
> - if (param[0] & 0x04) {
> - printk(KERN_INFO " Disabling hardware tapping\n");
> - if (alps_tap_mode(psmouse, 0))
> - printk(KERN_WARNING "alps.c: Failed to disable hardware tapping\n");
> - }
> +// if (param[0] & 0x04) {
> +// printk(KERN_INFO " Disabling hardware tapping\n");
> +// if (alps_tap_mode(psmouse, 0))
> +// printk(KERN_WARNING "alps.c: Failed to disable hardware tapping\n");
> +// }
>
> if (alps_absolute_mode(psmouse)) {
> printk(KERN_ERR "alps.c: Failed to enable absolute mode\n");
>
>
>
> So now, can anyone explain what bit 3 of param[0] does, and why you would
> want to disable hardware tapping support when it's set? My pad (ALPS
> 56AAA1760C on a Sager NP8560V) has always worked with hardware tapping as a
> plain PS/2 mouse, no special ALPS support req'd.
>
> Can this disabling of hardware tapping support be made optional (boot time
> param or other)? I don't want to have to patch every kernel from here on
> out.
>
It still should do software tap emulation (although support is a bit flakey
with ALPS I must admit, but there are patches that should improve it) - so
people who don't like tapping can deactivate it.
Anyway, "psmouse.proto=exps" boot option should disable ALPS native mode and
restore previous behavior.
--
Dmitry
On Thu, Feb 24, 2005 at 10:08:15PM -0500, Dmitry Torokhov wrote:
> > So now, can anyone explain what bit 3 of param[0] does, and why you would
> > want to disable hardware tapping support when it's set? My pad (ALPS
> > 56AAA1760C on a Sager NP8560V) has always worked with hardware tapping as a
> > plain PS/2 mouse, no special ALPS support req'd.
> >
> > Can this disabling of hardware tapping support be made optional (boot time
> > param or other)? I don't want to have to patch every kernel from here on
> > out.
> >
>
> It still should do software tap emulation (although support is a bit flakey
> with ALPS I must admit, but there are patches that should improve it) - so
> people who don't like tapping can deactivate it.
>
> Anyway, "psmouse.proto=exps" boot option should disable ALPS native mode and
> restore previous behavior.
Also, in my tree currently (and planned for 2.6.12) hardware tapping is
enabled again, because double taps don't work otherwise (hardware
limitation).
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Sun, 27 Feb 2005, Vojtech Pavlik wrote:
> Also, in my tree currently (and planned for 2.6.12) hardware tapping is
> enabled again, because double taps don't work otherwise (hardware
> limitation).
You should really try to get that squeezed into 2.6.11 before it is
released, or else I would anticipate a LOT more people whining about their
broken touchpads.
Regards,
Ian Morgan
--
-------------------------------------------------------------------
Ian E. Morgan Vice President & C.O.O. Webcon, Inc.
imorgan at webcon dot ca PGP: #2DA40D07 http://www.webcon.ca
* Customized Linux Network Solutions for your Business *
-------------------------------------------------------------------
I would also appreciate the return of good resolution. Blocky mouse
startup moves make graphic editing rather difficult. No mouse movement
until I have moved my finger a significant distance then the mouse all
of a sudden jumps a dozen pixels before it "smoothly" glides along.
I would also love to see the sync issues go away. :/ Whatever this
patch(es) was supposed to accomplish, it introduced some rather
undesirable side effects. a) sync issues, b) tapping, c) fine grain
movements, d) loss of scroll sliding as well (moving your finger along
the side/bottom of the glidepoint).
Not griping, just providing feedback.
-david
Ian E. Morgan wrote:
> On Sun, 27 Feb 2005, Vojtech Pavlik wrote:
>
>> Also, in my tree currently (and planned for 2.6.12) hardware tapping is
>> enabled again, because double taps don't work otherwise (hardware
>> limitation).
>
>
> You should really try to get that squeezed into 2.6.11 before it is
> released, or else I would anticipate a LOT more people whining about
> their
> broken touchpads.
>
> Regards,
> Ian Morgan
>
On Tue, Mar 01, 2005 at 06:40:21AM -0500, David Ford wrote:
> I would also appreciate the return of good resolution. Blocky mouse
> startup moves make graphic editing rather difficult. No mouse movement
> until I have moved my finger a significant distance then the mouse all
> of a sudden jumps a dozen pixels before it "smoothly" glides along.
>
> I would also love to see the sync issues go away. :/ Whatever this
> patch(es) was supposed to accomplish, it introduced some rather
> undesirable side effects. a) sync issues, b) tapping, c) fine grain
> movements, d) loss of scroll sliding as well (moving your finger along
> the side/bottom of the glidepoint).
>
> Not griping, just providing feedback.
Can you check with a current -mm kernel whether any of the issues is
still there? Everything seems to work smoothly with my ALPS.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Tue, 1 Mar 2005 12:54:32 +0100, Vojtech Pavlik <[email protected]> wrote:
>
> Can you check with a current -mm kernel whether any of the issues is
> still there? Everything seems to work smoothly with my ALPS.
>
I have problems with ALPS and 2.6.11-mm1. If I move the pointer with
the touchpad, it activates button modifiers at the same time. (xev
reports a MotionNotify event with state = 0x600 or sometimes 0x200
instead of the expected 0x0).
Moreover the pointer sometimes jump at the bottom right of the screen.
It worked fine with 2.6.11-rc5-mm1.
relevant portion of dmesg:
- with rc5:
Linux version 2.6.11-rc5-mm1 (tonfa@casaverde) (gcc version
3.4.3-20050110 (Gentoo Linux 3. 4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7.7)) #2 Tue Mar 1 13:33:05 CET 2005
input: AT Translated Set 2 keyboard on isa0060/serio0
ALPS Touchpad (Dualpoint) detected
Enabling hardware tapping
input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
- with .11
Linux version 2.6.11-mm1 (tonfa@casaverde) (gcc version 3.4.3-20050110
(Gentoo Linux 3.4.3. 20050110, ssp-3.4.3.20050110-0,
pie-8.7.7)) #5 Fri Mar 4 16:49:47 CET 2005
input: AT Translated Set 2 keyboard on isa0060/serio0
Enabling hardware tapping
input: DualPoint Stick on isa0060/serio1
input: AlpsPS/2 ALPS DualPoint TouchPad on isa0060/serio1
I hope it can help.
Benoit
On Fri, Mar 04, 2005 at 10:02:03PM +0100, Benoit Boissinot wrote:
> On Tue, 1 Mar 2005 12:54:32 +0100, Vojtech Pavlik <[email protected]> wrote:
> >
> > Can you check with a current -mm kernel whether any of the issues is
> > still there? Everything seems to work smoothly with my ALPS.
> >
>
> I have problems with ALPS and 2.6.11-mm1. If I move the pointer with
> the touchpad, it activates button modifiers at the same time. (xev
> reports a MotionNotify event with state = 0x600 or sometimes 0x200
> instead of the expected 0x0).
>
> Moreover the pointer sometimes jump at the bottom right of the screen.
>
> It worked fine with 2.6.11-rc5-mm1.
>
> relevant portion of dmesg:
>
> - with rc5:
>
> Linux version 2.6.11-rc5-mm1 (tonfa@casaverde) (gcc version
> 3.4.3-20050110 (Gentoo Linux 3. 4.3.20050110,
> ssp-3.4.3.20050110-0, pie-8.7.7)) #2 Tue Mar 1 13:33:05 CET 2005
> input: AT Translated Set 2 keyboard on isa0060/serio0
> ALPS Touchpad (Dualpoint) detected
> Enabling hardware tapping
> input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
>
> - with .11
>
> Linux version 2.6.11-mm1 (tonfa@casaverde) (gcc version 3.4.3-20050110
> (Gentoo Linux 3.4.3. 20050110, ssp-3.4.3.20050110-0,
> pie-8.7.7)) #5 Fri Mar 4 16:49:47 CET 2005
> input: AT Translated Set 2 keyboard on isa0060/serio0
> Enabling hardware tapping
> input: DualPoint Stick on isa0060/serio1
> input: AlpsPS/2 ALPS DualPoint TouchPad on isa0060/serio1
>
> I hope it can help.
Can you check if this patch helps?
[email protected], 2005-03-04 20:19:05+01:00, [email protected]
input: Fix inverted conditions in ALPS DualPoint stick packet
decoding.
[email protected], 2005-03-04 21:55:23+01:00, [email protected]
input: Fix ALPS DualPoint stick buttons. Testing shows that they're
at the same place as the pad ones, but packet has z==127.
alps.c | 26 +++++++++---------------
1 files changed, 10 insertions(+), 16 deletions(-)
diff -Nru a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
--- a/drivers/input/mouse/alps.c 2005-03-04 22:00:33 +01:00
+++ b/drivers/input/mouse/alps.c 2005-03-04 22:00:33 +01:00
@@ -124,8 +124,8 @@
/* Relative movement packet */
if (z == 127) {
- input_report_rel(dev2, REL_X, (x > 383 ? x : (x - 768)));
- input_report_rel(dev2, REL_Y, -(y > 255 ? y : (x - 512)));
+ input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) : x));
+ input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) : y));
input_sync(dev2);
return;
}
diff -Nru a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
--- a/drivers/input/mouse/alps.c 2005-03-04 22:00:49 +01:00
+++ b/drivers/input/mouse/alps.c 2005-03-04 22:00:49 +01:00
@@ -115,20 +115,14 @@
ges = packet[2] & 1;
fin = packet[2] & 2;
- /* Dualpoint has stick buttons in byte 0 */
- if (priv->i->flags & ALPS_DUALPOINT) {
-
- input_report_key(dev2, BTN_LEFT, packet[0] & 1);
- input_report_key(dev2, BTN_MIDDLE, (packet[0] >> 2) & 1);
- input_report_key(dev2, BTN_RIGHT, (packet[0] >> 1) & 1);
-
- /* Relative movement packet */
- if (z == 127) {
- input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) : x));
- input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) : y));
- input_sync(dev2);
- return;
- }
+ if ((priv->i->flags & ALPS_DUALPOINT) && z == 127) {
+ input_report_key(dev2, BTN_LEFT, left);
+ input_report_key(dev2, BTN_RIGHT, right);
+ input_report_key(dev2, BTN_MIDDLE, middle);
+ input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) : x));
+ input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) : y));
+ input_sync(dev2);
+ return;
}
/* Convert hardware tap to a reasonable Z value */
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, 4 Mar 2005, Vojtech Pavlik wrote:
> /* Relative movement packet */
> if (z == 127) {
> - input_report_rel(dev2, REL_X, (x > 383 ? x : (x - 768)));
> - input_report_rel(dev2, REL_Y, -(y > 255 ? y : (x - 512)));
> + input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) : x));
> + input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) : y));
Not that I have any idea, but (y - 512) seems much more likely here.
> + if ((priv->i->flags & ALPS_DUALPOINT) && z == 127) {
> + input_report_key(dev2, BTN_LEFT, left);
> + input_report_key(dev2, BTN_RIGHT, right);
> + input_report_key(dev2, BTN_MIDDLE, middle);
> + input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) : x));
> + input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) : y));
Also here.
-Daniel
*This .sig left intentionally blank*
On Mon, Mar 07, 2005 at 02:14:17AM -0500, Daniel Barkalow wrote:
> On Fri, 4 Mar 2005, Vojtech Pavlik wrote:
>
> > /* Relative movement packet */
> > if (z == 127) {
> > - input_report_rel(dev2, REL_X, (x > 383 ? x : (x - 768)));
> > - input_report_rel(dev2, REL_Y, -(y > 255 ? y : (x - 512)));
> > + input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) : x));
> > + input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) : y));
>
> Not that I have any idea, but (y - 512) seems much more likely here.
>
> > + if ((priv->i->flags & ALPS_DUALPOINT) && z == 127) {
> > + input_report_key(dev2, BTN_LEFT, left);
> > + input_report_key(dev2, BTN_RIGHT, right);
> > + input_report_key(dev2, BTN_MIDDLE, middle);
> > + input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) : x));
> > + input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) : y));
>
> Also here.
Indeed. It took me a while to find it.
--
Vojtech Pavlik
SuSE Labs, SuSE CR