heya, I have an IBM/Lenovo X200 Tablet PC, with a trackpoint pointing device. Previously, on 2.6.31, I was able to enable trackpoint scrolling, as per the instructions here: http://www.thinkwiki.org/wiki/How_to_configure_the_TrackPoint#Configuration_using_udev_and_HAL However, upon upgrading to 2.6.32, this no longer works. It appears that the device name has been changed from "TPPS/2 IBM TrackPoint", to "PS/2 Generic Mouse". However, even with this fix, the trackpoint scrolling stops working after a suspend/resume cycle, and will not work again till the machine is rebooted. Also, other users report that setting the sensitivity/speed of the trackpoint is now broken, as the files /sys/devices/platform/i8042/serio1/sensitivity and /sys/devices/platform/i8042/serio1/speed don't exist anymore. There's a discussion of the issue on the Arch Forum Boards here: http://bbs.archlinux.org/viewtopic.php?pid=680645 as well as a Ubuntu bug report here, with dmesg and other diagnostics: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/492729 and an Arch Linux bug report here: http://bugs.archlinux.org/task/17435 Cheers, Victor
Hm, could I get dmesgs of boot with i8042.debug from both working and non-working kernels, please? Also, on non-working kernel, does anything chnage if you compile psmouse as a module and reload it onve the box finishes booting?
Some debugging shows that the trackpoint in my X200s quite gets confused because of the Finger Sensing pad detection added in fc69f4a6af49ee69475dc4217924d9edf77760e0, the TP_READ_ID command just times out. Doing a psmouse_reset after trying to detect an fsp device or just not compiling with CONFIG_MOUSE_PS2_SENTELIC turned on nicely fixes the issue.
Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com>
Umm, I am not so keen on adding another reset, it will slow down detection even more. I'll ask Sentelic guys if we can move FSP detection lower.
heya, This is from a kernel where it doesn't work properly. I added "i8402.debug=1" to my Grub options, and I've pasted my dmesg output here: http://pastie.org/774382 When I do a "lshal | grep product.input", I find: input.product = 'PS/2 Generic Mouse' (string) In my /etc/hal/fdi/policy/mouse-wheel.fdi file, I have: <match key="info.product" string="TPPS/2 IBM TrackPoint"> <merge key="input.x11_options.EmulateWheel" type="string">true</merge> <merge key="input.x11_options.EmulateWheelButton" type="string">2</merge> <merge key="input.x11_options.YAxisMapping" type="string">4 5</merge> <merge key="input.x11_options.Emulate3Buttons" type="string">true</merge> <merge key="input.x11_options.EmulateWheelTimeout" type="string">200</merge> <merge key="input.x11_options.XAxisMapping" type="string">6 7</merge> </match> When I do a "rmmode psmouse", and then a "modprobe psmouse", I see in my lshal output: input.product = 'TPPS/2 IBM TrackPoint' (string) Not sure why this is. And of course, after the rmmod/psmouse, my trackpoint scrolling works again. Cheers, Victor
Created attachment 24518 [details] MOve fsp detection below trackpoint Could you please try this patch and let me know if it restores trackpoint detection? Thanks!
Thanks, works for me on my x200 (no tablet though) with 2.6.32.3 and 2.6.33-rc3-00291-g066000d-dirty.
Works also on x61t with 2.6.32.3. Thank you!
Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=24518
One remark, of which I don't know if it's relevant for a the patch: I notice on my x61t that after suspend speed and sensitivity of the trackpoint are reset to 97 and 128 respectively, regardless of their previous setting. Manually re-setting the values changes back to desired behaviour as expected. Thanks for your work!
(In reply to comment #10) > One remark, of which I don't know if it's relevant for a the patch: I notice > on > my x61t that after suspend speed and sensitivity of the trackpoint are reset > to > 97 and 128 respectively, regardless of their previous setting. Manually > re-setting the values changes back to desired behaviour as expected. > Hmm, that suggests that the trackpoint goes through full disconnect and not reconnect at resume. Did this also happen on older kernels? Please open a new bug so we don't mix up 2 separate issues. Thanks.
Fixed by commit 4a18b3ab6ed537b055e3fcfca64ab870b4f9acf0.