Bug 18375

Created attachment 20043 [details]
failed uinput testcase

bad.c creates a one-key keyboard with KEY_ENTER and attempts to send the KEY_ENTER event.  since the device is not recognized as a keyboard, the KEY_ENTER is not processed.

Created attachment 20044 [details]
workaround uinput testcase

bad.c creates a one-key keyboard with KEY_ENTER and attempts to send the KEY_ENTER event.  by adding an extra dummy key (KEY_A), the uinput device is recognized as a keyboard and sends the KEY_ENTER event properly.

(In reply to comment #2)
> Created an attachment (id=20044) [details]
> workaround uinput testcase
> 
> bad.c creates a one-key keyboard with KEY_ENTER and attempts to send the
> KEY_ENTER event.  by adding an extra dummy key (KEY_A), the uinput device is
> recognized as a keyboard and sends the KEY_ENTER event properly.

whoops, s/bad.c/good.c in that last comment.

Created attachment 20094 [details] [review]
proposed patch

This patch implements what the inline TODO suggests and checks for a id/bustype of BUS_HOST instead of assuming that any 1-bit input devices are acpi buttons.  The patch fixes the problem described in the bug as 1-bit key devices are now handled as "keyboards" instead of "buttons".

Any progress on this bug?  I haven't been able to use my fingerprint scanner for about 6 months now and this is getting very, very frustrating.  Jon submitted a proposed patch several months ago so this should be a fairly painless fix.  Thanks in advance!

also reproducible on gentoo: http://bugs.gentoo.org/show_bug.cgi?id=298459

I bisected myself through the xf86-input-evdev versions 2.2.5 to 2.3.1, checking whether my fingerprint reader would still be functioning without the necessity to append an extra Enter after the swipe.
The first bad commit was this 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>

The versions before that commit send 3 events when swiping the finger over the reader:
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

whereas this version sends only 2 events:
Event. Dev: input12, Type: 1, Code: 28, Value: 1
Event. Dev: input12, Type: 1, Code: 28, Value: 0

the missing third event is only sent after Enter has been pressed on an external keyboard:

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

Any idea what this commit has changed regarding the behavior of the fingerprint reader?

Thanks to Jon's input, issue fixed by sending an extra sync event in pam_thinkfinger.

(In reply to comment #8)
> Thanks to Jon's input, issue fixed by sending an extra sync event in
> pam_thinkfinger.

I guess it depended on the previous behavior which was to send events through as soon as we received them. This should be the correct solution. Sorry for any inconvenience caused; I didn't think to test fingerprint readers at the time.

Also the patch from comment #4 should go in (or at least via xorg-devel) if it hasn't already.