It seems to be related to libpam-thinkfinger's use of uinput. libpam-thinkfinger creates a uinput device to send a EV_KEY/KEY_ENTER press and release. This event _should_ emulate the enter key being pressed after a finger swipe so that the user does not have to press it manually.

I don't see any errors in the pam debug output about sending the enter event. Either libpam-thinkfinger is misusing uinput somehow or GDM is not processing the key event (maybe it's blocking focus on the password prompt textbox?).

Simply setting another KEYBIT along with our KEY_ENTER seems to fix the issue. The other KEYBIT can be any value and it doesn't seem to matter if the other KEYBIT is set before or after KEY_ENTER. If another KEYBIT is not set, it appears that the kernel is not sending the KEY_ENTER event.

I don't recommend committing this until we figure out what the root cause is, but if anyone else experiencing the problem could test it and verify that it resolves their issue, that'd be great.h

FYI, this issue of not receiving a key event when only one is set is reproducible in a standalone test program outside of thinkfinger-pam. So either it's a kernel issue or for some reason uinput wasn't designed to work with only a single KEYBIT set (which seems incorrect since it worked with earlier kernels).

I've attached two samples that show this behavior outside of thinkfinger.

They both create a uinput device and send a KEY_ENTER event. In bad.c, when the device is only set up with a KEY_ENTER key, the KEY_ENTER event is not observed in X. However, in good.c, if another supported key (say KEY_A) is added to the uinput device as well, the sending of the KEY_ENTER event works just fine.

Both of the testcases work as expected outside of X in the terminal which leads to me to believe something is getting munged in X's input layer.

That works great for me.
The InputDevice section was already there with the entry for the keyboard. But I had to add the line to the "ServerLayout" section. Once I restarted X, I could log in without following the swipe with a carriage return.

Attached is a patch to thinkfinger that should workaround the bug by adding a dummy key (KEY_A) to the uinput device.

It's certainly not a proper fix to why xorg is not correctly sending the KEY_ENTER but it's certainly an option for those of you who find hitting enter after you swipe annoying and/or don't have an xorg.conf to add the configuration workaround.

to the "ServerLayout" section, the fingerprint reader works as before.
</quote>

Adding this to my xorg.conf causes unwanted side-effects, such as causing my volume control button next to my headphone jack to stop working, and bizarrely stopping the key combinations ctrl-<arrow key> to stop working also. So this is not an option for me.

Unsure. It uses the workaround patch previously posted (adding a dummy KEY_A key capability to the uinput device). Without the workaround, the uinput device doesn't even show up in "xinput list". For some reason, a keyboard uinput device with only a KEY_ENTER is not sufficient to be registered.

So while it's more of a workaround than a fix, it does indeed resolve the issue and has absolutely zero side effects.

When creating a uinput device with only one key, hal incorrectly assigns it as a "button" rather than a "keyboard". This problem manifests itself in libpam-thinkfinger when a uinput device is creating to automatically send a carriage-return after the user swipes his fingerprint.

The problem lies in input_test_key() in hal's hald/linux/device.c. Since num_bits == 1 for a one-key keyboard, the device will be consider a button.

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.

I've tracked down the source of this issue in hal's hald/linux/device.c. When a new input device is added, it goes through a series of checks to determine what kind of device it is (mouse, keyboard, etc).

In input_test_key(), hal will figure out the size of the bitmask of the devices (num_bits, aka the number of "buttons" this input device has). If num_bits == 1, hal will treat the device as a "button" (eg. power/sleep/hibernate button) rather than a keyboard. Otherwise, it will run further checks to see what kind of keyboard it is (input_test_keyboard(), input_test_keypad()).

This explains exactly why having only a single key on the uinput device (KEY_ENTER) fails to work and adding a second dummy key (KEY_A) fixes the problem. Without the dummy key, the uinput device is treated as a "button" instead of a "keyboard" and does not send the KEY_ENTER event when using libpam-thinkfinger.

I'll email upstream and figure out if there's a proper fix to allow one-button keyboards or if hacking around it is the best approach.

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".

