Bug 8864

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.