Bug 14660 - ALPS Touchpad not recognized (73 02 64)
ALPS Touchpad not recognized (73 02 64)
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Input Devices
All Linux
: P1 normal
Assigned To: drivers_input-devices
:
: 15359 15933 16146 16681 18682 28152 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-21 16:34 UTC by Benjamin Howell
Modified: 2012-07-29 16:02 UTC (History)
72 users (show)

See Also:
Kernel Version: 2.6.31.5
Tree: Fedora
Regression: No


Attachments
dmesg with i8042.debug=1 kernel option set (70.82 KB, text/plain)
2009-11-21 16:34 UTC, Benjamin Howell
Details
output of cat /proc/bus/input/devices (2.78 KB, text/plain)
2009-11-21 16:36 UTC, Benjamin Howell
Details
Output of uname, dmesg, cat /proc/bus/input/devices, etc. (30.75 KB, application/x-gzip)
2010-06-06 17:48 UTC, Joe Gallo
Details
patch for ALPS 73,02,64 recognition (609 bytes, patch)
2010-06-08 20:18 UTC, Derek P. Moore
Details | Diff
Device initialization, sample finger swipe event data (11.94 KB, text/plain)
2010-08-11 03:33 UTC, Andrew Skalski
Details
Swipe event data, 6 bytes per line, binary (19.02 KB, text/plain)
2010-08-11 20:21 UTC, Arnout Engelen
Details
Swipe event data, parsed as 'absolute Mode - new format' (13.64 KB, text/plain)
2010-08-11 20:24 UTC, Arnout Engelen
Details
Shell script to help testing with serio_raw (2.26 KB, text/plain)
2010-08-11 22:57 UTC, Andrew Skalski
Details
event decoder C program (10.09 KB, text/plain)
2010-08-12 09:50 UTC, Andrew Skalski
Details
updated event decoder (11.38 KB, text/plain)
2010-08-12 21:35 UTC, Andrew Skalski
Details
modified dell IMPS emulation patch (8.05 KB, patch)
2010-08-23 16:49 UTC, Andrew Skalski
Details | Diff
Dmesg from acer aspire timeline 3820t with patch #32 (does not recognized touchpad) (288.22 KB, text/plain)
2010-09-17 20:26 UTC, ria.freelander
Details
Modified output of dmesg with patch on aspire 3820t (462.85 KB, text/plain)
2010-09-18 05:17 UTC, ria.freelander
Details
And another dmesg from aspire 3830t with patched module (953.49 KB, text/plain)
2010-09-18 05:31 UTC, ria.freelander
Details
dmesg with patched module running (desynchronized) (161.82 KB, text/x-log)
2010-09-28 11:28 UTC, ria.freelander
Details
ALPS v3 protocol support version 1 (25.28 KB, patch)
2011-09-01 20:42 UTC, Seth Forshee
Details | Diff
dmesg (57.79 KB, application/x-extension-1)
2011-09-03 09:59 UTC, juliusvonkohout
Details
registerdump (512.08 KB, application/octet-stream)
2011-09-06 12:12 UTC, juliusvonkohout
Details
Register dump on Dell E6420 on Fedora 14 (kernel 3.1.0-rc2) (512.08 KB, application/octet-stream)
2011-09-08 00:07 UTC, CJ
Details
Register dump on Dell N5110 on Fedora 15 (kernel 2.6.40.3) (512.08 KB, application/octet-stream)
2011-09-08 15:27 UTC, Daniel Hillier
Details
dmesg output on VAIO F111FX . Linux 3.2.4-1-ARCH (56.68 KB, text/plain)
2012-02-06 21:44 UTC, Mohammad Razeghi
Details
ALPS v4 Semi-Multitouch (buggy) (3.88 KB, patch)
2012-04-09 14:40 UTC, George Panta
Details | Diff

Description Benjamin Howell 2009-11-21 16:34:44 UTC
Created attachment 23857 [details]
dmesg with i8042.debug=1 kernel option set

I've got an HP Mini 311 with an ALPS touchpad that is not able to use a normal touchpad X11 driver and instead is recognized as an "ImPS/2 Generic Wheel Mouse" according to /proc/bus/input/devices. This is a new laptop model, so I suspect we just need to figure out how to get the kernel to recognize and report the ALPS hardware correctly.

I've attached dmesg output with the kernel option i8042.debug=1 set.
Comment 1 Benjamin Howell 2009-11-21 16:36:21 UTC
Created attachment 23858 [details]
output of cat /proc/bus/input/devices
Comment 2 Benjamin Howell 2009-11-23 13:50:48 UTC
Actually, it looks like I'm not going to be keeping this piece of hardware, so I won't be able to test any fix. Closing the bug report.
Comment 3 Dmitry Torokhov 2010-05-08 06:03:18 UTC
*** Bug 15359 has been marked as a duplicate of this bug. ***
Comment 4 Dmitry Torokhov 2010-05-08 06:06:52 UTC
*** Bug 15933 has been marked as a duplicate of this bug. ***
Comment 5 Cliff Wells 2010-06-06 02:51:54 UTC
I have an HP 311, which is the US version of the same hardware.   Would be happy to provide any additional data and/or be a tester.
Comment 6 Joe Gallo 2010-06-06 17:12:01 UTC
I have this hardware as well (on an HP dm3 laptop), and would like to help solve this.  I can provide more data and help test (as long as someone can hand-hold me a bit).
Comment 7 Joe Gallo 2010-06-06 17:48:39 UTC
Created attachment 26676 [details]
Output of uname, dmesg, cat /proc/bus/input/devices, etc.

Attached the output of uname, dmesg, xinput -list, cat /proc/bus/input/devices, etc. for 2.6.32 (detected as alps glidepoint) and 2.6.34 (detected as ImPS/2).
Comment 8 Dmitry Torokhov 2010-06-08 18:35:17 UTC
*** Bug 16146 has been marked as a duplicate of this bug. ***
Comment 9 Derek P. Moore 2010-06-08 20:18:23 UTC
Created attachment 26700 [details]
patch for ALPS 73,02,64 recognition

I was able to achieve recognition with the attached patch:

I: Bus=0011 Vendor=0002 Product=0008 Version=0000
N: Name="DualPoint Stick"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input6
U: Uniq=
H: Handlers=mouse1 event6 
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=3

I: Bus=0011 Vendor=0002 Product=0008 Version=7326
N: Name="AlpsPS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input7
U: Uniq=
H: Handlers=mouse2 event7 
B: EV=b
B: KEY=420 70000 0 0 0 0
B: ABS=1000003

...

My computer wouldn't auto-rebuild the nvidia kmod or boot into X after detection, but I'm not sure yet if that's related to the device being detected now or not.
Comment 10 Derek P. Moore 2010-06-08 20:38:10 UTC
I had problems booting X because I accidentally installed kernel-headers RPM instead of kernel-devel (for auto-rebuild of nvidia module).

I'm in X now with the detected device, and I'm able to see the Touchpad tab in GNOME Mouse Properties for configuration, but none of the features are being respected.  The touchpad is behaving as if it were in PS/2 Generic Mouse mode.
Comment 11 Cliff Wells 2010-06-08 20:46:04 UTC
According to this thread, this hardware uses a new protocol:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/527890/comments/50
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/550625

This explains why getting it recognized doesn't actually help at this point (if you intend to use it).
Comment 12 Sérgio M Basto 2010-07-05 18:50:48 UTC
I opened, 
https://bugs.freedesktop.org/show_bug.cgi?id=28802
which is based on 
https://bugzilla.redhat.com/show_bug.cgi?id=590880

with this patch:
https://bugzilla.redhat.com/attachment.cgi?id=412964

The touchpad is recognized 
https://bugzilla.redhat.com/show_bug.cgi?id=590880#c7

but I have some "missing properties" with synclient -l
Comment 13 Jonas Hauquier 2010-07-23 14:56:31 UTC
I have a Dell Latitude E6510 and also have this ALPS touchpad and same issues.
I can also test fixes if there are any.
Comment 14 Matthew Saltzman 2010-07-23 15:57:56 UTC
I have an E6410, and I can test as well.

I think the fact that this device is in Dell machines means it's going to become fairly popular fairly quickly.  I hope this can be fixed soon.  I miss scrolling and I know some others who miss being able to turn off tapping.
Comment 15 Fred 2010-07-30 22:38:41 UTC
I am having the same issue with a different computer, a DELL Precision M4500.
When checking the log file, I get the same ID :
psmouse serio1: ID: 73 02 64

Does anyone know if this bug is resolved yet, as it was open in November 2009, more than 8 months ago ?

Thank you
Comment 16 Dmitry Torokhov 2010-07-30 23:28:34 UTC
NO, the bug is not resolved as there needs to be a person why can reverse-engineer the new magic knock sequence and thus needs to have the hardware in question.
Comment 17 Cliff Wells 2010-07-30 23:37:59 UTC
Would remote access be sufficient?   I'd be willing to make an HP 311 available via SSH.
Comment 18 Matthew Saltzman 2010-07-31 00:03:48 UTC
Or is there code to run or a procedure to carry out that a volunteer could try?
Comment 19 Corona 2010-08-03 10:49:31 UTC
I'm also willing to test patches.
Comment 20 Andrew Skalski 2010-08-11 03:33:34 UTC
Created attachment 27402 [details]
Device initialization, sample finger swipe event data

I attached the initialization sequence done by the Windows driver over the AUX port, along with the event data generated by three example finger swipes over the touchpad.  Is there anything else I can do to help?
Comment 21 Dmitry Torokhov 2010-08-11 17:32:16 UTC
Very nice, thank you for doing this.
Comment 22 Arnout Engelen 2010-08-11 19:23:31 UTC
Browsing trough the initialization sequence, i saw a lot of 'ec' commands, usually followed by f0 and/or f6. 

There was no 'PSMOUSE_CMD_...' entry for ec yet in psmouse.h - after a quick google I found http://www.computer-engineering.org/ps2mouse/ which suggests it's a way to break out of a diagnostic 'wrap' mode. 'ec f0 f0' and 'ec f0 f6' are probably standard 'get back to defaults' sequences in this driver.

I guess we could add '#define PSMOUSE_CMD_RESET_WRAP  0x00ec' to psmouse.h

Nothing really jumps out as a 'magic knock' sequence here to me - all the switches of rate, resolution and scale are hard to make sense of... then again, I have zero experience with this anyway, so I wouldn't know what to look for.
Comment 23 Arnout Engelen 2010-08-11 20:19:32 UTC
The captured data obviously consists of 6-byte sequences. You could guess this would mean the data would simply be in 'ALPS absolute Mode - new format'-formatted packets.

I mocked up a small script to display Andrew's data in binary and 'parsed' as absolute. Indeed all the constants seem to align with 'ALPS absolute Mode', but the values for fin/ges/x/y/z don't seem quite right to me. Attached output.
Comment 24 Arnout Engelen 2010-08-11 20:21:57 UTC
Created attachment 27411 [details]
Swipe event data, 6 bytes per line, binary
Comment 25 Arnout Engelen 2010-08-11 20:24:41 UTC
Created attachment 27412 [details]
Swipe event data, parsed as 'absolute Mode - new format'
Comment 26 Andrew Skalski 2010-08-11 22:57:36 UTC
Created attachment 27413 [details]
Shell script to help testing with serio_raw

Attached is a shell script that can switch the AUX device (serio1) back and forth between the "psmouse" and "serio_raw" drivers.  While in serio_raw mode, you can read and write from /dev/serio_raw* to experiment with the touchpad protocol.

