Bug 43131
Summary: | Touchpad with bad behavior | ||
---|---|---|---|
Product: | Drivers | Reporter: | a-curtis |
Component: | Input Devices | Assignee: | drivers_input-devices |
Status: | RESOLVED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | chris, james, kernel-bugzilla.3.atliang, marcos.souza.org |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.4.0-999-generic | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
fspad.inf
script to initialise 10.1.1 hardware based on fspad.ini script to initialise 10.1.1 hardware based on fspad.ini(lower case) |
Description
a-curtis
2012-04-19 23:00:05 UTC
(In reply to comment #0) > This is on an Advent 5411 which has a sentelic touchpad. Would you please post the h/w information extracted from: "dmesg | grep Finger" ? Here you go [ 19.087720] psmouse serio1: sentelic: Finger Sensing Pad, hw: 10.1.1, sw: 1.0.0-K, buttons: 2 [ 19.437617] input: FSPPS/2 Sentelic FingerSensingPad as /devices/platform/i8042/serio1/input/input7 (In reply to comment #2) > Here you go > > [ 19.087720] psmouse serio1: sentelic: Finger Sensing Pad, hw: 10.1.1, sw: > 1.0.0-K, buttons: 2 Wow, looks like a pretty ancient hardware to me(back to year 2007). Someone on the archlinux forum mentioned about downgrading xf86-input-synaptics to version 1.5.99.902-1 may solve this issue, though. (In reply to comment #3) > (In reply to comment #2) > > Here you go > > > > [ 19.087720] psmouse serio1: sentelic: Finger Sensing Pad, hw: 10.1.1, > sw: > > 1.0.0-K, buttons: 2 > Wow, looks like a pretty ancient hardware to me(back to year 2007). > > Someone on the archlinux forum mentioned about downgrading > xf86-input-synaptics > to version 1.5.99.902-1 may solve this issue, though. I got this laptop in sept 2009 but it was cheap. I guess that's why if they used old hardware. Thanks but unfortunately that version of xf86-input-synaptics was no better I couldn't find hardware 10.1.1; however, with hardware 12.0.1(which should be the same generation of FSP. The packet output between them are identical), I can't reproduce the jumpy cursor behaviour on Ubuntu 12.04(kernel 3.4.0-rc4 + xserver-xorg-input-synaptics 1.5.99.902-0ubuntu5.1). Given that the hardware we're using(10.1.1/12.0.1) are using relative coordinates, I suspect that recently introduced absolute mode could cause this trouble. By any chance would you please try to add "options psmouse proto=imps" in your /etc/modprobe.d/psmouse.conf and see if going back to imps protocol gives you any improvement? I did not have that file so I created it and added the text you suggested. I then installed the latest xserver-xorg-input-synaptics and restarted. It seemed better at first but after half an hour I got the jumpy cursor again. Not quite as bad as it was though. Now my touchpad is detected as ImPS/2 Generic Wheel Mouse Also noticed output from cat /var/log/Xorg.0.log says that 11 mouse buttons are found for sententelic finger sensing pad and that no device driver is specified. That can't be right can it? (In reply to comment #6) > I did not have that file so I created it and added the text you suggested. I > then installed the latest xserver-xorg-input-synaptics and restarted. It > seemed > better at first but after half an hour I got the jumpy cursor again. Not > quite Did you happen to suspend/resume the laptop before running into this jumpy cursor scenario? This looks to me that driver is receiving mangled(bad sequence or missing byte perhaps?) packets. > as bad as it was though. > > Now my touchpad is detected as ImPS/2 Generic Wheel Mouse > > Also noticed output from cat /var/log/Xorg.0.log says that 11 mouse buttons > are > found for sententelic finger sensing pad and that no device driver is > specified. That can't be right can it? I don't know why evdev simply taking button index returned by EvdevUtilButtonEventToButtonNumber() as the number of buttons. I would prefer following code instead: --- xserver-xorg-input-evdev-2.7.0/src/evdev.c.orig 2012-05-10 14:04:52.000000000 +0800 +++ xserver-xorg-input-evdev-2.7.0/src/evdev.c 2012-05-10 14:04:53.000000000 +0800 @@ -2102,8 +2102,8 @@ if (EvdevBitIsSet(pEvdev->key_bitmask, i)) { mapping = EvdevUtilButtonEventToButtonNumber(pEvdev, i); - if (mapping > num_buttons) - num_buttons = mapping; + if (mapping != 0) + num_buttons++; } } I didn't suspend/resume. It seems that if I tap the touchpad in different places it will send the cursor off in different directions. tap top of touchpad cursor down tap bottom cursor goes up tap left side cursor goes right tap right side cursor goes left What I find strangest though is why clicking the actual button would move the cursor at all. (In reply to comment #8) [...] > What I find strangest though is why clicking the actual button would move the > cursor at all. Sounds to me that this model may need to be tuned with customised settings. Do you happen to have Windows + FSP native driver installed? I know this sounds strange; however, if you can't reproduce the same jumpy/abnormal behaviour in Windows, we could probably take advantage of the settings written in Windows driver. That said, if windows works without any of the above abnormal behaviour, please post the fspad.inf included in windows driver(should be able to extract it from driver/setup CD-ROM provided by the laptop manufacturer). Created attachment 74011 [details]
fspad.inf
I got a hold of the driver for vista. It worked normally when I had vista installed. Here is the fspad.inf
Created attachment 74161 [details] script to initialise 10.1.1 hardware based on fspad.ini Please try this bash script which is based on the fspad.ini supplied in attachment#74011 [details]. Thanks. I tried your script but it says unexpected readback for 01: 01a1 Unexpected FSP hardware. Not 0xA1. and there is no change. Thanks Created attachment 74261 [details]
script to initialise 10.1.1 hardware based on fspad.ini(lower case)
Sigh, the driver returns strings in lower case. This version should work with 10.1.
Thanks but this script does not affect the touchpads behavior (In reply to comment #14) > Thanks but this script does not affect the touchpads behavior Interesting. I'll need your help to do vista related debugging. Since it's a Linux kernel tracking system, we should do this offline. Can you still reproduce this same problem in a recent kernel/distribution? |