Recently upgraded from ubuntu 8.04 to 8.10 on my Dell XPS 1330, the finger print module worked perfectly before the upgrade, but now .....
firstly I had to hit carriage return after the swipe, but this was later fixed after I installed packages from Jon Oberheide.
But there's something else I realized now, if I try to type my password (instead of swiping my finger) then it prompts me to retype the password, and it does this thrice.

Jon: I've libpam-thinkfinger 0.3+r118-0ubuntu4~ppa1 from your PPA. It has the following problem: if you type in your password and press Enter at the 'Password or swipe finger:' prompt, it still sends that extra Enter keypress (twice!). So, for example, if you do sudo apt-get dist-upgrade, you get no choice to answer the first two apt's confirmation prompts -- they get answered for you.

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:

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.

I'm not sure to which bug report it was posted, but Ubuntu has decided to no longer support Thinkfinger. fprint is the supported direction, despite its flaws, because no one has been working on Thinkfinger upstream and RedHat is funding fprint development.

Checking the bug reports for the various fprint packages not much seems to be happening in Ubuntu and thinkfinger seems still to be the better option in most cases where the fingerprint reader is supported by thinkfinger.

Once configured, it prompts you to scan your finger, no chance for entering password instead... After several failed attempts, however, it falls back to password authentication. I wonder if there is any way to change such behavior.

Anyone got any ideas? I'm not really keen on the X hack, although I'm more comfortable with it than the patch Samuel Piau wrote about, primarily because I understand what the X hack is doing, not what his pam patch is doing.

Here is a more detailed explanation about this patch, it is not related to pam, but to device input event processing.

At some point xf86-input-evdev was changed to a newer version (2.2.5 to 2.3.1 ?), and they changed the events processing :

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.
[...]

What happens is the additional key code that was added in previous thinkfinger patch is not sent until a real keystroke happens (when you press enter). The patch here adds a synchronisation event after the key code, so that it is immediately posted.

Yeah, the documentation has changed its recommendation for modifying package versions for PPAs, so I followed the new recommendation. Older packagers from PPAs (such as Jon's will probably look newer). You should be able to install mine by doing something like:

Since we already have a working fix for thinkfinger why would nobody add it to the official repo? For example for business users working fingerprint authentication may be an important criterion to use or not to use Ubuntu and since thinkfinger did work in Hardy, Jaunty and Karmic, for a lot of people doing dist-upgrade to Lucid this bug might become a really bad surprise!

Before this bug will go into archive it should at least be f.i.x.e.d. I've even posted a message to the Ubuntu-motu maillist (http://tinyurl.com/358m7lq) since MOTU is listed as the official package maintainer and ... nothing as you see! Is it really that difficult to add a working patch to a package in the repository? So much for filling bugs and helping developers :(

I'll upload the fix, but except if someone adopt it, this kind of problems will appear from time to time, with sometime no solutions. My advice is that you upgrade to fprint, as indicated in the Debian bug I referenced.

Thanks for uploading the package. fprint is just as dead upstream as
thinkfinger, and in addition does not allow the user to chose between
fingerprint and password authentication, so it's not a viable
alternative at this point.

On 07/27/2010 05:53 AM, Fabrice Coutadeur wrote:
> Hi,
>
> For your information, thinkfinger has been removed from Debian almost
> one year ago because it was dead upstream (http://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=546005).
>
> I'll upload the fix, but except if someone adopt it, this kind of
> problems will appear from time to time, with sometime no solutions. My
> advice is that you upgrade to fprint, as indicated in the Debian bug I
> referenced.
>
> Fabrice
>
> ** Bug watch added: Debian Bug tracker #546005
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546005
>

I took the suggestion and upgraded to fprint for a couple of months. It is a downgrade. pam_thinkfinger at least prompts sensibly when doing the gsudo-type things. pam_fprint just sits there stupidly and you have to guess when something is waiting for a fingerprint scan or password. Combine that with not being able to type the password while a scan is being requested and you have a pretty frustrating piece of software... :-(