Why don’t you use Ask Fedora? I think you can find more people to answer for your question there.
Hi folks, I’m struggling to get the fingerprint reader working on Fedora 34. I got all hardware working 100% on Ubuntu 21.04 yesterday, but decided to switch to Fedora 34 due to the much better trackpad gesture support (3-finger desktop switching was a must for me!).
As recommended, I installed from the latest respin of Fedora 34. I’ve got libfprint-1.90.7-3.fc34.x86_64 installed, but every time I try to enroll a fingerprint, I immediately get an error and it gives up. Some reading on fprintd suggests this is usually a driver error. Here’s what the error looks like:
[sawaba@fedora ~]$ fprintd-enroll
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
Enroll result: enroll-unknown-error
Is that the right device?
I can’t find anything in /var/log that gives any more details and all my Googling hasn’t revealed anything useful. I also tried pulling from the Fedora 35 repo, but it just gives me the same version of libfprint that seems to be working for everyone else…
1 Like
There is Ubuntu thread, and others, suggesting that libfprint must be version 1.92 1 for the fingerprint sensor to work.
I haven’t managed to get a successful compile yet, always some package not found.
@Edward_Gray you shouldn’t need to compile, you can just install from rawhide: Community reviews - #9 by Michael_Lingelbach
1 Like
I’m currently running Fedora 34 on my Framework and fprintd worked out of the box.
Here is further information, if curious:
CPU: Quad Core 11th Gen Intel Core i7-1185G7 (-MT MCP-) speed/min/max: 1242/400/4800 MHz Kernel: 5.13.7-200.fc34.x86_64 x86_64
Up: 55m Mem: 4624.4/31880.5 MiB (14.5%) Storage: 3.64 TiB (19.4% used) Procs: 347 Shell: Zsh inxi: 3.3.06
It is suggested above to follow the procedure for Ubuntu (Ubuntu 21.04 on the Framework Laptop - #8 by jeshikat), but that says to run the command sudo update-grub, which doesn’t seem to exist in Fedora. This page, Equivalent of update-grub for RHEL/Fedora/CentOS systems? - Unix & Linux Stack Exchange, has an answer that says that the Fedora 33 guide says to run sudo grub2-mkconfig --output=/boot/grub2/grub.cfg. Does that seem right for Fedora 34? The current guide GRUB 2 - Fedora Project Wiki seems to confirm this, but I’m still a little confused.
And now that I look at that page more, I wonder if the correct advice might be to use grubby, per GRUB 2 - Fedora Project Wiki. However, looking at the grubby man page leaves me as confused as ever. Not being intimately familiar with the various parts of the Grub2 subsystem, I’m not clear what options in grubby would accomplish changing the setting.
I finally did the following, and it seems to have worked, as shown:
Before configuring /etc/default/grub to enable deep sleep:
[jeremy@fedora ~]$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
[jeremy@fedora ~]$
After configuring /etc/default/grub to enable deep sleep::
[jeremy@fedora ~]$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet mem_sleep_default=deep"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
[jeremy@fedora ~]$
Running the script to invoke the grub incantation:
[root@fwfedora ~]# cat /sys/power/mem_sleep
[s2idle] deep
[root@fwfedora ~]# cat doit.sh
grub2-mkconfig -o /etc/grub2.cfg
grub2-mkconfig -o /etc/grub2-efi.cfg
[root@fwfedora ~]# . doit.sh
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done
[root@fwfedora ~]# ls -l /etc/grub2.cfg /etc/grub2-efi.cfg
lrwxrwxrwx. 1 root root 22 Jun 15 11:41 /etc/grub2.cfg -> ../boot/grub2/grub.cfg
lrwxrwxrwx. 1 root root 22 Jun 15 11:41 /etc/grub2-efi.cfg -> ../boot/grub2/grub.cfg
[root@fwfedora ~]# diff /etc/grub2.cfg /etc/grub2-efi.cfg
[root@fwfedora ~]#
(reboot)
[root@fwfedora ~]# cat /sys/power/mem_sleep
s2idle [deep]
[root@fwfedora ~]#
6 Likes
@Jeremy_Schneider before you dive too deep into grub, if you haven’t checked to see whether you need to, you can run this command:
cat /sys/power/mem_sleep
If the result is [s2idle] deep, you don’t need to mess with grub to enable deep sleep, it’s already enabled.
I was deep into troubleshooting on my Fedora 34 system before realizing it was already enabled for me. Also worth mentioning - I installed Fedora 34 using the respin from August 2nd, which reportedly already had a lot of this stuff fixed.
2 Likes
@Alex_S The only difference here is that I’ve got the i7 chip just below yours - the i7-1165G7. I can’t imagine how that would make a difference though - the fingerprint reader isn’t part of the Intel chipset…
@Adrian_Sanabria Thank you. It is indeed already set. I used to be very grub-literate in my Gentoo days ;-).
[jeremy@fwfedora ~]$ cat /sys/power/mem_sleep
[s2idle] deep
[jeremy@fwfedora ~]$
Oh, by the way, I also installed from a respin – maybe that’s why I have it.
My battery seems to drain unreasonably fast when the machine is asleep – not like my Google Pixelbook – I can close it and return days later to a machine at practically the same charge level.
I’m looking forward to enhancements in the access to the firmware charging limits and other battery-related customizations.
@Jeremy_Schneider Same! I remember the days when I had the time and patience to do Stage 1 Gentoo installs 
Yes, one of the main reason to use the Fedora respins is that the Framework folks got them to include some of these fixes!
And I’m sure they’ll get us some good firmware updates that fix some of these issues, though overall, I’m pretty happy.
The output is saying that it’s not set. You want “deep” to be selected. But s2idle is.
1 Like
@Andrew_Gallant Thank you for that information! I saw the word “deep”, and was ignorant of the syntax…
@Adrian_Sanabria I am actually having the same problem. Regardless of what version I use, it seems to (sometimes) pass the first enroll stage but then quit with that same error. Journalctl says fprintd[11235]: Device reported an error during enroll: Finger is too similar to another, try use a different finger. According to fprintd, there are no enrolled fingerprints though…
The weird thing is that Gnome showed the fingerprint option when I first installed Fedora, but after running dnf upgrade it no longer does.
Update: After correctly setting the sleep mode as described in my post above, starting with 100% battery charge and closing the laptop, 10 hours later the charge was reported as 90%. That’s a big improvement over my initial observations.
4 Likes
Good news. The new libinput RPM package 1.18.1 to fix the Framework touchpad issue is available on Fedora 35. On Fedora 34, the libinput 1.18.1 RPM package is currently in testing status. It will be released around 1 week later. To install it earlier on Fedora 34, you can check this testing page. I also updated this thread’s wiki.
2 Likes
@Adrian_Sanabria @waocats I had similar errors after installing Windows to debug the trackpad issue. I was able to work around it by enabling the fingerprint login in Gnome (although I couldn’t enroll a fingerprint), then disabling fingerprint login and then reenabling it again. My guess is that since the fingerprint reader is a match on device chip there might have been some logic that needed to get reset after reinstalling an operating system. You might give that a try and see if that resolves your error.
Can anyone chime in on how long it takes their laptop to resume from S3/deep suspend?
For me on Fedora 34, kernel 5.13.8-200.fc34.x86_64:
Suspend: almost instant
Resume: around 13-15 seconds to resume (from S3/deep). This seems somewhat slow, is this in line with how long it should take?
I looked through some diagnostics with
https://github.com/intel/pm-graph and looked at dmesg/journal, but couldn’t find any culprits (yet), but I may be reading them incorrectly.
Semi side-note:
Fedora’s S2Idle resume is instant, but I think it’s using S1 sleep state. Tested in Windows and it’s instant also, but the modern standby feature I believe uses S0ix, not S1.
Linux should be able to S2Idle using S0ix to achieve discharge rates similar to Windows modern standby, if I’m gathering my info correctly, but support/implementation seems shoddy all around, and doesn’t seem to be working correctly on Framework yet (F34, 5.13), due the seemingly high discharge rates.
Saw that 5.14/5.15 are supposed to help, at least with AMD chips. Further insight would be appreciated!
2 Likes
I don’t have my Framework laptop yet, but resuming from deep suspend should be nearly instant. It might take another few seconds for WiFi to connect, but 13-15 seconds is definitely not normal. Or at least, shouldn’t be considered acceptable.
When I’ve had problems in the past, pm-graph is what has bailed me out. If that isn’t working for you, then I’m not quite sure where to go from there.
Here’s a guide from Intel that talks about debugging steps: http://web.archive.org/web/20210302014224/https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
1 Like
After more regular use of Fedora on my laptop, I can safely say that around 80% of battery charge my laptop cpu usage increases to about 30% and the entire experience becomes significantly slower. Has anybody else encountered this issue?
Thanks for the link! I did some more digging/reading, and then realized I overlooked the portion between Kernel Suspend Time and Kernel Resume Time – I ran:
sudo ./sleepgraph.py -m mem -rtcwake 15 -mindev 1 -dev
The -rtcwake 15 option wakes the laptop 15 seconds after suspend.
In the image below, both Kernel Suspend Time and Kernel Resume Time look fine, but I noticed the center mem time is ~26 seconds. Mousing over mem time, it says it’s the time spent in low-power mode with the clock running, of which I assume is just the total time spent suspended in memory.
So 26 seconds spent in memory means that, with the 15 second delay until the rtcwake signal, 11 seconds is spent in, I’m assuming, the firmware? until the kernel resumes.
(26 seconds mem time - 15 seconds until rtcwake = 11 seconds after rtcwake signal)
11 seconds plus the 1.2 seconds in Kernel Resume Time equals 12.2 seconds total to resume from S3/deep suspend. This matches about how long it takes to resume after a suspend, when I press the power button.
Note that when I run analyze-suspend.py, I get
WARNING: /dev/mem is not readable, ignoring DMI data
and
sleep-graph.py/sleepgraph, I get
WARNING: /dev/mem is not readable, ignoring the FPDT data
I did some Googling, and FPDT is the Firmware Performance Data table, and since it can’t be read with pm-graph (or at least I don’t know how), I can’t figure out why exactly it’s spending ~10seconds in the firmware on resume from suspend.
Is there a way to see a breakdown of what’s happening within mem time?
Also, seems some support was added in Kernel 5.12:
With Linux 5.12+ the ACPI FPDT table is being parsed on supported systems and exposed under /sys/firmware/acpi/fpdt/ .
Poking around,
> cat /sys/firmware/acpi/fpdt/resume/resume_avg_ns
> 12643760622
12643760622 nanoseconds ~= 12.649427013 seconds, matching the explanation above.
I’ve also tested:
- 5.14.0-0.rc4 rawhide kernel (same issue, and ran into some other oddities, probably cause rawhide haha)
- the latest Fedora Spin (F34-WORK-x86_64-LIVE-20210802.iso) booted from a USB stick, which resumed slightly slower probably running off USB.
Apologies in advance for the debug dump @Andrew_Gallant 
, but also some info directed to other Fedora/Linux/S3 suspend users/Framework!
Doesn’t happen on my end, have you checked what’s consuming that CPU usage via e.g. top, or perhaps if your clock speeds/frequencies lower (e.g. due to some power saving profile), increasing CPU usage? Difference between plugged in and on battery? Lots of unknowns here
1 Like