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.
Created attachment 23858 [details] output of cat /proc/bus/input/devices
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.
*** Bug 15359 has been marked as a duplicate of this bug. ***
*** Bug 15933 has been marked as a duplicate of this bug. ***
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.
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).
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).
*** Bug 16146 has been marked as a duplicate of this bug. ***
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.
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.
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).
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
I have a Dell Latitude E6510 and also have this ALPS touchpad and same issues. I can also test fixes if there are any.
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.
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
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.
Would remote access be sufficient? I'd be willing to make an HP 311 available via SSH.
Or is there code to run or a procedure to carry out that a volunteer could try?
I'm also willing to test patches.
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?
Very nice, thank you for doing this.
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.
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.
Created attachment 27411 [details] Swipe event data, 6 bytes per line, binary
Created attachment 27412 [details] Swipe event data, parsed as 'absolute Mode - new format'
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
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.)
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.
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 suppose his patch enables the '4-byte "Intellimouse Mode"', while the windows driver above triggers and uses another (6-byte) protocol.
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.
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.
(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)
(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 !
*** Bug 18682 has been marked as a duplicate of this bug. ***
(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.
Created attachment 30372 [details] Dmesg from acer aspire timeline 3820t with patch #32 (does not recognized touchpad)
Created attachment 30482 [details] Modified output of dmesg with patch on aspire 3820t
Created attachment 30492 [details] And another dmesg from aspire 3830t with patched module
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.
*** Bug 16681 has been marked as a duplicate of this bug. ***
How can I assist with my "eMachines D440"? It has similar touchpad...
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
Created attachment 31692 [details] dmesg with patched module running (desynchronized)
Any news?
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
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.
(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 ...
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?
from https://bugzilla.redhat.com/show_bug.cgi?id=590880 https://patchwork.kernel.org/patch/350841/
(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.
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
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).
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(
I patched 2.6.37 too with comment #50 and it works, but still it's not recognized as a synaptics touchpad
(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
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.
(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 ?
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.
VaKo, can you post Windows Driver init sequence?
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)
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 ~]$
(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.
You are right, my system won't shutdown automatically anymore. Anyway, I prefer scrolling :).
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?
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
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.
(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.
(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.
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.
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.
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.
(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
Same question as moutzi in comment #71. =:/
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 #73 here, vertical scrolling now works but rmmod and system shutdown hang when psmouse is removed.
(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.
for when a drive that recognized as a synaptics touchpad ? this is dual-touch isn't it ?
Ok, someone know about some development? Or I have to open case and cut the wires to the touchpad?
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 :)
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.
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?
I have a Dell Latitude E5520 with this issue; also happy to help in any way I can.
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.
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!
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
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.
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.
At all, good news.Thanks for info
Can anyone post a link to these 'cloused' drivers?
(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
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...
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
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.
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
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
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$
(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.
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.
(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 :)
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
(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
(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.
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
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!
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?
Oh wait, the other settings were disabled by default. Stupid Gnome. Everything works fine!
@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.
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
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!
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
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.
(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
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!
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.
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/
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
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!
(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.
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
btw the laptop does not have a "trackstick" it brakes bluetooth and wifi.
(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
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!
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?
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?
Created attachment 71752 [details] registerdump system and dmesg from post 120 and 121.
@Paul Gideon Dann: In ArchLinux you can install input-utils from AUR repository: https://aur.archlinux.org/packages.php?ID=52213
@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.
(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.
(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/
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
(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.
Created attachment 71972 [details] Register dump on Dell E6420 on Fedora 14 (kernel 3.1.0-rc2)
(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
Created attachment 72052 [details] Register dump on Dell N5110 on Fedora 15 (kernel 2.6.40.3)
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
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
So the improvements should be in any kernel from 3.3 onwards?
(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> }
(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>
(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
I get the following output from xinput list-props: http://pastebin.com/r8KFVeUL
(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.
*** Bug 28152 has been marked as a duplicate of this bug. ***
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)]
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'
(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.
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.
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)]
Thanks! Downloaded and installed 3.3.0-rc3 and I have scrolling!
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)]
(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
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) :)
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.
Let's do it. George, could you please open a new bug (or maybe even post a patch to linux-input@vger.kernel.org)?