Detect the Latitude 9440 fingerprint reader without replacing its driver

[pelifix]

Two bugs that currently cancel each other out, so they need fixing together.

1. The reader is never detected

The Broadcom BCM58200 ControlVault 3 in the Dell Latitude 9440 2-in-1:

$ cat /sys/bus/usb/devices/3-3/{idVendor,idProduct,product}
0a5c
5843
58200

0a5c is not in fingerprint_vendors, and the descriptor is bare 58200, so it matches neither the vendor list nor *fingerprint* / *biometric* / *elan:arm-m4* / fpc *. Setup exits with "No fingerprint sensor detected" and the first-run invitation never fires, on a machine where fprintd drives the reader fine:

$ fprintd-list $USER
Fingerprints for user on Broadcom Sensors (press):

Adding 0a5c wholesale would be wrong for the reason the existing comment gives about Elan and STMicro — Broadcom also ships Bluetooth radios, hubs and ControlVault modules on machines with no reader. This adds an exact vendor:product list instead. (has_kernel_driver would not have excluded it: the interface has no driver bound.)

2. Fixing that alone would break working machines

The setup installs libfprint-git with --ask 4. The comment reads that as accepting the stock-libfprint replacement, but --ask 4 accepts any replacement.

Readers libfprint cannot drive run on a TOD stack instead — a libfprint fork plus a vendor blob:

$ pacman -Qqo /usr/lib/libfprint-2.so.2
libfprint-tod
$ pacman -Qi libfprint-tod | grep -E 'Provides|Conflicts'
Provides        : libfprint  libfprint-tod  libfprint-2.so=2-64  libfprint-2-tod.so=1-64
Conflicts With  : libfprint

libfprint-git provides libfprint, so the transaction is accepted with no prompt and removes libfprint-tod and libfprint-2-tod1-broadcom — the only driver the reader has. Fixing detection without this would have pointed the first-run invitation straight at it.

The guard checks who owns /usr/lib/libfprint-2.so.2 rather than testing package names, which differ per vendor (libfprint-2-tod1-broadcom, -goodix, -cv3plus). fprintd and usbutils are still installed; only the libfprint swap is skipped.

Verification

On the Latitude 9440:

$ omarchy-hw-fingerprint; echo $?
1          # before
0          # after

owner: libfprint-tod  => skips libfprint-git

./test/cli passes (112 ok).

One judgement call to flag: 0a5c:5843 is the ControlVault 3 module, which also does smartcard and NFC. A Dell shipping CV3 with no reader would now match and be invited to a setup that fails at enrollment. I have no such machine to test on — happy to drop the pair if you would rather wait for a narrower signal.

🤖 Generated with Claude Code

[pelifix]

Flagging the overlap with two other open PRs on this file, since we're all editing the same package block.

#11840 fixes the same class of bug at a different layer. It preserves an alternate fprintd client (fprintd-clients-git / python-validity) from being replaced by stock fprintd; this PR preserves the libfprint provider (libfprint-tod + a vendor blob) from being replaced by libfprint-git. Neither subsumes the other — #11840 still installs libfprint-git unconditionally, so it wouldn't save a TOD-driven reader, and this PR doesn't protect python-validity's client. Both are wanted; whichever lands second needs a trivial rebase, as they both introduce a package array in the same block.

#11842 is complementary rather than overlapping — it catches the case where a reader is detected but libfprint has no driver for it. Worth noting the ordering though: if #11842 lands without this one, a TOD-driven machine would install libfprint-git, lose its driver, and then hit the new fprintd-list check and be told "this exact sensor isn't supported yet". The diagnosis would be wrong, and caused by the removal that just happened. This PR is what keeps that message truthful.

Happy to rebase onto either of them, or to fold #11840's client check into this one if you'd rather have a single guard covering both layers.