In serio_raw mode, the script can also dump the initialization sequence (the one I posted previously) out to the device, so that you can put it in "absolute" mode.

Usage: "alps-test.sh raw" ... "alps-test.sh init" ... "alps-test.sh psmouse"

A quick observation about the event data, based on a little experimentation.  The stick device (including its buttons) generates 6 bytes per event, and the touchpad (including its buttons) generates 30 bytes.

Stick device, left button down:
0000000 cf 00 00 49 00 3f

Stick device, left button release:
0000000 cf 00 00 48 00 3f

Touchpad, left button down:
0000000 8f 00 00 09 00 00 8f 00 00 09 00 00 8f 00 00 09
0000020 00 00 8f 00 00 09 00 00 8f 00 00 09 00 00

Touchpad, left button release:
0000000 8f 00 00 08 00 00 8f 00 00 08 00 00 8f 00 00 08
0000020 00 00 8f 00 00 08 00 00 8f 00 00 08 00 00
Comment 27 Andrew Skalski 2010-08-12 09:50:25 UTC
Created attachment 27416 [details]
event decoder C program

I have the event data format almost completely figured out, but there still a couple fields I'm uncertain about.  The attached C program will read event data from /dev/serio_raw*, decode, and output to stdout.  You will need my previously-attached shell script to bind the serio_raw driver, and to initialize the device.

gcc -Wall alps-decode.c -o alps-decode
./alps-test.sh raw
./alps-test.sh init
./alps-decode /dev/serio_raw*

There are three distinct event types, each 6 bytes long: pointing stick, touchpad coordinates+buttons, and touchpad x/y bitmap.  (The bitmap events are only sent when multi-touching, and are sent in addition to the normal touchpad events.)
Comment 28 Andrew Skalski 2010-08-12 21:35:12 UTC
Created attachment 27419 [details]
updated event decoder

I identified two more fields: One was the low-order bits of the touchpad "z" coordinate... the reading is so jittery, those bits are practically useless anyway.  The other field was a multi-touch "finger count", distinguishable through the x-axis and y-axis bitmaps as "groups of 1's separated by 0's".

My notes are in the attached updated decoder.
Comment 29 Arnout Engelen 2010-08-13 12:57:44 UTC
Looks like someone from Dell prepared a patch for the magic knocking sequence:

  https://patchwork.kernel.org/patch/118834/

doesn't looks like he added support for the new protocol though(?).
Comment 30 Arnout Engelen 2010-08-13 13:00:37 UTC
I suppose his patch enables the '4-byte "Intellimouse Mode"', while the windows driver above triggers and uses another (6-byte) protocol.
Comment 31 Andrew Skalski 2010-08-13 22:36:38 UTC
I tried the Dell patch, and scrolling now works, which was the biggest issue I wanted to solve.  It still doesn't support syndaemon though, and it would be nice to have control over hardware tapping.

I'm still working on decoding the initialization protocol, but have made a good amount of progress.  The beginning of the handshake is likely the basic mouse driver, which runs beneath the ALPS filter.  Where things get interesting is "ff e7e7e7 e9" and afterward.  The initialization consists almost entirely of reading from (and sometimes writing to) registers, with the exception of an instance where it asks to speak directly to the pointing stick.  On my device, the valid address range seems to be 0000-023f, but I didn't look very hard.

# Enable register access mode (The driver leads with an "EA", but it's not strictly required.)
(EA) EC EC EC E9

# Escape from register access mode
EA


While in register access mode, you can do three things:

# Switch to a new register address (4 nibbles, most significant first)
EC nibble3 nibble2 nibble1 nibble0

# Read byte from current register (reply: 2-byte address + 1-byte data)
E9

# Write data (there is no special command character)
nibble1 nibble0


Each 4-bit nibble is represented by a 1 or 2 byte PS/2 command:

0 : F0
1 : F6
2 : E7
3 : F3 0A
4 : F3 14
5 : F3 28
6 : F3 3C
7 : F3 50
8 : F3 64
9 : F3 C8
A : F2       *** Note: The F2 command responds with FA 00 (2 bytes as per PS/2 protocol)
B : E8 00
C : E8 01
D : E8 02
E : E8 03
F : E6


I haven't yet looked into what these registers actually do, though.
Comment 32 Andrew Skalski 2010-08-23 16:49:04 UTC
Created attachment 27731 [details]
modified dell IMPS emulation patch

Here's a modified version of the Dell IMPS emulation patch, which addresses:

- suspend/resume failure
- removes unsolicited modification of psmouse->type
- removes the single-entry lookup table
- simplified writing to device registers

I'm not 100% happy with how I'm falling back on IMPS mode, but I tried to do this without making major changes to how the psmouse layer works.

A handful of people are testing the attached patch over at launchpad:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/550625


I've figured out a few of the device registers which enable/disable features such as hardware tapping, the touchpad, the pointing stick, but I don't know enough about evdev to integrate with Xorg/syndaemon/whatever.

