| Summary: | Change behavior of fingerprint enrollment from "swiping" to "tap" | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Pankaj Kumar <ipankaj.singh10+kde> |
| Component: | kcm_users | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | major | CC: | me, null, uhhadd |
| Priority: | NOR | ||
| Version First Reported In: | 5.24.5 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Pankaj Kumar
2022-06-01 08:01:47 UTC
Hi, please include in the bug report the exact hardware models and firmware that you have problems with. I personally tried Fedora 36 on a modern Thinkpad laptop few days ago, and I didn't experience any problems with that hardware. (In reply to ratijas from comment #1) > Hi, please include in the bug report the exact hardware models and firmware > that you have problems with. > > I personally tried Fedora 36 on a modern Thinkpad laptop few days ago, and I > didn't experience any problems with that hardware. The exact hardware model of my sensor is not reported in KDE, but the enrollment happens what I am more concerend about is why swipe on a modern sensor ? We literally have like 1*1 cm sensor everywhere now > what I am more concerend about is why swipe on a modern sensor ? We literally have like 1*1 cm sensor everywhere now Please don't speak for everyone. As I said, I don't have any sensor at all on my laptop, but I was able to test it on my girlfriend's Thinkpad — and it worked just about right. Not everyone has the same hardware. Which is why… > The exact hardware model of my sensor is not reported in KDE, but the enrollment happens Please find out which exact model do you have, so we can work on a specific particular problem (if possible). You can find that out with various utilities like `lsusb`, `usb-devices`, `lspci`, KDE Info Center or even simply in `dmesg` logs. KDE is simply using fprint to handle the actual hardware, so you might want to check out its documentation too; the Arch Linux wiki would be a good starting point: https://wiki.archlinux.org/title/Fprint (In reply to ratijas from comment #3) > > what I am more concerend about is why swipe on a modern sensor ? We literally have like 1*1 cm sensor everywhere now > > Please don't speak for everyone. As I said, I don't have any sensor at all > on my laptop, but I was able to test it on my girlfriend's Thinkpad — and it > worked just about right. Not everyone has the same hardware. Which is why… > > > The exact hardware model of my sensor is not reported in KDE, but the enrollment happens > > Please find out which exact model do you have, so we can work on a specific > particular problem (if possible). You can find that out with various > utilities like `lsusb`, `usb-devices`, `lspci`, KDE Info Center or even > simply in `dmesg` logs. KDE is simply using fprint to handle the actual > hardware, so you might want to check out its documentation too; the Arch > Linux wiki would be a good starting point: > https://wiki.archlinux.org/title/Fprint `lsusb`, `usb-devices`, `lspci , none of these commands show my integreated fp sensor. Still I am able to enroll my fingerprint, just not able to use it afterwards Are you able to set it up via fprint command line "frontend"? As I was investigating implementation of fprint, I found that it is actually a enum of two variants.
/**
* FpScanType:
* @FP_SCAN_TYPE_SWIPE: Sensor requires swiping the finger.
* @FP_SCAN_TYPE_PRESS: Sensor requires placing/pressing down the finger.
*/
typedef enum {
FP_SCAN_TYPE_SWIPE,
FP_SCAN_TYPE_PRESS,
} FpScanType;
This scan type is proxy-passed via D-Bus to the users / enrollment KCM (system settings module), and used in the label accordingly:
kde/workspace/plasma-workspace/kcms/users/package/contents/ui/FingerprintDialog.qml:137:
text: i18nc("%1 is a type of operation (e.g. 'scan') and %2 is the name of a finger", "Please repeatedly %1 your %2 on the fingerprint sensor.", fingerprintModel.scanType, fingerprintRoot.currentFinger.toLowerCase())
So if you really believe that the wrong action is suggested for your device, then it's worth looking into its libfprint driver first. And for that you need to find out the exact model you have :)
You can then file a bug report at libfprint project here: https://gitlab.freedesktop.org/libfprint/libfprint/-/issues
|