[Solved] ELAN70A1 / 04f3:322d fingerprint on ASUS ExpertBook B9400CBA/B9450CBA — Fedora 44 KDE

Ask Fedora
,
1

Update — v2.0.0 / Unified v5

I have completed a much more extensive round of testing and the original
v1.0.0 procedure has now been superseded.

New users should not install or follow v1.0.0 first.

The current solution is a complete standalone Unified v5 installation:

Latest release:

Hardware

  • ASUS ExpertBook B9400CBA/B9450CBA
  • Intel Core i7-1255U
  • ACPI: ELAN70A1
  • HID VID:PID: 04f3:322d
  • Internal sensor: eFSA80SC 80x80
  • SPI: /dev/spidev0.0

Tested system

  • Fedora Linux 44 KDE
  • Kernel 7.1.8-200.fc44.x86_64
  • KDE Plasma 6.7.4
  • Wayland
  • fprintd 1.94.5-5.fc44

What changed in Unified v5

The earlier procedure used one capture configuration for enrollment and
another for normal verification.

Unified v5 now selects the capture profile automatically according to the
current libfprint action.

Enrollment:

250² = 62500

Verification / identification:

175² = 30625

Matcher:

SIGFM

SIGFM threshold:

100

Therefore a new user only needs one Unified v5 patch and one build.
The previous v3-enrollment → v4-runtime sequence is no longer required.

Final fingerprint benchmark

Genuine right index:

  • 19/20 matches
  • 1/20 false reject
  • 0 timeouts
  • minimum: 717 ms
  • median: 964 ms
  • mean: 1296.2 ms
  • maximum: 3076 ms

Wrong-finger left index:

  • 0/20 observed false accepts
  • 20/20 correct rejections
  • 0 timeouts
  • median: 983.5 ms

The one failed genuine attempt reached SIGFM scores close to the threshold
(including 96/100), but I intentionally did not lower the matcher threshold.
The current genuine reliability is already strong, and 20 impostor attempts
are not enough evidence to justify weakening an authentication threshold.

0/20 false accepts means no false accept was observed in this test set.
It does not prove a mathematically zero FAR.

Real Fedora/KDE authentication tests

The final Unified v5 setup was tested successfully with:

  • fprintd-verify
  • sudo
  • KDE Plasma lock screen
  • Plasma Login Manager
  • logout/login
  • full reboot persistence

In the final functional test, sudo, KDE lock-screen unlock, login after
logout, and login after reboot all succeeded on the first swipe.

Important additional finding: SPI PIO caused severe desktop stutter

During fingerprint testing I discovered a second, independent problem.

When fingerprint capture was active, the laptop could experience severe
mouse/KWin/system stutter.

One CPU core was measured at approximately 97-99% hard IRQ processing.

The kernel boot log contained:

pxa2xx-spi pxa2xx-spi.4: no DMA channels available, using PIO

The Intel idma64 DMA controller was becoming available later in the boot
process, after the SPI controller had already fallen back to PIO.

The tested fix is to force idma64 into the initramfs early:

/etc/dracut.conf.d/20-idma64-early.conf

with:

force_drivers+=" idma64 "

then rebuild the initramfs and reboot.

After this change:

  • SPI DMA channels were active
  • the previous 97-99% hard-IRQ saturation disappeared
  • repeated fingerprint tests while moving the mouse/touchpad produced no
    observed stutter or tearing

This issue was independent of SIGFM itself.

Remaining known issue

There is still one reproducible post-enrollment teardown/state-machine issue.

Enrollment completes and the fingerprint template is successfully saved,
but immediately afterward the same fprintd session can produce messages such as:

  • Deactivating image device while it is not idle
  • current_action != FPI_DEVICE_ACTION_NONE
  • Error invoking ioctl for SPI transfer (9)
  • Driver reported session error, but device is inactive

The tested workaround is simply:

sudo systemctl restart fprintd.service

once after enrollment.

Normal daily authentication is stable after that restart.

AI-assisted development disclosure

The diagnostic workflow, hypothesis testing, kernel/SPI/IRQ log analysis,
Unified v5 design, benchmark planning, and technical documentation were
developed interactively with OpenAI ChatGPT, model GPT-5.6 Sol.

All kernel logs, fingerprint enrollments, benchmark results, sudo tests,
KDE tests, login tests, and reboot tests were produced on the physical
ASUS ExpertBook.

The AI did not simulate the hardware results and did not directly control
the laptop.

Current recommendation

If you have the exact same hardware:

  • ELAN70A1
  • 04f3:322d
  • eFSA80SC

start directly with the current README / v2.0.0 procedure.

Do not follow the old v1.0.0 procedure first.

Repository:

Latest release:

3

additional post to be able to mark a solution for the OP

4

Final solution — v2.0.0 / Unified v5

The original v1 procedure has now been superseded.

The final tested solution is v2.0.0 / Unified v5, which is a complete
standalone installation path. New users do not need to install or follow
v1.0.0 first.

Main improvements:

  • Single Unified v5 patch
  • SIGFM threshold: 100
  • Enrollment frame threshold: 62500 (250²)
  • Verification/identify threshold: 30625 (175²)
  • 19/20 genuine matches in the final benchmark
  • 0/20 observed false accepts
  • 0 timeouts
  • sudo: working
  • KDE lock screen: working
  • Plasma Login Manager: working
  • login after full reboot: working
  • SPI PIO / hard-IRQ stutter fixed by early idma64 loading
  • remaining post-enrollment teardown issue documented with a tested
    fprintd restart workaround

Full standalone installation guide:

Latest release:

This is the solution I recommend for the exact hardware:

ELAN70A1 / 04f3:322d / eFSA80SC