Regarding absolute mode, the protocol for this touchpad doesn't include the "fin" and "ges" bits, and I suspect that tapping, scrolling, and other gestures need to be handled within the driver.
Comment 33 Sérgio M Basto 2010-09-01 20:41:18 UTC
(In reply to comment #32)
> Created an attachment (id=27731) [details]
> modified dell IMPS emulation patch

I test yours patch on ferdora kernel 2.6.35.4-12, and seems to work pretty well.

Just a question, this should be controlled by synaptics ? 

[   943.402] (EE) Synaptics no synaptics event device found
[   943.430] (EE) Query no Synaptics: 6003C8
[   943.430] (EE) Synaptics Unable to query/initialize Synaptics hardware.
[   943.438] (EE) PreInit failed for input device "Synaptics"
[   943.684] (II) config/udev: Adding input device AlpsPS/2 ALPS GlidePoint (/dev/input/event5)
[   943.691] (II) AlpsPS/2 ALPS GlidePoint: Found 3 mouse buttons
[   943.691] (II) AlpsPS/2 ALPS GlidePoint: Found scroll wheel(s)
[   943.691] (II) AlpsPS/2 ALPS GlidePoint: Found relative axes
[   943.691] (II) AlpsPS/2 ALPS GlidePoint: Found x and y relative axes
[   943.691] (II) AlpsPS/2 ALPS GlidePoint: Configuring as mouse
[   943.691] (II) XINPUT: Adding extended input device "AlpsPS/2 ALPS GlidePoint" (type: MOUSE)
[   943.691] (II) AlpsPS/2 ALPS GlidePoint: initialized for relative axes.
[   943.692] (II) config/udev: Adding input device AlpsPS/2 ALPS GlidePoint (/dev/input/mouse0)
Comment 34 Sérgio M Basto 2010-09-02 21:44:25 UTC
(In reply to comment #33)
> (In reply to comment #32)
> > Created an attachment (id=27731) [details] [details]
> > modified dell IMPS emulation patch

After 2 or more suspends laptop lock hard and battery stops charge, I don't know if it is related !
Comment 35 Dmitry Torokhov 2010-09-16 18:15:35 UTC
*** Bug 18682 has been marked as a duplicate of this bug. ***
Comment 36 Paul J. Davis 2010-09-17 00:03:12 UTC
(In reply to comment #20)
> Created an attachment (id=27402) [details]
> Device initialization, sample finger swipe event data
> 
> I attached the initialization sequence done by the Windows driver over the AUX
> port, along with the event data generated by three example finger swipes over
> the touchpad.  Is there anything else I can do to help?

Testing the patch from #32 I don't get a recognized touch pad on the HP Mini 311. It's close but one of the byte patterns is a mismatch. If I disable that specific test I can get things initialized, but pointer movement is just noise (as in, touch the trackpad makes the pointer randomly jump across the screen). I can't remember the exact line, but its long after matching the E7 fingerprint which gives me hope that this might just be a minor protocol issue.

How did you manage to dump a trace of the driver initialization? I'm not familiar with programming on Windows, so any sort of Google keywords that'll point me in the right direction would even be helpful.

I'll be going over the protocol based on the initialization sequence in the patch from #32 for now. If I find that it's just a protocol difference I'll update the patch post it here.
Comment 37 ria.freelander 2010-09-17 20:26:58 UTC
Created attachment 30372 [details]
Dmesg from acer aspire timeline 3820t with patch #32 (does not recognized touchpad)
Comment 38 ria.freelander 2010-09-18 05:17:05 UTC
Created attachment 30482 [details]
Modified output of dmesg with patch on aspire 3820t
Comment 39 ria.freelander 2010-09-18 05:31:24 UTC
Created attachment 30492 [details]
And another dmesg from aspire 3830t with patched module
Comment 40 ria.freelander 2010-09-18 06:02:37 UTC
On Acer Aspire 3820t module works strange (2edged vertical scrolling works 10-30 seconds from manually probbing insmod psmouse, and then fallback to default), no recognition of tuochpad seen.
Comment 41 Dmitry Torokhov 2010-09-22 23:02:00 UTC
*** Bug 16681 has been marked as a duplicate of this bug. ***
Comment 42 Ivan Baidakou 2010-09-24 12:16:10 UTC
How can I assist with my "eMachines D440"? It has similar touchpad...
Comment 43 ria.freelander 2010-09-26 15:40:11 UTC
New testcase: last lines of dmesg with debugging enabled in patched alps.c:
alps.c: E6 report: 00 00 64
alps.c: E7 report: 73 02 64
alps.c: EC report: 88 07 8a
input: ImPS/2 Generic Wheel Mouse as /devices/platform/i8042/serio1/input/input10
Comment 44 ria.freelander 2010-09-28 11:28:58 UTC
Created attachment 31692 [details]
dmesg with patched module running (desynchronized)
Comment 45 Lado Kumsiashvili 2010-11-04 00:48:23 UTC
Any news?
Comment 46 Edward Herr 2010-11-04 12:20:09 UTC
I also have same issue running 2.6.37-rc1 on Acer AO721-3574 netbook.  ALPS touchpad identified as "PS/2 Generic Mouse".  Will try applying patches later today.

I: Bus=0011 Vendor=0002 Product=0001 Version=0000
N: Name="PS/2 Generic Mouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input8
U: Uniq=
H: Handlers=mouse0 event8 
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=3
Comment 47 ria.freelander 2010-11-04 16:14:34 UTC
What soft are you used for extract init sequence and can you attach EC report of HP Mini 311? I want to know about EC proto version of touchpad in it.
Comment 48 Sérgio M Basto 2010-11-16 21:26:43 UTC
(In reply to comment #29)
> Looks like someone from Dell prepared a patch for the magic knocking sequence:
> 
>   https://patchwork.kernel.org/patch/118834/
> 
> doesn't looks like he added support for the new protocol though(?).

I test this patch works well until suspend and resume laptop , after that touchpad is completed desynchronized , a freak show ...
Comment 49 Elias Probst 2010-11-30 23:39:11 UTC
The touchpad works on a DELL E6510 here. The only problem left: it is über-sensitive.
Typing some sentences without having a randomly jumping cursor is nearly impossible. 

I tried to reproduce this "jumping" by intentionally touching it with the heel of my thumb, but could never make the cursor jump that crazy as it sometimes does whilst typing.

Has anyone else seen this behaviour and knows a possible fix?
How could I provide further debug information for this problem?
Comment 51 Sérgio M Basto 2010-12-12 02:11:09 UTC
(In reply to comment #50)
Hi, good news , patch works for me with 
kernel-2.6.35.9-65.fc14 from src.rpm on
http://koji.fedoraproject.org/koji/buildinfo?buildID=208600
and patch https://patchwork.kernel.org/patch/350841/
even after 2 suspend to ram and resume.
Comment 52 David De Sousa 2011-01-06 03:07:38 UTC
Hi! I have this touchpad in my laptop, I'll be happy to help in debugging/testing patches to make this thing work.

the patch in patchwork.kernel.org does work, but not entirely, synaptics is not loaded into X, and you can't configure anything
Comment 53 Janmejay Singh 2011-01-09 01:41:10 UTC
I have a Dell Latitude E6510. Tried the patch from patchwork url in comment#50, it seems to work well. Have tried suspend/resume twice, no issues. All this is on 2.6.37 tag(had a clean merge).
Comment 54 VaKo 2011-01-12 12:05:44 UTC
I've got the same issue like ria.freelander@gmail.com from comment #43
alps.c: E6 report: 00 00 64
alps.c: E7 report: 73 02 64
alps.c: EC report: 88 07 8a

so this patch can't be applied(
Comment 55 David De Sousa 2011-01-12 13:12:30 UTC
I patched 2.6.37 too with comment #50 and it works, but still it's not recognized as a synaptics touchpad
Comment 56 Sérgio M Basto 2011-01-13 16:16:33 UTC
(In reply to comment #54)
> I've got the same issue like ria.freelander@gmail.com from comment #43
> alps.c: E6 report: 00 00 64
> alps.c: E7 report: 73 02 64
> alps.c: EC report: 88 07 8a
> 
> so this patch can't be applied(

You have a new patch on #50
Comment 57 VaKo 2011-01-14 19:09:02 UTC
New patch didn't bring anything new in device recognition, also because it include special Dell model check (I'm not on Dell).
Maximum, that I can reach is touchpad recognition and trackpad tab enabled (with new 2.6.37 kernel), but it useless anyway, because I can control it.
Comment 58 Sérgio M Basto 2011-01-20 04:40:19 UTC
(In reply to comment #57)
> New patch didn't bring anything new in device recognition, also because it
> include special Dell model check (I'm not on Dell).
> Maximum, that I can reach is touchpad recognition and trackpad tab enabled
> (with new 2.6.37 kernel), but it useless anyway, because I can control it.

yeah, right,
as Peter Hutterer wrote : 
kernel bug. the kernel needs to send the right magic command to the touchpad
so it actually looks like a touchpad. otherwise it looks like a generic PS2
mouse to us and everything else is hidden by the hardware. this is a common
problem for newer touchpads and usually consists of finding the right magic
sequence.

we have a patch at #32, that seems have the "the right magic
sequence" , but is like just a draft , can't help to build the synatics drive ?
Comment 59 VaKo 2011-01-20 07:54:52 UTC
as I dig in Windows driver, it have much more complicate init sequence, that, as I think, arrange this "wrong answer" 88 07 8a from hardware.
Comment 60 ria.freelander 2011-01-30 13:57:37 UTC
VaKo, can you post Windows Driver init sequence?
Comment 61 VaKo 2011-01-31 10:51:50 UTC
actually no, because it's more complicated, than I expect (not just send some command and analyze an answer, but also some memory manipulations, I can't understand clearly). also it used for all ALPS models, so, till the moment, I didn't figure out which init sequence is ours.
BTW, seems like 730264 E7 answer is correct for different models (that give us two different answers on EC comand request: 88079b and 88078a)
Comment 62 Jaap Crezee 2011-03-22 09:02:49 UTC
Let's kick this thread again.
I can confirm the following patch works for me with 2.6.38 on mij Dell Latitude E6510

https://patchwork.kernel.org/patch/118834/

So please commit it upstream or if it is not good enough: fix it and then commit.

---
Infos:

[root@jaaplaptop jaap]# dmidecode -s "system-product-name"
Latitude E6510
[root@jaaplaptop jaap]# 

[jaap@jaaplaptop ~]$ xinput -list | grep -i alps
â   â³ ImPS/2 ALPS GlidePoint                   id=14   [slave  pointer  (2)]
[jaap@jaaplaptop ~]$
Comment 63 Sérgio M Basto 2011-03-22 17:35:36 UTC
(In reply to comment #62)
> Let's kick this thread again.
> I can confirm the following patch works for me with 2.6.38 on mij Dell Latitude
> E6510
> 
> https://patchwork.kernel.org/patch/118834/

you have https://patchwork.kernel.org/patch/350841/
which fix suspend/resume issues and restricting the
quirks to Dell portables only.
but as explain in this bug report, this enable touchpad as generic PS/2 mouse and still not recognized as a synaptics touchpad. 
So won't go upstream ... . Not my choice, I prefer have scroll.
Comment 64 Jaap Crezee 2011-03-22 17:37:57 UTC
You are right, my system won't shutdown automatically anymore.
Anyway, I prefer scrolling :).
Comment 65 Ian 2011-03-22 18:26:57 UTC
I was able to fix my suspend/resume issues by adding "acpi_sleep=nonvs" to my kernel boot options, following the advice here: 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/596080/comments/16

Will this patch plus those kernel args give me a scrolling+sleeping+resuming system?
Comment 66 Sérgio M Basto 2011-03-22 18:52:32 UTC
you have https://patchwork.kernel.org/patch/350841/
which fix suspend/resume issues and restricting the
quirks to Dell portables only.

which part you don't understand ? 

Please read the post before , sending reports
Comment 67 Ian 2011-03-22 19:07:17 UTC
if i understood your previous post correctly, you were saying that jaap's patch fixes the scrolling problem, but also breaks suspend/resume; for that reason, it won't go upstream.  

i'm asking whether the suspend/resume problem caused by jaap's patch can be fixed by setting acpi_sleep=nonvs, and if so, would that enable jaap's patch to go upstream.  

these are yes/no questions.
Comment 68 Sérgio M Basto 2011-03-22 19:36:57 UTC
(In reply to comment #67)
> if i understood your previous post correctly, you were saying that jaap's patch
> fixes the scrolling problem, but also breaks suspend/resume; for that reason,
> it won't go upstream.  
> 
> i'm asking whether the suspend/resume problem caused by jaap's patch can be
> fixed by setting acpi_sleep=nonvs, and if so, would that enable jaap's patch to
> go upstream.  
> 
> these are yes/no questions.

no , 2nd patch fix , correct , not any more a problem,  the suspend/resume , which have the 1st patch  have.
Comment 69 Elias Probst 2011-03-23 00:13:06 UTC
(In reply to comment #62)
> Let's kick this thread again.
> I can confirm the following patch works for me with 2.6.38 on mij Dell Latitude
> E6510
> 
> https://patchwork.kernel.org/patch/118834/

This patch caused major issues on my Dell Latitude E6510 using 2.6.38-rc8+

- Partial broken input under X: most clicks were just ignored, randomly some inbetween worked. Shifted focus of mouse.
- Moving the mouse made the cursor go mad, racing across the screen, randomly clicking (left+right) things
- Frozen window manager focus

All this things happened during a 2h period while trying this patch.
After just de-applying the patch from my Kernel and changing nothing else, everything is back to normal and working fine so far.

I think the support for this Alps touchpad should be properly rewritten from the ground up.
Comment 70 Janmejay Singh 2011-03-23 00:57:55 UTC
I have been using this patch: https://patchwork.kernel.org/patch/350841/ for sometime now. So may be, this will help:

- https://patchwork.kernel.org/patch/350841/ works well across suspend/resume(consistently) [however, https://patchwork.kernel.org/patch/118834/ results in crazy mouse pointer after suspend/resume].

- It seems there is another bug on D6510 that sometimes causes screen to go blank after suspend/resume and inputs(keyboard and mouse) are blocked. Every-time this happened to me I had to 'force restart'. Most of the times when i force-restarted after this problem, the quirk didn't engage. As in, my touchpad was detected as PS/2 mouse and fringe scroll didn't work. But reboot sometimes made it work again. 

- I tried dropping some printk statements in the quirk init code, but none of that initialization executed when my touchpad was detected as PS/2 mouse. Haven't tried to investigate any further yet.

All of this is with tag v2.6.37 + https://patchwork.kernel.org/patch/350841/

Haven't tried it with v2.6.38 yet.
Comment 71 moutzl 2011-04-08 10:35:21 UTC
Anyone know a solution how to turn off touchpad and continue using trackpoint?(except opening case and disconnecting touchpad :)
I have Dell E6410 and this option is not in BIOS, and patches around are just to enable scrolling, so Im currious if there is some workaround or I have to wait for new driver for Alps2 touchpad.
Comment 72 Patrick Chilton 2011-05-02 08:58:00 UTC
I have the same problem on a Packard Bell EasyNote TX86. I tried 2.6.38-ARCH with https://patchwork.kernel.org/patch/350841/ and ALPS/2 GlidePoint showed up in xinput alongside PS/2 Mouse, but as far as I know I didn't get any synaptics features. synclient -m didn't output anything.
Comment 73 Patrick Chilton 2011-05-04 13:10:25 UTC
(In reply to comment #72)
> I have the same problem on a Packard Bell EasyNote TX86. I tried 2.6.38-ARCH
> with https://patchwork.kernel.org/patch/350841/ and ALPS/2 GlidePoint showed up
> in xinput alongside PS/2 Mouse, but as far as I know I didn't get any synaptics
> features. synclient -m didn't output anything.

I didn't realize it checks to see if it's running on a Dell. I commented that out and it works!

Here's my DMI info:

System Information
	Manufacturer: Packard Bell   
	Product Name: EasyNote TX86                  
	Version: V1.11

Chassis Information
	Manufacturer: Packard Bell   
	Type: Notebook
	Version: V1.11
Comment 74 Jason 'vanRijn' Kasper 2011-05-06 20:42:49 UTC
Same question as moutzi in comment #71. =:/
Comment 75 Weng Xuetian 2011-05-16 03:59:41 UTC
Thanks to #73, I also found this problem.

I manually add a new entry in the quirk table and found vertical scroll works.

$ dmidecode --type chassis 
# dmidecode 2.11
SMBIOS 2.6 present.

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
        Manufacturer: Gateway         
        Type: Notebook
        Lock: Not Present
        Version: V1.04
        Serial Number: LXWMW0C0010300F5431601
        Asset Tag:                  
        Boot-up State: Safe
        Power Supply State: Safe
        Thermal State: Safe
        Security Status: None
        OEM Information: 0x00000000
        Height: Unspecified
        Number Of Power Cords: 1
        Contained Elements: 0
        SKU Number: Not Specified
Comment 76 Patrick Chilton 2011-05-17 16:07:58 UTC
comment #73 here, vertical scrolling now works but rmmod and system shutdown hang when psmouse is removed.
Comment 77 Dmitry Torokhov 2011-05-18 23:29:49 UTC
(In reply to comment #71)
> Anyone know a solution how to turn off touchpad and continue using
> trackpoint?

Not until proper support added to the alps.c driver and touchpad and trackpoint are presented as 2 logically independent devices to userspace.
Comment 78 Sérgio M Basto 2011-05-19 02:17:11 UTC
for when a drive that recognized as a synaptics touchpad ?
this is dual-touch isn't it ?
Comment 79 moutzl 2011-05-19 07:48:32 UTC
Ok, someone know about some development? Or I have to open case and cut the wires to the touchpad?
Comment 80 Avi Romanoff 2011-05-19 20:37:34 UTC
aroman@hades:~$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ ImPS/2 ALPS GlidePoint                  	id=12	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ Laptop_Integrated_Webcam_FHD            	id=10	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=11	[slave  keyboard (3)]
    ↳ Dell WMI hotkeys                        	id=13	[slave  keyboard (3)]
aroman@hades:~$ uname -a
Linux hades 2.6.38-9-generic #43-Ubuntu SMP Thu Apr 28 15:23:06 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
___

I can confirm that this issue affects my laptop, a Dell Vostro 3550 (most recent model). I am very willing/able to test any patches and be of help if I can, I could provide SSH access to my laptop if needed. I also have a Windows 7 partition with the properly functioning Windows driver, so if anyone could tell me what to do to help them reverse engineer something (I gather what is needed right now is someone to crack the "magic code" for these new ALPS touchpads), I'd be happy to help.

What works with my touchpad is:

- Tap to click
- Vertical scrolling via the far right side of the trackpad
- Both physical mouse buttons

It is not recognized by synaptic, and I am unable (or don't know how) to disable the touchpad, enable horizontal scrolling, disable tap-to-click, or generally configure the trackpad at all.

Here's the hoping this bug gets fixed soon :)
Comment 81 skrobul+kernelbug 2011-05-26 00:01:36 UTC
I can confirm exactly the same bug on Dell E6420. I've applied patch https://patchwork.kernel.org/patch/350841/ and it gave me at least vertical scroll, but broke suspend/resume.
Comment 82 Joe Gallo 2011-05-26 12:55:21 UTC
I still have the laptop I mentioned above that is affected by this problem, but I hardly ever use it anymore.  I would be willing to pay to ship it to an interested kernel developer (and later pay to ship it back to myself when they're done).

Any takers?
Comment 83 Paul Gideon Dann 2011-06-02 12:29:57 UTC
I have a Dell Latitude E5520 with this issue; also happy to help in any way I can.
Comment 84 Francisco Cribari 2011-06-03 12:25:28 UTC
I have a DELL Latitude E6510 notebook and I am also affected by this bug. I run Ubuntu 11.04 (64 bit). The problem also occurred with 10.04 and 10.10. I have no touchpad tab in the mouse preferences panel. The cursor was jumping erratically until I found a workaround: the Python script in #41 of 

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238

Before using this script I suffered for several months with a cursor that would erratically jump a few lines up or down while I was typing.
Comment 85 Aleksey 2011-06-06 18:18:43 UTC
I have Dell Latitude E6520 and I am also affected. I run also ubuntu 11.04.

At the moment the Dual point touchpad is not recognized propely; xinput shows it as "ImPS/2 ALPS GlidePoint".

I do not run the mentioned Python script, but I just enable/disable the touchpad by a simple script thorugh xinput and attached this script to the Fn+F5 key combination (it then even shows the Dell-developed little picture appearing for a second in the right top corner showing the touchpad enabled/disabled)

But it would be really nice to have it sorted!

Also: I have E5510, where the problem is basically the same now.

Many thanks!
Comment 86 Sérgio M Basto 2011-07-12 01:45:26 UTC
I found this bug report : 
Several Ubuntu-certified Dell laptops: ImPS/2 ALPS GlidePoint configure as PS/2 mouse instead of proper touchpad.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/760142
Comment 87 Kåre Fiedler Christiansen 2011-07-14 16:01:27 UTC
I have contacted Rezwanul Kabir, the Dell author for the patch that enables IntelliMouse support. He has a lot of interesting info, which he kindly allowed me to quote. Here are some snippets from our conversation:
-----
Me:
 Do you, or anyone else at Dell, have the specifications from
 Alps needed to write a full driver? As I understand it, your
 patch will not give full Alps touchpad capabilities, but
 rather initialise it as "Intellimouse mode".
rez:
 Dell does not have this specification. I would have provided the full support otherwise.
 ALPS has refused to provide the specifications due to what they consider as IP issues. They
 agreed to open up only the "Intellimouse Mode" part of the spec and the patch was based
 on that.
Me:
 Thank you, it's nice to have accurate information here, since it seems
 that ALPS have misled others to understand that Dell had the
 information and could release it if they wish.
rez:
 If that is what ALPS is saying, then it's defintely not right.
-----
So Dell does not have the info, it is Alps we should be bugging.

Rez also wrote:
-----
Me:
 I believe this is important for Dell. Even if you do not officially
 support these brands of computers with Linux, it will still hurt sales
 if something as trivial as mouse support doesn't work with Linux on your
 hardware. I hope Dell will make sure that the specifications for the
 Alps touchpad are made available for open source drivers.
rez:
 I agree that we need the full support and I have been working with ALPS to provide
 us a driver that we can install out of the factory. Unfortunately, that driver will
 not be open source. ALPS has already delivered a beta release for RHEL6.0 driver that
 we are testing currently and will be posted for customers after that. Releases for
 Ubuntu versions are also underway.
Me:
 That's very interesting. I'm a little worried, since proprietary
 drivers tend to implement only part of the interfaces, and be very
 difficult to get bugs fixed in.
 For instance the proprietary nvidia driver does not respond well to
 all xrandr extensions, and flash has a few well known semi-trivial
 outstanding bugs that never seem to get any attention. I hope we can
 expect better from ALPS, but I guess we will see.
 I hope the RHEL driver will work with Fedora and other RPM-based
 distributions too...
rez:
 I don't know yet what type of constraints there are with their driver. I agree
 with what you said about proprietery drivers..Definitely not ideal and I have
 communicated our preferences for open source driver to them but they refused
 due to IP issues, as I have mentioned earlier.
-----
So closed-source drivers are on their way for RHEL and Ubuntu.
Dell is pushing for an open source driver, but ALPS refuses.

So it seems the avenues open are getting the information from ALPS or reverse engineering.
Comment 88 Dmitry Torokhov 2011-07-15 01:33:20 UTC
I though full initialization sequence was already posted here. Someone (Dell themselves maybe?) with the hardware should play with it and adjust our stock ALPS driver.
Comment 89 moutzl 2011-07-15 09:21:04 UTC
At all, good news.Thanks for info
Comment 90 Jaap Crezee 2011-07-15 09:35:30 UTC
Can anyone post a link to these 'cloused' drivers?
Comment 91 Adrian 2011-07-21 04:20:06 UTC
(In reply to comment #87)
>ALPS has already delivered a beta release for RHEL6.0

do you know where I can download the beta driver? would like to test it. thx
Comment 92 Paul Johnson 2011-07-26 02:46:42 UTC
As far as I know, the most recent version of the patch is https://patchwork.kernel.org/patch/350841

I wrote out my understanding of the situation: 

http://pj.freefaculty.org/blog/alps-touchpad-linux-final-statement-now

Along with the firefox addon called "Grab and Drag", I find I can get most of the synaptics features I actually use...
Comment 93 CJ 2011-07-28 00:02:18 UTC
I just tried patch (https://patchwork.kernel.org/patch/350841) on top of 2.6.39 kernel from kernel.org on Dell E6420. And it still doesn't work. I am running fedora 14.

I: Bus=0011 Vendor=0002 Product=0005 Version=7326
N: Name="ImPS/2 ALPS GlidePoint"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse0 event5 
B: PROP=0
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=103
Comment 94 Paul Johnson 2011-07-29 14:21:23 UTC
CJ: That is what the patch is supposed to do.  What do you mean "still doesn't work"?

If you get right side scrolling, double-tap to execute, and the cursor does not fly about randomly as you type, then you have everything this is supposed to give.  See the blog post I referenced in #92.
Comment 95 CJ 2011-07-29 20:17:40 UTC
Paul,

I just notice that I have to use the "right side vertical scrolling". Yes, all those are working, just the "synclient -l" still can't find device.

Thanks,
CJ
Comment 96 Adrian 2011-08-02 04:23:39 UTC
someone know how to patch kernel 3.0 ?
i am using ubuntu 11.04 and I have installed:

$ uname -r
3.0.0-0300-generic

when I try this: 

sudo apt-get build-dep --no-install-recommends linux-image-$(uname -r)
[sudo] password for adrian: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Picking 'linux' as source package instead of 'linux-image-3.0.0-0300-generic'
..... -> DOWNLOADING STUFF FOR 2.6.38 <-

...

$ apt-get source linux-image-$(uname -r)
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Picking 'linux' as source package instead of 'linux-image-3.0.0-0300-generic'
NOTICE: 'linux' packaging is maintained in the 'Git' version control system at:
http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-natty.git
Skipping already downloaded file 'linux_2.6.38-10.46.dsc'
Skipping already downloaded file 'linux_2.6.38.orig.tar.gz'
Skipping already downloaded file 'linux_2.6.38-10.46.diff.gz'
Need to get 0 B of source archives.
Skipping unpack of already unpacked source in linux-2.6.38


Again changing 3.0 for 2.6.38.... what can I do?
Right now click on tab works, mousemovement works and select on double click. doesn't work: vertical scroll etc...


$ sudo lsinput

...

/dev/input/event7
   bustype : BUS_I8042
   vendor  : 0x2
   product : 0x1
   version : 0
   name    : "PS/2 Generic Mouse"
   phys    : "isa0060/serio1/input0"
   bits ev : EV_SYN EV_KEY EV_REL

...


What I want is that AT LEAST vertical scroll works... right now with kernel 3.0 I have NO scroll.

cheers
adrian
Comment 97 Paul Johnson 2011-08-10 01:08:14 UTC
Dear Adrian:

Your problem happens because you are NOT currently running the 3.0 kernel. uname is asking your system what you run now, so you are not getting what you need.

As luck would have it, Debian testing released a kernel-3.0 version and so I just went through the patch. It works just fine, so far as I can tell. I mean, it does give the benefits I claimed before, no more, no less (no true synaptics features, in other words).  

I did the work in Emacs shell, so you can review the gory details for yourself. Except for 2 times that I forgot to type "sudo", which I deleted, this is a verbatim transcript. Note that the 3.0 kernel still shows up as patched version of 2.6.  But it is 3.0.0 as you can see:

pauljohn@pjlap-124:~$ uname -r
3.0.0-1-amd64

pauljohn@pjlap-124:~$ sudo apt-get build-dep --no-install-recommends linux-image-$(uname -r)
[sudo] password for pauljohn: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Picking 'linux-2.6' as source package instead of 'linux-image-3.0.0-1-amd64'
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

pauljohn@pjlap-124:~$ apt-get source linux-image-$(uname -r)
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Picking 'linux-2.6' as source package instead of 'linux-image-3.0.0-1-amd64'
NOTICE: 'linux-2.6' packaging is maintained in the 'Svn' version control system at:
svn://svn.debian.org/svn/kernel/dists/sid/linux-2.6/
Need to get 97.8 MB of source archives.
Get:1 http://ftp.debian.org/debian/ testing/main linux-2.6 3.0.0-1 (dsc) [5,983 B]
Get:2 http://ftp.debian.org/debian/ testing/main linux-2.6 3.0.0-1 (tar) [97.1 MB]
Get:3 http://ftp.debian.org/debian/ testing/main linux-2.6 3.0.0-1 (diff) [681 kB]
Fetched 97.8 MB in 11min 30s (141 kB/s)
gpgv: keyblock resource `/home/pauljohn/.gnupg/trustedkeys.gpg': file open error
gpgv: Signature made Sun 24 Jul 2011 03:52:57 AM CDT using RSA key ID 95861109
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./linux-2.6_3.0.0-1.dsc
dpkg-source: info: extracting linux-2.6 in linux-2.6-3.0.0
dpkg-source: info: unpacking linux-2.6_3.0.0.orig.tar.gz
dpkg-source: info: applying linux-2.6_3.0.0-1.diff.gz

pauljohn@pjlap-124:~$ cd linux-2.6-3.0.0/


pauljohn@pjlap-124:linux-2.6-3.0.0$ wget https://patchwork.kernel.org/patch/350841/raw/ -O touchpad.patch
--2011-08-09 19:54:46--  https://patchwork.kernel.org/patch/350841/raw/
Resolving patchwork.kernel.org (patchwork.kernel.org)... 140.211.167.41, 140.211.167.43
Connecting to patchwork.kernel.org (patchwork.kernel.org)|140.211.167.41|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/x-patch]
Saving to: “touchpad.patch”

    [ <=>                                   ] 5,921       --.-K/s   in 0.006s  

2011-08-09 19:54:47 (890 KB/s) - “touchpad.patch” saved [5921]

pauljohn@pjlap-124:linux-2.6-3.0.0$ patch -p1 < touchpad.patch 
patching file drivers/input/mouse/alps.c
patching file drivers/input/mouse/alps.h
patching file drivers/input/mouse/psmouse-base.c
Hunk #1 succeeded at 661 (offset 2 lines).
pauljohn@pjlap-124:linux-2.6-3.0.0$ cd drivers/input/mouse
pauljohn@pjlap-124:mouse$ make -C /lib/modules/`uname -r`/build M=`pwd` psmouse.ko
make: Entering directory `/usr/src/linux-headers-3.0.0-1-amd64'
  CC [M]  /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/psmouse-base.o
  CC [M]  /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/synaptics.o
  CC [M]  /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/alps.o
  CC [M]  /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/elantech.o
  CC [M]  /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/logips2pp.o
  CC [M]  /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/lifebook.o
  CC [M]  /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/sentelic.o
  CC [M]  /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/trackpoint.o
  LD [M]  /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/psmouse.o
  MODPOST 1 modules
  CC      /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/psmouse.mod.o
  LD [M]  /home/pauljohn/linux-2.6-3.0.0/drivers/input/mouse/psmouse.ko
make: Leaving directory `/usr/src/linux-headers-3.0.0-1-amd64'

pauljohn@pjlap-124:mouse$ sudo /sbin/rmmod psmouse
[sudo] password for pauljohn: 

pauljohn@pjlap-124:mouse$ sudo cp /lib/modules/3.0.0-1-amd64/kernel/drivers/input/mouse/psmouse.ko /lib/modules/3.0.0-1-amd64/kernel/drivers/input/mouse/psmouse.ko-orig

pauljohn@pjlap-124:mouse$ sudo cp psmouse.ko /lib/modules/3.0.0-1-amd64/kernel/drivers/input/mouse/psmouse.ko

pauljohn@pjlap-124:mouse$ sudo /sbin/modprobe psmouse
pauljohn@pjlap-124:mouse$
Comment 98 Sérgio M Basto 2011-08-10 15:17:30 UTC
(In reply to comment #97)
> As luck would have it, Debian testing released a kernel-3.0 version and so I
> just went through the patch. It works just fine, so far as I can tell. I mean,
> it does give the benefits I claimed before, no more, no less (no true synaptics
> features, in other words).  

On fedora kernel 2.6.40 which is a 3.0, no synaptics was found, so nothing new , is a patch just applied to Debian kernels ? 


> pauljohn@pjlap-124:linux-2.6-3.0.0$ wget
> https://patchwork.kernel.org/patch/350841/raw/ -O touchpad.patch

err.. this patch is old, very old, have almost one year, and _not_ enable synaptics features on this ALPS.
Comment 99 Paul Johnson 2011-08-10 22:42:23 UTC
Sear Sergio:

I don't mean to be too unkind, but please read at least a little bit of the thread before making silly comments. All of your questions have been answered. Especially review this post and the site to which it refers.

https://bugzilla.kernel.org/show_bug.cgi?id=14660#c92

This gives the background on the ALPS company refusing to provide driver information: 

https://bugzilla.kernel.org/show_bug.cgi?id=14660#c87

If there is a newer patch, GIVE THE ADDRESS. I was amazed that the patch still applies cleanly to kernel-3.0.

The patch is not distributed with Debian's kernel, that's why I explained how to apply it! AFAIK, most distributions do not apply the patch because it has been put into and then removed from the main kernel.

And, as explained above, this is not supposed to give synaptics touchpad service. The best we can hope for at the moment is to imitate an intellimouse device and avoid the worst of the horrible performance problems that the mysterious ALPS device is providing.
Comment 100 Sérgio M Basto 2011-08-11 02:43:55 UTC
(In reply to comment #99)
> Sear Sergio:
> 
> I don't mean to be too unkind, but please read at least a little bit of the
> thread before making silly comments.

yeah, I read "true features" and you write "no true features".

> If there is a newer patch, GIVE THE ADDRESS. 

Comment #87 mentions something new "ALPS has already delivered a beta release for RHEL6.0 driver that we are testing currently and will be posted for customers after that (...)"
I'm still waiting  

> I was amazed that the patch still applies cleanly to kernel-3.0.

don't be :)
Comment 101 Seth Forshee 2011-08-16 20:55:01 UTC
Hi Andrew,

Nice work on reverse-engineering the protocol. I just wish I had found all your results before I duplicated most of your work :) I came to different conclusions in a couple of places though, so I thought it would be worthwhile to mention these and see if we can resolve the differences. I'll use your a-f 0-7 naming scheme below.

For clarity, I'm calling the two types of touchpad packets position packets and bitmap packets. It should be pretty obvious which is which.

First off, in the trackstick packets I'm seeing the x and y coordinates as 8-bit signed values in 2's compliment format. Your notes have them as 7-bit values plus a sign bit. I've gone back and checked again, and I do think it's a 2's compliment signed value, as with this interpretation the values get more negative the farther you push the trackstick in the negative direction. Does your hardware behave differently than what I've observed?

In the touchpad position packets, you have bits a54 as low bits of the z coordinate. I had guessed them to be the low bits of the x coordinate, for two reasons. First, that makes the x position a 10-bit value like the y position. Second, when I move my finger down the touchpad slowly those bits seem to change roughly how you would expect them to if they were the low bits of the x position, although it's difficult to be certain because they're so jittery. What reasons did you have for concluding these were part of the z coordinate?

On my hardware (Dell Latitude E6520) the mouse buttons just below the keyboard are reported in d654 of the touchpad position packet. It seems you observed them in d210 of the trackstick packet. This is probably just a difference in our hardware, and both can be supported.

On the touchpad bitmap packets our observations were in complete agreement :)

One other point I'd like to inquire about is distinguishing between the types of packets. In my observation the last byte of the trackstick packets is always 0x3f, and I never see this value for the last byte of the other packet types. In fact the pressure values in the touchpad position packets seem to jump over any values near 0x3f completely, going from 0x13 or so to 0x50 or so without hitting any values in between. In my testing this has been the most reliable way to identify trackstick packets (I also verify that a6 is set as a sanity check). Do my observations hold on your hardware?

From there I identify bitmap packets as having to satisfy the following conditions: the packet follows a position packet with bit e6 set, and the packet has bit a6 set. I haven't found anything better, and it seems to be working reliably.

I'm hoping to get this all nailed down and have some patches to support the new protocol before long. Right now I have a badly hacked up driver, but it's mostly working.

Thanks,
Seth
Comment 102 Andrew Skalski 2011-08-16 22:07:58 UTC
(In reply to comment #101)
> First off, in the trackstick packets I'm seeing the x and y coordinates as
> 8-bit signed values in 2's compliment format. Your notes have them as 7-bit
> values plus a sign bit. I've gone back and checked again, and I do think it's a
> 2's compliment signed value, as with this interpretation the values get more
> negative the farther you push the trackstick in the negative direction. Does
> your hardware behave differently than what I've observed?

Hi Seth,

It's been about a year since I attempted to reverse-engineer the protocol, so my
memory is going to be a little fuzzy, but I'll do my best to compare notes.  The
bad news is I no longer have the Latitude E6510, so I can't run any more tests
on that variant of the touchpad hardware.  I'm currently using a Precision M4600,
however, and the "alps-decode.c" program is not decoding the trackstick correctly
anymore.  The trackstick button bits changed, and the x/y coordinates are no longer
decoding as a continous [-xmin,xmax] range centered on zero.  So, it's evident that
that my old Latitude E6510 had different hardware with a slightly different protocol.

> In the touchpad position packets, you have bits a54 as low bits of the z
> coordinate. I had guessed them to be the low bits of the x coordinate, for two
> reasons. First, that makes the x position a 10-bit value like the y position.
> Second, when I move my finger down the touchpad slowly those bits seem to
> change roughly how you would expect them to if they were the low bits of the x
> position, although it's difficult to be certain because they're so jittery.
> What reasons did you have for concluding these were part of the z coordinate?

In "struct pad" in alps-decode.c, the X and Y coordinates both already have 10-bit
values, so I'm a little confused about that point.  I had a hard time with the a54
bits as well, and for the same reason - there's too much jitter.  Interpreting them
as the low-bits of X gives me 12 bits, and puts the X and Y coordinates on different
scales.  Labeling a54 as "z_low" was part process-of-elimination, part experimentation,
part guesswork.

In my opinion, it wouldn't hurt simply to ignore those bits.  They don't seem to
add any (useful) precision to whatever coordinate they belong to.

> On my hardware (Dell Latitude E6520) the mouse buttons just below the keyboard
> are reported in d654 of the touchpad position packet. It seems you observed
> them in d210 of the trackstick packet. This is probably just a difference in
> our hardware, and both can be supported.

Yes, it seems to be a difference in hardware.

> On the touchpad bitmap packets our observations were in complete agreement :)
> 
> One other point I'd like to inquire about is distinguishing between the types
> of packets. In my observation the last byte of the trackstick packets is always
> 0x3f, and I never see this value for the last byte of the other packet types.
> In fact the pressure values in the touchpad position packets seem to jump over
> any values near 0x3f completely, going from 0x13 or so to 0x50 or so without
> hitting any values in between. In my testing this has been the most reliable
> way to identify trackstick packets (I also verify that a6 is set as a sanity
> check). Do my observations hold on your hardware?

I'd like to say yes, but I don't remember enough detail to say for certain whether
or not the E6510's Z coordinate had the same leap.

> From there I identify bitmap packets as having to satisfy the following
> conditions: the packet follows a position packet with bit e6 set, and the
> packet has bit a6 set. I haven't found anything better, and it seems to be
> working reliably.
> 
> I'm hoping to get this all nailed down and have some patches to support the new
> protocol before long. Right now I have a badly hacked up driver, but it's
> mostly working.
> 
> Thanks,
> Seth
Comment 103 Seth Forshee 2011-08-17 02:05:54 UTC
(In reply to comment #102)
> > In the touchpad position packets, you have bits a54 as low bits of the z
> > coordinate. I had guessed them to be the low bits of the x coordinate, for two
> > reasons. First, that makes the x position a 10-bit value like the y position.
> > Second, when I move my finger down the touchpad slowly those bits seem to
> > change roughly how you would expect them to if they were the low bits of the x
> > position, although it's difficult to be certain because they're so jittery.
> > What reasons did you have for concluding these were part of the z coordinate?
> 
> In "struct pad" in alps-decode.c, the X and Y coordinates both already have
> 10-bit
> values, so I'm a little confused about that point.  I had a hard time with the
> a54
> bits as well, and for the same reason - there's too much jitter.  Interpreting
> them
> as the low-bits of X gives me 12 bits, and puts the X and Y coordinates on
> different
> scales.  Labeling a54 as "z_low" was part process-of-elimination, part
> experimentation,
> part guesswork.

Okay, I overlooked one discrepancy in our decoding, and I mistyped something above. I have x and y at 11 bits each. I have e3210 as all belonging to y and only e54 as belonging to x. And this seems to hold in my observation -- in moving my finger slowly down the touchpad, here's a sample of what I get with the 11-bit values formed by combining c6543210 and e3210:

0c0
0c4
0c6
0c8
0c9
0ca
0cd
0ce
0d0

This sort of pattern continues as I move down the touchpad.
Comment 104 Paul Johnson 2011-08-30 14:58:48 UTC
I wonder if you can reproduce a system freeze when using the replacement psmouse patch to emulate the IntelliMouse (same patch as mentioned https://bugzilla.kernel.org/show_bug.cgi?id=14660#c97).  On my laptop, attempting

$ /sbin/rmmod psmouse

produces a complete system lockup. In my experience, a kernel panic causes a flashing caps lock light, and there is no flashing light. So I don't call what I see a kernel panic. The system just freezes, will not respond to keyboard or touchpad.

I was trying to remove that module because i have been having periodic "fail to suspend" problems after installing that driver. The problem is that the system seems to go into suspend, but then it wakes up immediately.  That doesn't happen when I use psmouse from the base kernel. 

I'm running Debian "wheezy" now, and the freeze happens with both kernel 3.0.0-1 amd64 and 2.6.39-3~bpo60+1
Comment 105 Seth Forshee 2011-09-01 20:42:11 UTC
Created attachment 71202 [details]
ALPS v3 protocol support version 1

I'm attaching an initial version of the patch I've been working on to support these touchpads. Note that the patch does not support all variations of these touchpads. I have an Acer Aspire One 532h that isn't working with it yet, and there may be others.

This is working well on two Dell machines I've tested with (Latitude E6520 and Latitude E6320), and I'd appreciate testing on more hardware. I've created a dkms package that should work at least on Ubuntu, which is available at:

http://people.canonical.com/~sforshee/alps-touchpad/psmouse-alps-0.1/psmouse-alps-dkms_0.1_all.deb

Thanks for testing!
Comment 106 Jonathan Protzenko 2011-09-01 20:51:54 UTC
Dell E6410.

[111049.130212] input: DualPoint Stick as /devices/platform/i8042/serio1/input/input20
[111049.143332] input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input21
[111059.685093] alps.c: Aborted multi-packet sequence, discarding
(message repeated many times)

jonathan@ramona:~ $ uname -a
Linux ramona 3.0.0-1-amd64 #1 SMP Sun Jul 24 02:24:44 UTC 2011 x86_64 GNU/Linux

- Vertical scrolling work just fine.
- Horizontal scrolling does not work.
- Two-finger scroll does not work either.
- Tap-to-click does not work.

Anything else I could do to make myself useful?
Comment 107 Jonathan Protzenko 2011-09-01 21:15:16 UTC
Oh wait, the other settings were disabled by default. Stupid Gnome. Everything works fine!
Comment 108 Avi Romanoff 2011-09-01 22:32:32 UTC
@Seth Forshee:

Thanks very much (and everyone else who has contributed) for taking the time to reverse-engineer the protocol and create the patch.

I'm patching my kernel as we speak, but as I'm not familiar with the kernel codebase I don't know what functionality I should (hopefully) expect to see with your patch. Can you provide a quick summary of the enhancements over the current "single-touch & tap-to-click" behavior for myself and other testers? I'm afraid I wouldn't know what to report back.

In any event, I'll report back how the patch goes with my Vostro 3550.
Comment 109 Paul Johnson 2011-09-02 02:01:19 UTC
Dear Seth (or anybody)

I used the psmouse-dkms package that Seth provided on my Debian system, Dell Precision M4600 laptop.  The psmouse module seems to build fine. The system seems to see the touchpad, but I can't use it. I mean, it clicking and cursor-moving don't do anything. And the touchpad buttons don't do anything. The pointer stick in the keyboard and does move the cursor, but the buttons (ones just below space bar) don't.

I can't tell if this happens because I'm configured incorrectly or because I have one of those ALPS devices that does not work yet.

In a terminal running "xev", there is no response when touching the touchpad, but keys and the pointer stick do have an effect.

After rebooting, in output from dmesg, I see


[    8.188170] input: DualPoint Stick as /devices/platform/i8042/serio1/input/input10
[    8.201063] input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input11

And the synclient -l agrees, it lists output! Yeah.

$ synclient -l
Parameter settings:
    LeftEdge                = 268
    RightEdge               = 1523
    TopEdge                 = 191
    BottomEdge              = 1088
    FingerLow               = 12
...

$ cat /proc/bus/input/devices

...

I: Bus=0011 Vendor=0002 Product=0008 Version=7326
N: Name="AlpsPS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input11
U: Uniq=
H: Handlers=mouse2 event11
B: PROP=8
B: EV=b
B: KEY=e420 70000 0 0 0 0
B: ABS=260800001000003


$ uname -a
Linux pjlap-124 2.6.39-bpo.2-amd64 #1 SMP Tue Jul 26 10:35:23 UTC 2011 x86_64 GNU/Linux
Comment 110 Paul Johnson 2011-09-02 02:28:31 UTC
Ach. Sorry to ask such a naive question. When Jonathan said "Stupid Gnome", I did not appreciate how stupid it is. And I am.

In case other users come along and have same "touchpad does not work" symptom with Seth's patch, here is a command that turns the touchpad on.

$ gconftool-2 --set --type boolean /desktop/gnome/peripherals/touchpad/touchpad_enabled true

Same can be changed in program "gconf-editor", I notice.

Without changing anything, I have cursor movement, right-side scroll. Double-click grabs the scroll bar "grabber" button.

In particular, these settings seem to work as expected.

$ synclient VertTwoFingerScroll=1
$ synclient TouchpadOff=1
$ synclient CircularScrolling=1


The most important thing for me is the "disable touchpad while typing".  That seems OK. I had been  having more and more trouble with that one with the Intellimouse emulation patch.

Thanks to Seth and Andrew and everybody else who has been trying to make this work. I admire the effort especially because I know for sure I could not do it!
Comment 111 moutzl 2011-09-02 09:40:18 UTC
Hello, I used package provided by Seth on Dell Latitude 6410 with Gentoo linux really idiot's way ( I just copy source to the kernel source and rebuild the kernel) after that touchpad and trackpoint working fine.
Vertical scroling is working, also horizontal is working. And most important for me:
synclient TouchpadOff=1  is turning off the touchpad! great, thank you guys!
if you will need futher testing/debugging let me know.



System uname: Linux-3.0.3-gentoo-x86_64-Intel-R-_Core-TM-_i3_CPU_M_380_@_2.53GHz-with-gentoo-2.0.3

I: Bus=0011 Vendor=0002 Product=0008 Version=7326
N: Name="AlpsPS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input16
U: Uniq=
H: Handlers=mouse1 event16 
B: PROP=8
B: EV=b
B: KEY=e420 70000 0 0 0 0
B: ABS=260800001000003

I: Bus=0011 Vendor=0002 Product=0008 Version=0000
N: Name="DualPoint Stick"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input15
U: Uniq=
H: Handlers=mouse0 event15 
B: PROP=0
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=3
Comment 112 Paul Gideon Dann 2011-09-02 09:56:49 UTC
Nice work!  The mouse works well for me with this patch (on a Dell Latitude E5520).  However, the sensitivity is significantly higher than with the generic PS/2 mouse driver.
Comment 113 Felix Schuster 2011-09-02 10:19:42 UTC
(In reply to comment #112)
> Nice work!  The mouse works well for me with this patch (on a Dell Latitude
> E5520).  However, the sensitivity is significantly higher than with the generic
> PS/2 mouse driver.

Same here on a Dell Precision M4500 running Gentoo Linux:

I: Bus=0011 Vendor=0002 Product=0008 Version=7326
N: Name="AlpsPS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse1 event5 
B: PROP=8
B: EV=b
B: KEY=e420 70000 0 0 0 0
B: ABS=260800001000003

2.6.39-gentoo-r3 #3 SMP Fri Sep 2 11:53:53 CEST 2011 x86_64 Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz GenuineIntel GNU/Linux
Comment 114 George Panta 2011-09-02 11:31:58 UTC
Hello Seth and thank you for your work on this.

Unfortunately the driver does not work for me on a Sony Vaio VPCF11M1E, ALPS mode is not activated and it reverts to IM/PS2 mode. Here is dmesg snip:

dmesg |  grep -i alps
[   11.292271] alps.c: v3 touchpad failed to enter command mode

I would be happy to provide you any more info. Thanks!
Comment 115 Francisco Cribari 2011-09-02 11:38:26 UTC
Seth's patch works for me. I now have a touchpad tab in the mouse preferences panel and

cribari@darwin:~$ dmesg |  grep -i alps
[    5.326131] alps.c: E6 report: 00 00 64
[    5.348321] alps.c: E7 report: 73 02 64
[    5.386957] alps.c: E6 report: 00 00 64
[    5.407704] alps.c: E7 report: 73 02 64
[    5.623105] alps.c: trackstick E7 report: 42 02 14
[    6.049341] input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input9

My hardware: DELL 6510 Intel GPU. I am running Ubuntu Linux 11.04 64 bit. My kernel:

cribari@darwin:~$ uname -a
Linux darwin 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

The only drawback so far is that the touchpad mouse is a bit too sensitive.
Comment 116 Weng Xuetian 2011-09-02 11:50:09 UTC
Hello Seth, patch not works here, this is what I get.
$ dmesg | grep -Ri alps
[    3.972008] alps.c: trackstic E7 report failed
[   12.042474] input: PS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input13

I: Bus=0011 Vendor=0002 Product=0001 Version=7326
N: Name="PS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input13
U: Uniq=
H: Handlers=mouse1 event13 
B: PROP=0
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=3

uname -a
Linux saber-chakra 3.0-ck #1 SMP PREEMPT Fri Sep 2 18:58:39 CST 2011 x86_64 AMD Phenom(tm) II P820 Triple-Core Processor AuthenticAMD GNU/Linux

Actually I have try to use this patch before (and add my laptop to quirk table by hand, since it's not Dell but a Gateway one.), and touchpad work with vertical scroll feature, so I think they might be the similar device.
https://patchwork.kernel.org/patch/350841/
Comment 117 David De Sousa 2011-09-02 16:51:47 UTC
I can confirm Seth's patch is working on my Dell Latitude E6520

I: Bus=0011 Vendor=0002 Product=0008 Version=7326
N: Name="AlpsPS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input2
U: Uniq=
H: Handlers=mouse1 event2 
B: PROP=8
B: EV=b
B: KEY=e420 70000 0 0 0 0
B: ABS=260800001000003

Linux morgoth 3.1.0-rc4+ #2 SMP Fri Sep 2 09:53:12 VET 2011 x86_64 Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz GenuineIntel GNU/Linux

However, I'm making several click mistakes because the pointer moves when I'm going to click, I guess it's oversensitive like #115 is reporting, any way to fix this?


Great work, Seth and all the other people involved, open source rocks
Comment 118 David Tomaschik 2011-09-02 16:57:50 UTC
The package works for me on a Latitude E5420.  I agree with the above posters that the touchpad is definitely more sensitive now.  I also feel (subjectively) that the vertical scroll area on the right of the touchpad is substantially wider.  gpointing-device-settings doesn't seem to have any effect on the touchpad, even though it shows it.  I also haven't been able to find the right synclient bits to manipulate these settings.

Thanks for the great work!
Comment 119 Andrew Skalski 2011-09-02 17:23:01 UTC
(In reply to comment #118)
> The package works for me on a Latitude E5420.  I agree with the above posters
> that the touchpad is definitely more sensitive now.  I also feel (subjectively)
> that the vertical scroll area on the right of the touchpad is substantially
> wider.  gpointing-device-settings doesn't seem to have any effect on the
> touchpad, even though it shows it.  I also haven't been able to find the right
> synclient bits to manipulate these settings.
> 
> Thanks for the great work!

I've also noticed that my vertical scroll area is wider.  The X/Y resolution of my touchpad (Precision M4600) is larger than the constants that are currently set in the module - there are evidently several touchpad models with different resolutions, so the driver just needs a way to detect/compensate for that.
Comment 120 juliusvonkohout 2011-09-03 09:59:26 UTC
Created attachment 71512 [details]
dmesg

toshiba satellite r850-14t
Linux SATELLITE 3.0.4-030004-generic #201108301138 SMP Tue Aug 30 11:42:30 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

kernel error and then:

[   22.881093] alps.c: E6 report: 00 00 64
[   22.898271] alps.c: E7 report: 73 02 64
[   22.934167] alps.c: E6 report: 00 00 64
[   22.952304] alps.c: E7 report: 73 02 64
[   22.955263] usb 2-1.6: new full speed USB device number 4 using ehci_hcd
[   23.039256] alps.c: trackstic E7 report failed
[   23.304999] e1000e 0000:00:19.0: irq 40 for MSI/MSI-X
[   23.364864] e1000e 0000:00:19.0: irq 40 for MSI/MSI-X
[   23.365206] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   23.488875] input: PS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input8
[   23.513623] psmouse.c: Failed to enable mouse on isa0060/serio1

tested with 2.6.38-11 3.0.4 and 3.1 rc4
Comment 121 juliusvonkohout 2011-09-03 10:02:00 UTC
btw the laptop does not have a "trackstick"
it brakes bluetooth and wifi.
Comment 122 tlinsky 2011-09-04 19:59:57 UTC
(In reply to comment #105)
Thanks very much for your work in reverse engineering this protocol! The dkms deb module in comment 105 did not work on my HP dm1z-2100. The cursor does not move at all. Please let me know if there is anything at all more I can do to help.

$ uname -a
Linux ufo4 3.0.0-10-generic #16-Ubuntu SMP Fri Sep 2 18:32:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

$ cat /proc/bus/input/devices
I: Bus=0011 Vendor=0002 Product=0005 Version=7326
N: Name="ImPS/2 ALPS GlidePoint"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input11
U: Uniq=
H: Handlers=mouse0 event11 
B: PROP=0
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=103

$ dmesg | grep -i 'psmouse\|alps'
[    8.108746] alps.c: E6 report: 00 00 64
[    8.152879] alps.c: E7 report: 73 02 64
[    8.241312] alps.c: E6 report: 00 00 64
[    8.284751] alps.c: E7 report: 73 02 64
[    8.630144] alps.c: trackstic E7 report failed
[   17.570530] input: PS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input8
[   17.629108] psmouse.c: Failed to enable mouse on isa0060/serio1
Comment 123 Seth Forshee 2011-09-05 17:00:47 UTC
Thanks to everyone who has tested the patch! One note -- when you include the dmesg output please don't just grep for alps, as some of the messages of interest don't contain that string.

A few of things are becoming clear. First, there are at least a couple of different versions of the touchpads that reply to the E7 report with 73 02 64. The patch will work to varying degrees with some of them and won't work at all with the others. I've an Acer netbook that falls into the latter category, and I'll be working to find out what needs to be done with these.

Second, the patch is probably failing for any machines without a trackstick. This should be fairly easy to fix.

Third, not all of these touchpads have the same resolution. This accounts for at least part of the sensitivity problems being seen (with the touchpads, not with the tracksticks).

I've written a quick-and-dirty program to dump the full register space from these devices. I'd appreciate if you could all run it on your machines, capture the output, and email it to me (seth dot forshee at canonical dot com). Please also include the model of your machine and the maximum ABS_X and ABS_Y values reported by your machine (a description of how to determine these is below). N.B.: this program may leave your touchpad in a non-functional state, especially if its execution is interrupted. If this happens you can try running:

  echo -n "psmouse" | sudo tee /sys/bus/serio/devices/serio<n>/drvctl

Using the sysfs path printed in the "Found serio mouse at" message at the top of the output. If that doesn't work you should reboot. Also note that this will take quite a while to run.

A executable is available at:

  http://people.canonical.com/~sforshee/alps-touchpad/alps-reg-dump/alps-reg-dump

And the source is available at:

  http://kernel.ubuntu.com/git?p=sforshee/alps-reg-dump.git;a=summary

To capture the maximum ABS_X and ABS_Y values from the touchpad, you must be using my driver changes. Run "sudo lsinput" and identify the input device named "AlpsPS/2 ALPS DualPoint TouchPad", then run "sudo input-events <n> | grep 'ABS_[XY]'", where <n> is the input device number. While this is running, touch on the lower-right corner of the touchpad, and tell me the maximum values you see reported.

Thanks everyone!
Comment 124 George Panta 2011-09-05 22:25:06 UTC
Hello Seth Forsee and thanks for your work on this. 

I've left your program for a couple of hours now and also redirected stder to the logfile. 
It has generated about 4000 lines and apart from the first lines every other line says failed and in between some of them there are stderr lines "error reading command response".

Is that helpful and should I let it run overnight until the program exits/finishes?
Comment 125 Paul Gideon Dann 2011-09-06 08:42:16 UTC
I've spent a good ten minutes looking, but I can't find any equivalent to the input-events package for ArchLinux, without which I don't have lsinput or input-events.  I also haven't had any luck finding an upstream project or repository.  What's the best way to get hold of the source for those tools?
Comment 126 juliusvonkohout 2011-09-06 12:12:33 UTC
Created attachment 71752 [details]
registerdump

system and dmesg from post 120 and 121.
Comment 127 skrobul+kernelbug 2011-09-06 14:35:23 UTC
@Paul Gideon Dann:  In ArchLinux you can install input-utils from AUR repository:
https://aur.archlinux.org/packages.php?ID=52213
Comment 128 Paul Gideon Dann 2011-09-06 14:49:46 UTC
@skrobul => Thanks for finding the source and creating the AUR package :)

I've run lsinput, found the device number, and run input-events with that number.  However, I get no events at all from the device, even though the cursor goes whizzing off around the screen.  If I do the same thing with the standard psmouse driver, I get plenty of events.  I also get plenty of events from the track stick when the new driver is loaded.
Comment 129 Seth Forshee 2011-09-06 16:24:51 UTC
(In reply to comment #124)
> Hello Seth Forsee and thanks for your work on this. 
> 
> I've left your program for a couple of hours now and also redirected stder to
> the logfile. 
> It has generated about 4000 lines and apart from the first lines every other
> line says failed and in between some of them there are stderr lines "error
> reading command response".
> 
> Is that helpful and should I let it run overnight until the program
> exits/finishes?

Sorry, I sent a reply yesterday but the email bounced.

If you start getting failures like this you probably don't need to let it run to completion. Just stop the program and send what output you did capture.
Comment 130 Seth Forshee 2011-09-06 16:30:08 UTC
(In reply to comment #125)
> I've spent a good ten minutes looking, but I can't find any equivalent to the
> input-events package for ArchLinux, without which I don't have lsinput or
> input-events.  I also haven't had any luck finding an upstream project or
> repository.  What's the best way to get hold of the source for those tools?

Try here.

http://www.kraxel.org/cgit/input/
Comment 131 CJ 2011-09-07 23:04:04 UTC
Seth,

I just tried your patch on 3.1.0-rc2 kernel with my Dell E6420 (fedora 14). The trackpad is still working when I am at the gnome login window, once I login it stops working. If I switch to pseudo console, the trackpad is working there fine but not when I switch back to X server.

I: Bus=0011 Vendor=0002 Product=0008 Version=7326
N: Name="AlpsPS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input19
U: Uniq=
H: Handlers=mouse1 event6 
B: PROP=8
B: EV=b
B: KEY=e420 70000 0 0 0 0 
B: ABS=260800001000003

ABS_XY value by "sudo input-events 6 | grep 'ABS_[XY]'"

16:02:02.572034: EV_ABS ABS_MT_POSITION_X 1791
16:02:02.572036: EV_ABS ABS_MT_POSITION_Y 1268
16:02:02.572042: EV_ABS ABS_X 1791
16:02:02.572044: EV_ABS ABS_Y 1268

> sudo ./bin/alps-reg-dump 
Found serio mouse at /sys/bus/serio/devices/serio1/
Error writing to /sys/bus/serio/devices/serio1/drvctl
Error: Could not locate serio mouse

Thanks,
CJ
Comment 132 Seth Forshee 2011-09-07 23:10:57 UTC
(In reply to comment #131)
> I just tried your patch on 3.1.0-rc2 kernel with my Dell E6420 (fedora 14). The
> trackpad is still working when I am at the gnome login window, once I login it
> stops working. If I switch to pseudo console, the trackpad is working there
> fine but not when I switch back to X server.

I'm not sure why this would be happening.

> > sudo ./bin/alps-reg-dump 
> Found serio mouse at /sys/bus/serio/devices/serio1/
> Error writing to /sys/bus/serio/devices/serio1/drvctl
> Error: Could not locate serio mouse

When this happens, you probably need to run 'modprobe serio_raw' as root and try again.
Comment 133 CJ 2011-09-08 00:07:51 UTC
Created attachment 71972 [details]
Register dump on Dell E6420 on Fedora 14 (kernel 3.1.0-rc2)
Comment 134 CJ 2011-09-08 00:12:16 UTC
(In reply to comment #132)
> (In reply to comment #131)
> > I just tried your patch on 3.1.0-rc2 kernel with my Dell E6420 (fedora 14). The
> > trackpad is still working when I am at the gnome login window, once I login it
> > stops working. If I switch to pseudo console, the trackpad is working there
> > fine but not when I switch back to X server.
> 
> I'm not sure why this would be happening.

Is there anything you want to check to help debugging this? Anybody has tried Fedora 14 before? On this system, I at least can get vscoll work with an older patch at https://patchwork.kernel.org/patch/350841.

> 
> > > sudo ./bin/alps-reg-dump 
> > Found serio mouse at /sys/bus/serio/devices/serio1/
> > Error writing to /sys/bus/serio/devices/serio1/drvctl
> > Error: Could not locate serio mouse
> 
> When this happens, you probably need to run 'modprobe serio_raw' as root and
> try again.

Please see the register dump at https://bugzilla.kernel.org/attachment.cgi?id=71972

Thanks,
CJ
Comment 135 Daniel Hillier 2011-09-08 15:27:33 UTC
Created attachment 72052 [details]
Register dump on Dell N5110 on Fedora 15 (kernel 2.6.40.3)
Comment 136 Sérgio M Basto 2012-01-20 02:20:57 UTC
huau ! bugzilla is back 

for who don't yet know 
http://people.canonical.com/~sforshee/alps-touchpad/psmouse-alps-0.10/
was merged on linux-next (by input team I guess),
and backported on Fedora kernels so last kernel on updates of F-15 and F-16 got the ALPS working and detect with synclient :

works very well specially after: 
synclient VertTwoFingerScroll=1
synclient HorizTwoFingerScroll=1
synclient VertEdgeScroll=1
synclient HorizEdgeScroll=1
synclient -l | grep -i scroll


synclient TapButton1=1
synclient TapButton2=1
synclient TapButton3=1
synclient -l | grep -i tap


Thank you Seth Forshee
Comment 137 George Panta 2012-01-21 15:48:14 UTC
Hello,

The improvements are great and it is great that they are upstreamed.

Is there any chance to add semi-mt multitouch support for v4 ALPS touchpads?
Luckily Seth Forshee has already documented the packet format for these devices.

Thanks
Comment 138 Arnout Engelen 2012-01-22 09:28:43 UTC
So the improvements should be in any kernel from 3.3 onwards?
Comment 139 James M. Leddy 2012-01-27 00:21:15 UTC
(In reply to comment #136)
> huau ! bugzilla is back 
> 
> for who don't yet know 
> http://people.canonical.com/~sforshee/alps-touchpad/psmouse-alps-0.10/
> was merged on linux-next (by input team I guess),
> and backported on Fedora kernels so last kernel on updates of F-15 and F-16 got
> the ALPS working and detect with synclient :
> 
> works very well specially after: 
> synclient VertTwoFingerScroll=1
> synclient HorizTwoFingerScroll=1
> synclient VertEdgeScroll=1
> synclient HorizEdgeScroll=1
> synclient -l | grep -i scroll

This is great news! Can someone who has one of these devices and the stuff in linux-next try an 'xinput list-props' of the device (probably "AlpsPS/2 ALPS GlidePoint") and report the output? I ask this because of this gem in gnome-settings-daemon (gsd-input-helper.c):

gboolean
device_is_touchpad (XDevice *xdevice)
{
<snip>
        /* we don't check on the type being XI_TOUCHPAD here,
         * but having a "Synaptics Off" property should be enough */

        prop = XInternAtom (GDK_DISPLAY_XDISPLAY (gdk_display_get_default ()), "Synaptics Off", False);
        if (!prop)
                return FALSE;

<snip>
}
Comment 140 James M. Leddy 2012-01-27 00:45:19 UTC
(In reply to comment #136)
> huau ! bugzilla is back 
> 
> for who don't yet know 
> http://people.canonical.com/~sforshee/alps-touchpad/psmouse-alps-0.10/
> was merged on linux-next (by input team I guess),

Small note, this looks like it's already fixed and released in 3.2 

commit 25bded7cd60fa460e520e9f819bd06f4c5cb53f0
Author: Seth Forshee <seth.forshee@canonical.com>
Date:   Mon Nov 7 19:53:36 2011 -0800

    Input: ALPS - add support for protocol versions 3 and 4
    
    This patch adds support for two ALPS touchpad protocols not
    supported currently by the driver, which I am arbitrarily naming
    version 3 and version 4. Support is single-touch only at this time,
    although both protocols are capable of limited multitouch support.
    
    Thanks to Andrew Skalski, who did the initial reverse-engineering
    of the v3 protocol.
    
    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Acked-by: Chase Douglas <chase.douglas@canonical.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Comment 141 Seth Forshee 2012-01-27 03:13:43 UTC
(In reply to comment #140)
> (In reply to comment #136)
> > huau ! bugzilla is back 
> > 
> > for who don't yet know 
> > http://people.canonical.com/~sforshee/alps-touchpad/psmouse-alps-0.10/
> > was merged on linux-next (by input team I guess),
> 
> Small note, this looks like it's already fixed and released in 3.2 
> 
> commit 25bded7cd60fa460e520e9f819bd06f4c5cb53f0
> Author: Seth Forshee <seth.forshee@canonical.com>
> Date:   Mon Nov 7 19:53:36 2011 -0800

3.3-rc1 actually.

$ git describe --contains 25bded
v3.3-rc1~83^2~5^2~51
Comment 142 Paul Gideon Dann 2012-01-27 14:52:34 UTC
I get the following output from xinput list-props: http://pastebin.com/r8KFVeUL
Comment 143 James M. Leddy 2012-01-27 15:02:48 UTC
(In reply to comment #142)
> I get the following output from xinput list-props: http://pastebin.com/r8KFVeUL

Awesome, that means it'll g-s-d will work properly. I've also confirmed this with the g-s-d devs.
Comment 144 Dmitry Torokhov 2012-02-06 17:41:26 UTC
*** Bug 28152 has been marked as a duplicate of this bug. ***
Comment 145 Mohammad Razeghi 2012-02-06 21:44:22 UTC
Created attachment 72307 [details]
dmesg output on VAIO F111FX . Linux 3.2.4-1-ARCH

i have the same problem on VAIO F111Fx . this is also "xinput list" command output :

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ ImPS/2 Generic Wheel Mouse              	id=11	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Sony Vaio Keys                          	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ UVC Camera (064e:2100)                  	id=9	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=10	[slave  keyboard (3)]
Comment 146 Francisco Cribari 2012-02-08 16:22:12 UTC
When upgrading to kernel 3.2.0-15 (Linux Mint 12, 64 bit) I got:

Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.2.0-15-generic /boot/vmlinuz-3.2.0-15-generic
Error! Bad return status for module build on kernel: 3.2.0-15-generic (x86_64)
Consult /var/lib/dkms/psmouse-alps/0.10/build/make.log for more information.
Error! Bad return status for module build on kernel: 3.2.0-15-generic (x86_64)
Consult /var/lib/dkms/virtualbox-guest/4.1.2/build/make.log for more information.

The contents of /var/lib/dkms/psmouse-alps/0.10/build/make.log:

cribari@darwin ~ $ cat /var/lib/dkms/psmouse-alps/0.10/build/make.log
DKMS make.log for psmouse-alps-0.10 for kernel 3.2.0-15-generic (x86_64)
Wed Feb  8 13:17:51 BRT 2012
make: Entering directory `/usr/src/linux-headers-3.2.0-15-generic'
  LD      /var/lib/dkms/psmouse-alps/0.10/build/src/built-in.o
  CC [M]  /var/lib/dkms/psmouse-alps/0.10/build/src/psmouse-base.o
  CC [M]  /var/lib/dkms/psmouse-alps/0.10/build/src/synaptics.o
  CC [M]  /var/lib/dkms/psmouse-alps/0.10/build/src/alps.o
/var/lib/dkms/psmouse-alps/0.10/build/src/alps.c:135:33: error: expected ‘)’ before ‘int’
make[2]: *** [/var/lib/dkms/psmouse-alps/0.10/build/src/alps.o] Error 1
make[1]: *** [/var/lib/dkms/psmouse-alps/0.10/build/src] Error 2
make: *** [_module_/var/lib/dkms/psmouse-alps/0.10/build] Error 2
make: Leaving directory `/usr/src/linux-headers-3.2.0-15-generic'
Comment 147 Dmitry Torokhov 2012-02-08 17:05:22 UTC
(In reply to comment #146)
> When upgrading to kernel 3.2.0-15 (Linux Mint 12, 64 bit) I got:
...

This should be reported to Mint developers please.
Comment 148 Colton Jenkins 2012-02-10 02:14:38 UTC
I also have this issue after switching from Ubuntu 11.04 to 

Linux nemesis 3.2.5-1-ARCH #1 SMP PREEMPT Tue Feb 7 08:34:36 CET 2012 x86_64 Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz GenuineIntel GNU/Linux

xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ PS/2 Generic Mouse                      	id=12	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ Laptop_Integrated_Webcam_FHD            	id=10	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=11	[slave  keyboard (3)]
    ↳ Dell WMI hotkeys                        	id=13	[slave  keyboard (3)]

Dell Latitude e5520

Is there any way I can help in resolving this issue? Whether its testing or a c file I should look over.
Comment 149 Sérgio M Basto 2012-02-10 03:50:05 UTC
you have PS/2 Generic Mouse                          id=12    [slave  pointer 
so your kernel is not >= 3.3-rc1 nor got the alps patch . 
after that you will have: 
AlpsPS/2 ALPS DualPoint TouchPad          id=13   [slave  pointer  (2)]
Comment 150 Colton Jenkins 2012-02-12 21:14:56 UTC
Thanks! Downloaded and installed 3.3.0-rc3 and I have scrolling!
Comment 151 mkz 2012-03-12 19:52:05 UTC
The latest Kernel 3.3.0-rc7 from the Ubuntu Kernel ppa resolved most of the problems on my Dell Latitude E6410. But if the power supply is connected to my laptop, the behavior of the touchpad (not the trackpad) changes drastically: Sometimes, the cursor jumps around, often it stops moving with no reason and if tapping is enabled, it quite often generates mouse click events… Any ideas?

 xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ DualPoint Stick                         	id=12	[slave  pointer  (2)]
⎜   ↳ AlpsPS/2 ALPS DualPoint TouchPad        	id=13	[slave  pointer  (2)]
Comment 152 Sérgio M Basto 2012-03-14 04:04:55 UTC
(In reply to comment #151)
> The latest Kernel 3.3.0-rc7 from the Ubuntu Kernel ppa resolved most of the
> problems on my Dell Latitude E6410. But if the power supply is connected to my
> laptop, the behavior of the touchpad (not the trackpad) 

http://en.wikipedia.org/wiki/Touchpad
A touchpad (or trackpad) is a ... 
are you talking about point stick ?  

> changes drastically:
> Sometimes, the cursor jumps around, often it stops moving with no reason and if
> tapping is enabled, it quite often generates mouse click events… 

I also got Dell Latitude E6410, I use Fedora and don't saw any cursor jump, neither change behaviour with power supply connected or disconnected .
and I had use it for a long time .



> Any ideas?
no 
Seems water in keyboard ... 
have you bios updated ? normally bios update doesn't change nothing, but we never know.

dmidecode | grep "BIOS Infor" -A4
BIOS Information
        Vendor: Dell Inc.
        Version: A11
        Release Date: 11/30/2011
        Address: 0xF0000
Comment 153 George Panta 2012-04-09 14:40:16 UTC
Created attachment 72861 [details]
ALPS v4 Semi-Multitouch (buggy)

Hello everyone,

I have made a patch that adds semi-mt support to v4 Alps touchpads.
Unfortunately it is quite buggy.

On my Vaio the Left Half of the Touchpad is quite erratic (synclient -m 10 shows f alternating constantly between 1 and 2 fingers with one finger touching it).

The right Half of the Touchpad (i.e. if x>1000 in synclient -m x) works as intended (two finger scrolling/taps and three fingers are recognized).

I have used the Documentation from Seth Forshee and essentially copied his work.

I would really appreciate it if someone could finalize the patch.
I hope Seth could revisit this :)

P.S. I am not a programmer (I guess programmers will understand this) :)
Comment 154 Seth Forshee 2012-04-09 15:31:54 UTC
I think this bug should be closed, since the problem originally reported is fixed. ALPS v4 semi-MT support is related but still a separate issue.
Comment 155 Dmitry Torokhov 2012-04-09 19:58:48 UTC
Let's do it.

George, could you please open a new bug (or maybe even post a patch to linux-input@vger.kernel.org)?

Note You need to log in before you can comment on or make changes to this bug.