|
Description
Éric Brunet
2014-11-16 11:11:18 UTC
Created attachment 109548 [details]
evemu-record of selecting text from left to right raising the index several times
First example in the event E: 0.415903 0001 0110 0000 # EV_KEY / BTN_LEFT 0 BTN_LEFT is released, followed in the next event by BTN_LEFT 1 and BTN_TOOL_DOUBLETAP 1 as well within the same frame. Definitely a kernel/firmware issue, needs to be fixed in the kernel too. Hans, Benjamin? Hi, Can you please directly after booting up the system do: dmesg > dmesg.txt And attached the generated dmesg.txt file here ? Thanks, Hans Created attachment 109618 [details]
dmesg just after boot
Kernel is the one packaged by fedora20 (3.17.2-200) plus one single patch written by B. Tissoires to make my pen working, hence the weird name "atmelfix". I have also tried the original fedora20 kernel, which has the same bad behaviour for the clickpad.
for synaptics, I have tried the packaged version by fedora20 (1.7.6) and also the latest git version.
If this is a kernel bug, should I open another bug on bugzilla.kernel.org and/or send a message to the linux-input mailing list, or is this bug enough to track the problem?
I have tried to understand a little bit more the problem, and, while playing with evtest, I have the impression that there are actually two different bugs!
* one bug is that the driver sends a BTN_LEFT=0 followed by a BTN_LEFT=1
when another finger comes touching the clickpad while a first finger is
clicking it.
* the other bug is that the behaviour depends on _where_ the clicking finger
is on the clickpad. If it is in the bottom region of the clickpad (where the
buttons are in emulation mode), the driver is extra-buggy; see below.
When the clicking finger is elsewhere, things are better.
Here is what I have done; with evtest running, I only look at
EV_KEY/BTN_xxx and SYN_REPORT events. I make the following sequence of touches and record the outcome:
A) I click somewhere,
B) I touch with another finger (while still clicking),
C) I lift the other finger (while still clicking),
D) I touch again with another finger (while still clicking),
or, after C):
D') I remove the clicking finger
The first bug appears in steps B and D: the two BTN_LEFT events (see below)
shouldn't be there.
The second bug appars in step C, if the clicking finger is in the
bottom part of the clickpad. In that case, after step C, the reported state
is inconsistent; it has : LEFT=1 TOUCH=0 FINGER=0 DOUBLETAP=0. The steps
D and D' depend also on the position of the clicking finger, but they actually report what is needed to make the state consistent again.
Here is the record. A line of dashes is one or more SYN_REPORT.
A) I click somewhere
BTN_TOUCH = 1
--------------------
BTN_TOOL_FINGER = 1
--------------------
BTN_LEFT = 1
B) I touch with another finger (while still clicking),
BTN_TOOL_FINGER = 0
BTN_LEFT=0 <= Buggy!
-----------------------
BTN_TOOL_DOUBLETAP=1
BTN_LEFT = 1 <= Buggy!
C) I lift the other finger (while still clicking),
*** If the click is in the bottom part
BTN_TOUCH = 0 <= Buggy!
BTN_TOOL_DOUBLETAP =0
*** If the click is elsewhere
BTN_TOOL_FINGER =1
BTN_TOOL_DOUBLETAP=0
D) I touch again with another finger (while still clicking),
*** If the click is in the bottom part
BTN_TOUCH = 1
BTN_LEFT = 0 <= Buggy!
-------------------
BTN_TOOL_DOUBLETAP=1
BTN_LEFT = 1 <= Buggy!
*** If the click is elsewhere
BTN_TOOL_FINGER = 0
BTN_LEFT=0 <= Buggy!
-----------------------
BTN_TOOL_DOUBLETAP=1
BTN_LEFT = 1 <= Buggy!
D') After C), I lift the clicking finger (nothing is touching anymore)
*** If the click is in the bottom part
BTN_TOUCH = 1
BTN_LEFT = 0
-------------------
BTN_TOOL_FINGER = 1
-------------------
BTN_TOUCH = 0
BTN_TOOL_FINGER = 0
*** If the click is elsewhere
BTN_LEFT = 0
-------------------
BTN_TOUCH = 0
BTN_TOOL_FINGER = 0
Hi, Unfortunate the dmesg does not contain the info I'm looking for. I see that you're are running Fedora kernels, these have dyndbg enabled, can you please add: dyndbg="file drivers/input/mouse/* +p" To your kernel commandline, and then gather a new dmesg (again directly after boot please). Thanks, Hans Created attachment 110007 [details]
dmesg after boot with dyndbg enabled
I had a hard time enabling dyndbg, as I got hit by the grub2 fedora bug 923374 about replacing spaces by \x20. Fortunately, the solution you gave of installing f21 packages worked...
Anyway, here is the dmesg. The only new lines that appeared and seemd relevant are:
[1.405327] psmouse serio4: cypress_ps2: send extension cmd 0x00, [0 0 0 0]
[1.652684] psmouse serio4: cypress_ps2: Command 0x00 response data (0x): 00 00 14
[1.696480] psmouse serio4: alps: E6 report: 00 00 64
[1.733506] psmouse serio4: alps: E7 report: 73 03 0a
[1.770560] psmouse serio4: alps: EC report: 88 b3 18
[2.220638] psmouse serio4: alps: E6 report: 00 00 64
[2.258180] psmouse serio4: alps: E7 report: 73 03 0a
[2.302738] psmouse serio4: alps: EC report: 88 b3 18
[2.333874] psmouse serio4: alps: EC report: 88 b3 18
[2.435072] psmouse serio4: alps: pitch 42x36 num-electrodes 21x13 physical size 84x43 mm res 48x47
(In reply to Éric Brunet from comment #7) > Created attachment 110007 [details] > dmesg after boot with dyndbg enabled > > I had a hard time enabling dyndbg, as I got hit by the grub2 fedora bug > 923374 about replacing spaces by \x20. Fortunately, the solution you gave of > installing f21 packages worked... Oh, good that you figured out that one yourself, thanks. > Anyway, here is the dmesg. The only new lines that appeared and seemd > relevant are: > > [1.405327] psmouse serio4: cypress_ps2: send extension cmd 0x00, [0 0 0 0] > [1.652684] psmouse serio4: cypress_ps2: Command 0x00 response data (0x): 00 > 00 14 > [1.696480] psmouse serio4: alps: E6 report: 00 00 64 > [1.733506] psmouse serio4: alps: E7 report: 73 03 0a > [1.770560] psmouse serio4: alps: EC report: 88 b3 18 > [2.220638] psmouse serio4: alps: E6 report: 00 00 64 > [2.258180] psmouse serio4: alps: E7 report: 73 03 0a > [2.302738] psmouse serio4: alps: EC report: 88 b3 18 > [2.333874] psmouse serio4: alps: EC report: 88 b3 18 > [2.435072] psmouse serio4: alps: pitch 42x36 num-electrodes 21x13 physical > size 84x43 mm res 48x47 OK, good, so you've a v7 touchpad, which I already suspected, but I wanted to know for sure before chasing down the wrong rabbit hole. I've a hunch what might be the problem, but I cannot really put my finger on it. So can you please do the following: 1) Boot with i8042.debug=1 on the kernel commandline 2) Login, do dmesg > dmesg.txt Note dmesg.txt will now contain your PASSWORD (in ps/2 scan codes) !!!!! 3) Do the troublesome click + select text sequence on the touchpad 4) Do dmesg > dmesg.touchpad Now compare the 2 dmesg files, and create a new file copying only the *new* lines in dmesg.touchpad to the new log file. 5) Attach the new log file here Created attachment 110071 [details]
dmesg with i8042.debug=1, clicking at bottom and dragging
Comparing two dmesg wouldn't work; the sequences are so long that the second dmesg didn't have all the info. I rather did
sudo dmesg -C && dmesg -w > file
The first recorded event is the release of the enter key (I guess) and the last recorded events are hitting Ctrl-C (I guess again. I don't speak PS/2)
In between the interesting stuff. I did click towards the bottom left of the touchpad, touched the top and moved the touching finger, released the touching finger then released the clicking finger.
Created attachment 110073 [details]
dmesg with i8042.debug=1, clicking at top and dragging
As the behaviour seems different whether I click at the bottom or at the top, I attached another fragment of dmesg where this time I click touwards the top of the touchpad, touch with another finger, move the touching finger, raise the touching finger and then raise the clicking finger
Hi, Thanks for the detailed logs, so my hunch about the problem was correct, but only part of the problem. i've ended up writing 3 separate patches to sort out all issues your 2 traces show. I'll attach both my debugging tool (parts of the kernel code copied to a c file to generate a binary to interpret the i8042.debug traces + output of that tool), as well as the 4 kernel patches I did. I'm currently starting a scratch build of a f20 kernel with those patches added to it. I'll leave another comment when the upload of the srpm has finished. Regards, Hans Created attachment 110308 [details]
alps v7 8042 dump debugging tool + output
Created attachment 110310 [details]
4 kernel patches hopefully fixing the issues discussed in this bug.
Hi, Ok, so the scratch build kernel is building now: http://koji.fedoraproject.org/koji/taskinfo?taskID=8269499 Once it is done, download kernel-3.17.4-201.fdo86338.fc20.x86_64.rpm, and do: sudo rpm -ivh kernel-3.17.4-201.fdo86338.fc20.x86_64.rpm And then boot into the new kernel and see if it resolves the various issues you've been experiencing. Regards, Hans This is all very nice: everything I am using on this touchpad is working nicely: I can click and drag without any problem. Now, there are still some problem with the touchpad. Some theoretical problem, I should say, because it concerns three fingers and four fingers tap which are not so useful. If I put one, two, three and then four fingers on the upper part of the clickpad, I get the expected sequence (printing only the BTN_...) Event: type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1 Event: type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1 ------------ <- putting the second finger Event: type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0 Event: type 1 (EV_KEY), code 333 (BTN_TOOL_DOUBLETAP), value 1 ------------ <- putting the third finger Event: type 1 (EV_KEY), code 333 (BTN_TOOL_DOUBLETAP), value 0 Event: type 1 (EV_KEY), code 334 (BTN_TOOL_TRIPLETAP), value 1 ------------ <- putting the fourth finger Event: type 1 (EV_KEY), code 334 (BTN_TOOL_TRIPLETAP), value 0 Event: type 1 (EV_KEY), code 335 (BTN_TOOL_QUADTAP), value 1 When the first or second tap is on the bottom part of the clickpad (on the natural position of the buttons), the third finger isn't seen and the fourth finger is counted as the third. The events sent are then Event: type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1 Event: type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1 ------------ <- putting the second finger Event: type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0 Event: type 1 (EV_KEY), code 333 (BTN_TOOL_DOUBLETAP), value 1 ------------ <- putting the third finger THEN the fourth finger Event: type 1 (EV_KEY), code 333 (BTN_TOOL_DOUBLETAP), value 0 Event: type 1 (EV_KEY), code 334 (BTN_TOOL_TRIPLETAP), value 1 I'll attach a trace to document this weird behaviour. But again, I don't care about three fingers of four fingers, I care about click and drag and you fixed that. You're awesome, thank you ! Created attachment 110325 [details]
dmesg trace of putting four fingers on the clickpad with the first at bottom
I put the first finger on the bottom left of the clickpad, then fingers 2, 3 and 4 on the upper part, from left to right, then I remove the fingers.
The third finger is not registered and the fourth is registered as the third.
Created with the patched kernel 3.17.4-201.fdo86338 botted with i8042.debug=1.
Created attachment 110353 [details]
alps v7 8042 dump debugging tool + output
Hi,
Thanks for the new dump, that explains the purpose of 2 (re-used) bits on clickpads which were not clear, and as such are not being used. These bits get set when > 2 fingers are present and some fingers are in the button areas at the bottom.
I'm attaching a new decode tool (which properly sees the number of fingers now), as well as a new set of kernel patches.
I'll also do another scratch build for you to test.
Regards,
Hans
Created attachment 110354 [details]
4 kernel patches hopefully fixing the issues discussed in this bug.
Hi, Ok, so the scratch build kernel with the new set of fixes is building now: http://koji.fedoraproject.org/koji/taskinfo?taskID=827630 Once it is done, download kernel-3.17.4-201.fdo86338_2.fc20.x86_64.rpm, and do: sudo rpm -ivh kernel-3.17.4-201.fdo86338_2.fc20.x86_64.rpm And then boot into the new kernel. Please test the following: 1) All the original issues you were experiencing as a result of the 3 / 4 finger patches, the fixes for those have changed too 2) 3 / 4 fingers down with a finger in the left button area (as you've done the last time) 3) 3 / 4 fingers down with a finger in the *right* button area 4) 3 / 4 fingers down with a finger in the left button area *and* a finger in the right button area 5) 3 / 4 fingers down with 2 fingers in the left button area (if that will fit) If any of these causes issues, please provide a new i8042.debug dump Thanks & Regards, Hans I finally found the kernel at http://koji.fedoraproject.org/koji/taskinfo?taskID=8276307 I have tried my touchpad in all the possible ways while watching the output of evtest, and I couldn't find any bad behaviour. Click and drag works as expected, and three and four finger taps are correctly reported. I'd say this device works perfectly, now, and I am marking the bug as resolved/fixed. Thank-you a lot! (In reply to Éric Brunet from comment #20) > I finally found the kernel at > http://koji.fedoraproject.org/koji/taskinfo?taskID=8276307 Ugh, sorry for messing up the copy & paste of the url. > I have tried my touchpad in all the possible ways while watching the output > of evtest, and I couldn't find any bad behaviour. Click and drag works as > expected, and three and four finger taps are correctly reported. > > I'd say this device works perfectly, now, and I am marking the bug as > resolved/fixed. > > Thank-you a lot! You're welcome, thanks for the high quality bug report and feedback, I could not have fixed this without your help. I'll go and send the fixes upstream now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.