sys-auth/thinkfinger providers a PAM module to allow authentication to the system using a UPEK/SGS Thomson Microelectronics fingerprint reader, as featured e.g. on Thinkpad notebooks. With the upgrade to x11-drivers/xf86-input-evdev-2.3.1, this authentication stops to work as expected: swiping the finger over the sensor does not perform a login any more. However, pressing Enter on an external USB keyboard after the swipe results in a successful login. Same behaviour can be observed with the (currently masked) x11-drivers/xf86-input-evdev-2.3.2. Downgrading to x11-drivers/xf86-input-evdev-2.5.2 fixes the issue. The fingerprint reader as such works fine, as can be verified with the tf-tool, which is also part of sys-auth/thinkfinger.
A bug with identical symptoms has been reported over a year ago for ubuntu: <https://bugs.launchpad.net/ubuntu/+source/thinkfinger/+bug/256429>
Only reproducible in the X server context. On the system console, swiping works as expected.
Using the evbug kernel module, the difference between 2.2.5 (good) and 2.3.1 (bad) becomes visible: Whereas 2.2.5 sends 3 events: Event. Dev: input11, Type: 1, Code: 28, Value: 1 Event. Dev: input11, Type: 1, Code: 28, Value: 0 Event. Dev: input11, Type: 0, Code: 0, Value: 1 2.3.1 sends only two: Event. Dev: input12, Type: 1, Code: 28, Value: 1 Event. Dev: input12, Type: 1, Code: 28, Value: 0 and the missing 3rd event is only sent after pressing enter: Event. Dev: input7, Type: 4, Code: 4, Value: 458792 Event. Dev: input7, Type: 1, Code: 28, Value: 1 Event. Dev: input7, Type: 0, Code: 0, Value: 0 Event. Dev: input12, Type: 0, Code: 0, Value: 1
AFAIK, the ubuntu bug is resolved by adding a bogus second key to the uinput "keyboard", so that it is no longer handled as a button by hal. This bugfix is performed by the 0.3-carriagereturn.patch of sys-auth/thinkfinger-0.3-r1, which I am using - so it does not fix the issue for me. Another tip there is to add a bogus "kbd" section to the xorg.conf and add it to the serverlayout. This does not change the situation for me, either.
link to upstream bug report added
Looks like HAL is also involved in this... I'm not sure x11 has anything to do here. Thanks
Created attachment 214291 [details] lshal output wrt hal: the output of lshal is identical for both the good version 2.2.5 and the bad version 2.3.1 of x11-drivers/xf86-input-evdev.
I bisected my way through xf86-input-evdev version 2.2.5 to 2.3.1 and found this commit to be the first bad one: commit 1f641d75edba7394201c1c53938215bae696791b Author: Oliver McFadden <oliver.mcfadden@nokia.com> Date: Thu Jul 23 13:19:49 2009 +0300 evdev: Only send the events at synchronization time. Instead of just posting the button/key press/release events to the server as soon as they arrive, add them to an internal queue and post them once we receive an EV_SYN synchronization event. The motion events are always sent first, followed by the queued events. There will be one motion event and possibly many queued button/key events posted every EV_SYN event. Note that the size of the event queue (EVDEV_MAXQUEUE) is arbitrary and you may change it. If we receive more events than the queue can handle, those events are dropped and a warning message printed. Tested on my Lenovo T400 using evdev for all input devices; keyboard, touchpad, and trackpoint. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Based on the commit message, I would try sending a EV_SYN after the EV_KEY events in uinput_cr() in pam_thinkfinger-uinput.c. Something like: struct input_event ev = { .type = EV_SYN, .code = SYN_REPORT, .time = {0, }. .value = 0 }; ev_size = sizeof(ev); write (*fd, &ev, ev_size); I don't have the hardware to test though. I'd still recommend the "bogus second key" patch in addition though since I don't think that has been upstreamed to hal yet. I don't think you'd see any difference in lshal since the virtual uinput keyboard is created/destroyed on the fly. Regards, Jon Oberheide
(In reply to comment #9) > Based on the commit message, I would try sending a EV_SYN after the EV_KEY > events in uinput_cr() in pam_thinkfinger-uinput.c. I'll give it a try! > I don't have the hardware to test though. I'd still recommend the "bogus > second key" patch in addition though since I don't think that has been > upstreamed to hal yet. I don't think you'd see any difference in lshal since > the virtual uinput keyboard is created/destroyed on the fly. I ran lshal while the fingerprint reader was "running", e.g. between the PAM authentication request and swiping my finger. During that period of time, a "Virtual ThinkFinger Keyboard" shows up in the lshal output.
(In reply to comment #9) > Based on the commit message, I would try sending a EV_SYN after the EV_KEY > events in uinput_cr() in pam_thinkfinger-uinput.c. Dear Jon, thanks for your input - sending a sync event after the key event fixes the issue - without having adverse effects on pam_thinkfinger on the commandline. Tested with x11-drivers/xf86-input-evdev-2.3.1.
Created attachment 214331 [details, diff] patch that sends sync event patch applied that sends sync event after keys.
Created attachment 214334 [details] ebuild that applies the patch
Awesome! Glad you got it working! Regards, Jon Oberheide
Thanks Jon! Patch submitted upstream: https://sourceforge.net/tracker/?func=detail&atid=889697&aid=2921928&group_id=179573
Ok then nothing for X11 or HAL teams, reassigning. Thanks for finding the cause of this, very interesting read :) Thanks
Thanks a lot, this patches fixes my issue too :) Cheers, jcat
Thank you. I first found your patch upstream and wrote my own -r2. When I wanted to file the report I found this one. The -r2 ebuild should make its way into the tree!
The supplied patch and ebuild solves this for me as well. Thanks. This was driving me crazy.
Confirmation that it works for me here as well.
Works for me on amd64. When will this be in the tree?
ACK, the -r2 ebuild show go into the tree. Works well for x86 here.
Sorry, I don't have much time now, but I will try to put this on portage ASAP. Thanks for the patch :).
Created attachment 224929 [details] file found on my system in addition to thinkfinger this -r2 ebuild works fine on mu amd64 with x11-drivers/xf86-input-evdev-2.3.2
+*thinkfinger-0.3-r2 (11 Apr 2010) + + 11 Apr 2010; <chainsaw@gentoo.org> +files/0.3-send-sync-event.patch, + -thinkfinger-0.2.2-r1.ebuild, -thinkfinger-0.3.ebuild, + files/60-thinkfinger.rules, -thinkfinger-0.3-r1.ebuild, + +thinkfinger-0.3-r2.ebuild: + Revision bump by Víctor Enríquez Miguel. Patches from mephinet & Michael + Weber close bug #298459. Patch from Michael Weber closes bug #309751.
