My Thinkpad R61 has an ALPS pad and a trackpointer (UltraNav). The devices only get detected as generic PS/2 mouse though. I enabled the DEBUG mode of the "alps.c" driver and attached the info below. The trackpointer also remains undetected. "trackpoint.c" has no debug mode, so i can't really attach usefull infos. Also, the content in "/sys/devices/platform/i8042/" doesn't seem to have any of the special info which are described on: http://www.thinkwiki.org/wiki/Patch_to_enable_advanced_trackpoint_configuration I'm using 2.6.22.1 and also tried a 2.6.19 Gentoo LiveCD to be sure it's not a new behaviour. I also attached the whole dmesg becuase serio/i8042 could prevent something from showing up maybe. Thanks Christian Birchinger Model: ------ Thinkpad R61 8918-5QG /proc/bus/input/devices: ------------------------ I: Bus=0011 Vendor=0002 Product=0001 Version=0000 N: Name="PS/2 Generic Mouse" P: Phys=isa0060/serio1/input0 S: Sysfs=/class/input/input5 U: Uniq= H: Handlers=mouse0 event5 B: EV=7 B: KEY=70000 0 0 0 0 B: REL=3 alps.c (#define DEBUG) kernel log (triggered by modprobe psmouse): ------------------------------------------------------------------ alps.c: E6 report: 00 00 64 alps.c: E7 report: 73 00 0a input: PS/2 Generic Mouse as /class/input/input10 ls -R /sys/devices/platform/i8042/: ----------------------------------- /sys/devices/platform/i8042/: driver@ modalias power/ serio0/ serio1/ subsystem@ uevent /sys/devices/platform/i8042/power: wakeup /sys/devices/platform/i8042/serio0: bind_mode driver@ err_count id/ power/ set softrepeat uevent description drvctl extra modalias scroll softraw subsystem@ /sys/devices/platform/i8042/serio0/id: extra id proto type /sys/devices/platform/i8042/serio0/power: wakeup /sys/devices/platform/i8042/serio1: bind_mode driver@ id/ power/ rate resolution subsystem@ description drvctl modalias protocol resetafter resync_time uevent /sys/devices/platform/i8042/serio1/id: extra id proto type /sys/devices/platform/i8042/serio1/power: wakeup cat /sys/devices/platform/i8042/*/description: ---------------------------------------------- i8042 KBD port i8042 AUX port
Created attachment 12324 [details] Full dmesg output I've attached the full dmesg log
Hmm, "73 00 0a" is not in the list of known responses for ALPS. Do you have the other OS installed on this box? If so is the touchpad identified as ALPS there?
Yes, i know that because i first wrongly assumed it's a Synaptics pad and installed the driver for it which failed. I tested it with the original "other OS" installation which came with the device. I found similar reports of other users, they all seem to have the NVidia version of the R61. Like most, i wouldn't have dreamed that it's not a Synaptics.
Created attachment 12899 [details] Add TP R61 ALPS signature Ok, lets start with this patch and see where it leads us. If it dies not work try removing ALPS_PASS from the TP R61 entry. Thanks!
ALPS_PASS fails, the behaviour is the following. Pad is usable but acts like mouse emulation. The Xorg Synaptics driver finds a Device but uses the eventX device of the Generic PS/2 mouse then instead of the one for ALPS. No special Pad behaviour is configurable. When cat-ing the PS/2 generic eventX device theres data on the console but when cat-ing the ALPS eventX device theres nothing. So i assume it's running in emu mode. Trackpointer is complettly inactive though. 0 instead of ALPS_PASS makes the pad fully working. Xorg driver finds the right eventX device. And the features work like defining wheel scroll area and mouse speed etc. So this is a full success! However there's some regression. The trackpointer is not fully inactive this time but just jumps around in a rectancle area. Wild guess is that it interprets the info from the trackpointer as ALPS pad events too. The /proc/bus/input/devices doesen't show the trackpointer at all. It shows ALPS and Generic PS/2. Well since the ALPS has a totaly new ID the trackpointer maybe has too. As i said before, the trackpointer driver has no debug define, so some patch to dump usefull information would help. Thanks alot so far.
Ok, this is good. Could you please do the following: 1. echo 1 > /sys/modules/i8042/parameters/debug 2. push trackpoint to the left for a second 3. echo 0 > /sys/modules/i8042/parameters/debug 4. dmesg > dmesd.tp.left repeat the same for right, up, down, buttons and the touchpad without trackpoint and send me all dmesg.* files - this should allow me to see how to extract trackpoint data from the touchpad. Thank you.
Created attachment 12927 [details] Trackpointer pressed UP debug info
Created attachment 12928 [details] Trackpointer pressed DOWN debug info
Created attachment 12929 [details] Trackpointer pressed LEFT debug info
Created attachment 12930 [details] Trackpointer pressed RIGHT debug info
Ok, i hope the datas are usable. I've used dmesg -c to clear the previous data, between each run. You'll probably see the "Return" keys i've pressed to switch debug 1 and 0.
Argh, sorry i've got it all in emu mode will reupload the the data with the other module loaded.
Created attachment 12931 [details] Trackpointer pressed UP debug info
Created attachment 12932 [details] Trackpointer pressed DOWN debug info
Created attachment 12933 [details] Trackpointer pressed LEFT debug info
Created attachment 12934 [details] Trackpointer pressed RIGHT debug info
Created attachment 13068 [details] Add TP R61 ALPS signature as DualPoint Argh, I saw that you send bad debug data and completely missed that you also sent good debug data... Anyway, I believe that our dulapoint code should handle your touchpad just fine. Please let me know if this works. Thanks!
Works fine now: /proc/bus/input/devices: I: Bus=0011 Vendor=0002 Product=0008 Version=0000 N: Name="DualPoint Stick" P: Phys=isa0060/serio1/input1 S: Sysfs=/class/input/input8 U: Uniq= H: Handlers=mouse0 event5 B: EV=7 B: KEY=70000 0 0 0 0 B: REL=3 I: Bus=0011 Vendor=0002 Product=0008 Version=7301 N: Name="AlpsPS/2 ALPS DualPoint TouchPad" P: Phys=isa0060/serio1/input0 S: Sysfs=/class/input/input9 U: Uniq= H: Handlers=mouse1 event8 B: EV=f B: KEY=420 70000 0 0 0 0 B: REL=3 B: ABS=1000003 dmesg: input: DualPoint Stick as /class/input/input8 input: AlpsPS/2 ALPS DualPoint TouchPad as /class/input/input9 I don't know if all those possible configs i find on the net about special /sys/devices/platform/i8042/serio[01] parameter are part of the vanilla kernel. In my case i don't find any mention of a Trackpointer in /sys/devices/platform/i8042/serio[01] or /sys/devices/platform/i8042/serio[01]. Anyway that's probably a user thing and doesn't belong here. Thanks alot for your work!
Great, thank you for testing! As far as the stick going it will not be driven by trackpoint driver - the stick is "hidden" behind the touchpad and we don't know a way to communicate directly with it to enable advanced features (if there are any).
The patch is in mainline, closing.
Hello, I also own a Thinkpad R61 8918-5QG and I have tested this patch on a 2.6.23.1 vanilla kernel. Since then, I'm no longer able to scroll with the middle trackpoint button. I think this is due to the trackpoint buttons being "bound" to the touchpad device ("AlpsPS/2 ALPS DualPoint TouchPad") rather than to the trackpoint device ("DualPoint Stick"). Indeed, I noticed that : - disabling the touchpad in xorg (no AlwaysCore or CorePointer options) resulted in a trackpoint with no buttons usable - and that disabling the trackpoint in xorg let the trackpoint buttons enabled - also, I was able to scroll using the middle trackpoint button in conjunction with the touchpad I would be glad to provide more detailed input but I don't know what would be useful. Thanks. Sébastien Mazy
Also, when no X is running : "cat /input/dev/mouse1" displays data only when the trackpoint is moved "cat /input/dev/mouse2" displays data when either the touchpad, or the touchpad buttons, or the trackpoint buttons are used And my /proc/bus/input/devices gives the following information : I: Bus=0011 Vendor=0002 Product=0008 Version=0000 N: Name="DualPoint Stick" P: Phys=isa0060/serio1/input1 S: Sysfs=/devices/virtual/input/input6 U: Uniq= H: Handlers=mouse1 event6 ts1 B: EV=7 B: KEY=70000 0 0 0 0 0 0 0 0 B: REL=3 I: Bus=0011 Vendor=0002 Product=0008 Version=7301 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 ts2 B: EV=f B: KEY=420 0 70000 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=1000003
Hello, Would it be possible to reopen the bug ? Wheel emulation not working anymore with the trackpoint when the alps dualpoint driver is used is definitely a big regression. Moreover, when disabling the touchpad in the bios, the trackpoint is handled by the trackpoint linux driver. Here is what then displays when you cat proc/bus/input/devices : I: Bus=0011 Vendor=0002 Product=000a Version=0000 N: Name="TPPS/2 IBM TrackPoint" P: Phys=isa0060/serio1/input0 S: Sysfs=/devices/platform/i8042/serio1/input/input6 U: Uniq= H: Handlers=mouse1 event6 ts1 B: EV=7 B: KEY=70000 0 0 0 0 0 0 0 0 B: REL=3 It seems that tha ALPS driver prevents the trackpoint driver to handle the stick, though it is supported. A quick search on the internet shows that a similar problem occurred earlier with the synaptics driver, as Stephen Evanchik (trackpoint driver author) wrote on his blog : http://stephen.evanchik.com/node/35 (quote : "Changes were made to the Synaptics driver that prevent some pass-thru devices from working properly"). We may face the same issue, transposed to the alps driver.
Unlike Synaptics ALPS is unwilling to tell us how to handle pass-through devices so we are not doing this well :( As far as middlebutton scroll goes - the buttons belong to the touchpad, not the trackpoint, unfortunately X only emulates scrolling when button belongs to the same device, which I think is wrong. To restore previous behavior use psmouse.proto=exps.
Thanks for your answer. Fortunately I will be able to revert to the generic driver to keep trackpoint scrolling, or simply disable the touchpad. Too bad ALPS does not cooperate with kernel developers. I sent an email to their customer service but I doubt it will help. The bios configuration of my notebook allows to : - enable both touchpad and trackpoint (recognized as dualpoint touchpad and stick) - enable trackpoint only (recognized as IBM trackpoint) - enable touchpad only (recognized as dualpoint touchpad and stick, though there is no stick device) Is there any test I can perform in those 3 modes that could help understand how ALPS pass-through work or is it much more complicated than that and I am definitely to naive ? (I bet on the second possibility)
I have enabled the Synaptics driver with the patch attached to this bug. This caused my touchpad to be recognized and configured, which is good. But it caused the 3 "mouse buttons" above the touchpad to misbehave. I can't hold them pressed. When i hold any one of them, it's like i just clicked it once and released it immediately. So they cannot be used for dragging or selecting. Is there any further information i can provide to help debug this issue ? (also note that the 2 buttons at the bottom of the touchpad work normally)
I tried to use xev to see what events are generated, and what I see is the following: - hold down one of the 3 buttons above touchpad and move trackpoint: - hold down one of the 2 buttons below touchpad and move touchpad: ButtonPress (button 1) -> MotionNotify (when i later actually release the button, i get ButtonRelease (button 1)) This is correct. However when i do the following combinations, here's what happens: - hold down one of the 3 buttons above touchpad and move touchpad: - hold down one of the 2 buttons below touchpad and move trackpoint: ButtonPress (button 1) -> ButtonRelease (button 1) -> MotionNotify (when i later actually release the button, i get no event at all) Any clue what may generate the spurious ButtonRelease event in the first case ?
Same thing here. Although the trackpoint buttons are part of the software device "AlpsPS/2 ALPS DualPoint TouchPad", they behave in different ways when used in cunjunction with the trackpoint and touchpad. They are usable in none of the cases : - the trackpoint cannot take advantage of them since they do not belong to it (from a linux device point of view) -> no wheel emulation in xorg - using the touchpad causes a release event in xev while the button is not released Should we file a new bug report ?
I have the same issue on my Lenovo X300 with kernel 2.6.28-13. Has there been any development on the ALPS driver? Ben
PS: I noticed, that there is a patch available to enable srolling whith the trackpoint when both trackpoint and touchpad are enabled: http://userweb.kernel.org/~akpm/mmotm/broken-out/input-mouse-alpsc-handle-touchpoints-buttons-correctly.patch will this ever be included in the main kernel? Ben
me again, sorry. patch seems to be merged in 2.6.31-rc1.