I got a small usb fingerprint reader (UMAX, but I think it’s a generic one with UMAX printed brand on it).
My Leap 15.1 doesn’t seem to se it:
**linux-e53g:/home/libor #** lsusb
...
Bus 001 Device 002: ID 27c6:5740
...
This one is appearing and disappearing, whin pluging/unplugin the USB fingerprint reader. It’s also the only one without text label.
Any ideas how to proceed?
By the way, I installed fprintd and such, but that is only next step, after it will be recognized as hardware.
I am not sure what you mean with “see it”.
The system does detect it and reads from it
27c6:5740
which is a Vendor ID and a Product ID (as specified by that vendor).
When these IDs are knw to the system (there is a list of them in the system that is regularly updated), it will also print that textual information, which it doesn’t in your case.
While this could only be “that it is not in the list”, it proably also means that the system has no idea what sort of device it is.
BTW, searching on the Internet reveals: Shenzhen Goodix Technology Co.,Ltd.Fingerprint Reader
But that is not new to you 
Thank you Henk, that was helpful. Mind refreshing and educative :-).
So aparently, there’s no way to make it work, I guess. I found no perfect match, but this is fingerprint reader from the same vendor Shenzhen Goodix Technology Fingerprint Reader.
This is not realy a subject where I am very good in. Better wait for others to tune in before you jump to the conclusion “there’s no way to make it work”.
I could imagine that something could be done inspecting udev rules on the system. E.g. findng if there are udev rules for fingerprint devices and then adding these number so the system uses the driver it has for those others one on your device. But as said, that is only a vague idea of mine.
Hi
The USB ID doesn’t show up as supported either;
https://fprint.freedesktop.org/supported-devices.html
If I were hazard an educated guess,
Anything that’s manufactured in that part of China will be supported generically.
Therefor,
Typical of any authentication device or method in Linux,
You first need to decide how you want to use the device, authentication for logging into a device or machine is usually very different than logging into a service from a running machine.
When you log into your machine, it generally involves the display manager and sometimes a PAM service.
When you log into a service, depending on how it’s built you might pass tokens or certificates to an authenticator for authorization.
Assuming you’re logging into the device and your fingerprint reader is built to support fprint,
the following ArchWiki article will probably get you working…
https://wiki.archlinux.org/index.php/Fprint
HTH,
TSU
Although it’s worth checking,
Of course we know that such a list is likely incomplete, and probably moreso considering the origin of this device where new products appear almost hourly.
TSU
Well TSU, thanks for suggestions. If you think it’s worh trying, I’m up for some fun :-).
However, I already did try enroll (first thing I did) and it didn’t found any devices:
# fprintd-enroll
list_devices failed: No devices available
As for the purpose, I’d love to use it for logging into the system, because I find it extremely convenient. I replaced SDDM with LightDM due to SDDM not supporting remote access, so if the device is woking, the next step would be to set it up with the DM.
Have you installed the necessary PAM module?
If you have, pls post the name of the package you installed.
You may also need a PAM configuration to enable your fingerprint reader, similar to what is described in the following Ubuntu article
http://www.thinkwiki.org/wiki/How_to_enable_integrated_fingerprint_reader_with_fprint
Been awhile since I’ve dealt with these kinds of issues (device identification, udev rules), my main experience was several years ago adding an Android device when they often weren’t properly identified so you couldn’t set up ADB (Android Device Bridge) to communicate with the device.
And, I’m sure a few things have probably changed since I’ve worked with this situation.
From the following article
https://opensource.com/article/18/11/udev
Possibly an important suggestion is to display device information to know what your machine knows or doesn’t…
# udevadm info -a -n /dev/sdb | less
At that point you will be at a bit of a crossroads depending on what is displayed.
If the device is properly identified as a fingerprint reader, then maybe all you need is a proper udev rule to make it work…
You can try the udev rule suggested in the article, if it doesn’t post your result…
TSU
Always wanting to learn.
As I mentioned earlier I also guess that maybe a (changed) udev rule might help here, But have lack of knowledge where and how to look.
I tried to understand from the udevadm man pge what the -n option does. I assume it is one way toidentify about which device you want the information from the usdev database. But why /dev/sdb? Nowhere such a device is mentioned in this thread. Nowhere is there even any mention of a mass-storage device.
Is a fingerprint reader seen as a mass-storage device? And when yes, why should it be sdb? That would depend on how many other mass-storage devices are already connected to the system, of which there is no information.
This triggers me to the suggestion of tracking what logging is created during the connecting of the device. There it would show if, and when yes what, device file is created for it.
First (as root)
dmesg -w
connect the device and watch (eventualy copy/paste) the output.
To stop the watching: Ctrl-C.
Yes, that reference to /dev/sdb is curious even considering the referenced article is an internal reader. I’m sure it should point to your device.
TSU
Hi
So the openSUSE Leap 15.1 version is 0.8.0 and the newer 0.9.x series fails to build as it needs a later systemd version…
@OP, can you try a live USB version of Tumbleweed and see if it springs into life?
Henk and TSU,
thanks for suggestions, I’m digesting the info and going through links, will report on progress.
Malcolm, I should be able the USB Tumbleweed too, perhaps during the weekend.
Oak
Hello again,
I perhaps misunderstood something, because I thought first thing is to get the driver (firmware) working, then the PAM module (that would be Display Manager dependant, isn’t it?). However, I have fprintd-pam, pam, pam-32bit, pam-config and yast2-pam installed.
No lack with common-auth (from the linked article), it doesn’t provide the pam_fprintd.so line:
**#** grep fprint /etc/pam.d/common-auth
**#**
I tried to look into configuration of PAM in YaST too, but I’m a bit lost. Is it the module called something like “Adminstration of User Login” (translated)? If so, I’m not sure, if I should configure anything there…
If a functional device is connected, shouldn’t be some related module listed in lsmod output? If so, what should I look for?
Here is dmesg -w reacting on connected fingerprint reader:[11961.403697] usb 1-4: new full-speed USB device number 6 using xhci_hcd
[11961.735898] usb 1-4: New USB device found, idVendor=27c6, idProduct=5740
[11961.735900] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[11961.735901] usb 1-4: Product: Goodix Fingerprint Device
[11961.735902] usb 1-4: Manufacturer: HTMicroelectronics
[11961.735903] usb 1-4: SerialNumber: HTK32
[11961.739518] cdc_acm 1-4:1.0: ttyACM0: USB ACM device
[11961.753790] input: HTMicroelectronics Goodix Fingerprint Device as /devices/pci0000:00/0000:00:01.3/0000:
02:00.0/usb1/1-4/1-4:1.2/0003:27C6:5740.0006/input/input18
[11961.753896] hid-generic 0003:27C6:5740.0006: input,hidraw0: USB HID v1.00 Mouse [HTMicroelectronics Goodix
Fingerprint Device ] on usb-0000:02:00.0-4/input2
In addition to that, here’s xhci lsmod output:
# lsmod | grep xhci
xhci_pci 16384 0
xhci_hcd 245760 1 xhci_pci
usbcore 286720 4 usbhid,cdc_acm,xhci_pci,xhci_hcd
As for
# udevadm info -a -n /dev/sdb | less
… that doesn’t look healthy (yep, that /dev/sdb) and is giving a non-sense output. Well, I might be doing something wrong…
Oak
I’m going to be a bit hamstrung personally for several days as I’ve had to replace my workhorse due to catastrophic hardware failure, but your dmesg output suggests to me your kernel properly identified it and has already configured a driver
Although you could also try running udevadm and point to the proper dev device, you may be able to skip that and make sure a udev rule exists for your device and is properly written. If you find a possibly improper rule, you can post for others to evaluate
TSU
Unfortunately I have no experience with udev rules. I get what the command does:
**#** udevadm info --help
udevadm info [OPTIONS] [DEVPATH|FILE]
...
-n --name=NAME Node or symlink name used for query or attribute walk.
-a --attribute-walk Print all key matches walking along the chain
of parent devices
...
…but I don’t know what device I should pass into the command. Definitely not the /dev/sdb, right? Also the /devices/pci0000:00/0000:00:01.3/0000:
02:00.0/usb1/1-4/1-4:1.2/0003:27C6:5740.0006/input/input18 is more than suspicious.udev.
I tried
**#** udevdm info -a -n /devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-4/1-4:1.2/000
3:27C6:5740.0006/input/input18 | less
…but it seems to give empty results. Probably due to a nonsense device, I entered.
Oak
Anyone please, any more idas?
Although my new machine isn’t fully up and may also need to be replaced,
Based on a quick Internet search,
You should install and try to use this tool as one attempt…
https://software.opensuse.org/package/fingerprint-gui
The tool should be more or less self-explanatory… Launch it and see if it identifies your scanner.
If it does, then enroll.
TSU
Another attempt would be to follow the steps in the following fprint ArchWiki article…
Except for installation (You would use openSUSE methods using Software Manager or zypper), the remaining configuration steps should work on openSUSE
https://wiki.archlinux.org/index.php/Fprint
TSU
Although the following StackExchange article is fairly old (2015),
You might find it useful…
Use lsusb to verify your device is recognized and how… although as I already noted it looks like the kernel did detect your scanner and assign a kernel mode driver.
Although it describes how to write a udev rule that modifies so you can login with normal Users and not just root, seems to me that just trying the rule should fix whatever problems you might have. Note that this may also be necessary even if Fingerprint-GUI appears to work at first.
And, although may not be necessary don’t ignore the link to the original tutorial the post is based on
https://unix.stackexchange.com/questions/365409/fingerprint-gui-only-working-as-root
HTH,
TSU