1.0.0 is out, and it needs testing on other machines

[kpagnussat]

1.0.0 is out: https://github.com/kpagnussat/canvasbio-cb2000/releases/tag/v1.0.0

A libfprint TOD module for the CanvasBio CB2000, 2df0:0003, the reader in the power button of the Samsung Galaxy Book2 360 and Book3 360.

What it is

The package is libfprint-2-tod1-canvasbio-cb2000. It installs next to your distribution's libfprint instead of replacing it, so other fingerprint readers keep working and a distribution upgrade does not fight it. Plain C with GLib. One .so, a changelog and a copyright file, nothing else.

An 80x64 frame gives libfprint's own minutiae matcher too little to work with, so the driver brings its own. Enrollment fuses 15 counted touches into one template and asks you to move your finger when a touch adds too little new area.

This is a first release and not an upgrade of the R2.5 snapshot. That one shipped libfprint-2-2 version 1:1.94.10+canvasbio.202604201514, which replaced the system libfprint with a build that had the driver compiled inside. If you installed it, put your distribution's library back before installing 1.0.0: the names differ, so apt does not treat this as an upgrade, and the old build does not load TOD modules at all, so installing on top of it does nothing and reports nothing. The README opens with the commands. Prints enrolled with R2.5 have to be enrolled again, because the template format changed.

What is tested, and what is not

All four packages, against the sensor, on one Galaxy Book3 360. The .deb for Ubuntu 26.04 is the one every accuracy figure was measured with.

The openSUSE and Fedora .rpm and the Arch PKGBUILD were each installed from the release page, with the command the README gives, on the live image of their own distribution (Fedora with SELinux enforcing), and through fprintd each one enrolled a finger, accepted it 5 times out of 5, refused a finger that was not enrolled 5 times out of 5, and survived a cancelled verify. That shows the package works end to end on its distribution; it is not a second accuracy figure. Fedora still needs a libfprint with TOD from a third party repository and an SELinux policy, and on Fedora and Arch that library takes the place of the system one. Fedora 43 and the Arch derivatives have not been tried.

The same capture question was answered by measurement: across three sessions the sensor was handed in turn to the vendor's Windows driver and to this one, with the host recording the USB traffic of both, and replayed through the same engine the two come out level. Against the template built from Windows touches, the frames this driver read score 60 of 60 and the vendor driver's own score 58 of 60. docs/RESEARCH.md has the tables.

What this project needs

Every accuracy figure in the README comes from one person's fingers, one laptop, one sensor unit. That is a ceiling no further work on my side can lift.

There is a way to try the reader that installs nothing:

git clone https://github.com/kpagnussat/canvasbio-cb2000
cd canvasbio-cb2000
sudo sh -c 'systemctl stop fprintd; exec tests/device/run.sh'

It builds a throwaway container, enrolls a finger and ends with two counts: how often your enrolled finger was accepted, and how often a finger that was never enrolled was. --detect-only stops after finding the reader and sends nothing to it. No image leaves the container.

Those two counts from another machine, or from another person's fingers, are worth more here than anything else. A report that it simply works is as useful as one that it does not, especially on a Galaxy Book model the README does not list, or on a distribution or release the README does not list as tested.

Post results in this thread. Bugs belong in issues, with your distribution, the package version, and the output of fprintd-verify under G_MESSAGES_DEBUG=all.

Before you rely on it

The capture area is about 6 x 5 mm, and neither this driver nor the vendor's Windows one has any liveness or fake finger detection, because there is none in the hardware to use. Treat the reader as a convenience unlock, not as strong authentication. The README's Known limitations says why, with the references.

Looking for the 2df0:0007, the sensor in the Galaxy Book5 360?

It's deliberately not bound here. It is a Realtek match-on-chip part with a different protocol, and it is being worked on against libfprint's own realtek driver, which is where it belongs. That work is tracked in linux-fingerprint-drivers#17, which is the place to go if you have one.

[kpagnussat]

1.0.1 is out: https://github.com/kpagnussat/canvasbio-cb2000/releases/tag/v1.0.1

A small maintenance release. The driver now files the sensor's coverage and interrupt replies by a tag on the command table instead of by sequence name, so a later change to the tables cannot switch the coverage check off without anyone noticing. Nothing changes on the wire, in matching or in the print format, and fingers enrolled with 1.0.0 keep working.

It was tested on the sensor with the device test.

[frank-w]

this the result of my test (ubuntu 26.4, galaxy book 3 360):

CanvasBio CB2000 self test, driver 1.0.1+75d85ec

Found CanvasBio CB2000, driver canvasbio-cb2000
The reader was found and opened.

Enrollment: 15 touches with one finger.
Press the sensor, lift, press again, shifting the finger a little
each time so the template covers more of the fingertip.
Press Enter when you are ready. 
Touch the sensor.
  [ 1/15] ok
  [ 2/15] ok
  [ 3/15] ok
  [ 4/15] ok
  [ 5/15] ok
  [ 6/15] ok
  [ 7/15] ok
  [ 8/15] ok
  [ 8/15] Move the finger to place another part of it on the sensor.
  [ 9/15] ok
  [10/15] ok
  [10/15] Please try again.
  [11/15] ok
  [12/15] ok
  [13/15] ok
  [14/15] ok
  [15/15] ok
Enrolled, 17 touches in total.

Same finger, 5 attempts.
  [1/5] touch the sensor
      accepted
  [2/5] touch the sensor
      accepted
  [3/5] touch the sensor
      accepted
  [4/5] touch the sensor
      accepted
  [5/5] touch the sensor
      accepted

Now a finger you did not enroll, 5 attempts.
Any other finger, on either hand. Every one of these should
be refused.
Press Enter when you have changed finger. 
  [1/5] touch the sensor
      refused
  [2/5] touch the sensor
      refused
  [3/5] touch the sensor
      refused
  [4/5] touch the sensor
      refused
  [5/5] touch the sensor
  Please try again.
      refused

Result

  driver         1.0.1+75d85ec
  enrollment     completed in 17 touches
  same finger    5 of 5 accepted
  other finger   0 of 5 accepted

These four lines are the whole result and carry nothing about
your fingers. The template stayed in memory and is gone now.

i hope this is what you need ;) as far as i understand the output it works as expected, thanks for your work. i install the package now and look if i can configure it from controlpanel and use it as quick-auth (my intention to not allow spying my password when outside)

works like a charm, thank you very much!

[kpagnussat]

Good idea, done: the README now explains them under Try it without installing.

They come from the driver, not from fprintd: it asks libfprint for another touch, and the text is what GNOME's fingerprint settings show too. So yes, they are requests for another touch, not errors. The "move the finger" one follows the vendor's Windows driver, which asks for it at the same points during enrollment, so a user coming from Windows sees the same prompt.

[frank-w]

just small other thing,
i did not see pipeline-config for the release. I guess you have you manually and uploaded its output to a release.
imho pipeline also increases trust and make build-steps clean (have not seen new build-steps in readme).

it is clear that pipeline also is much work, and i do not want to give you more tasks :) just a thought

[kpagnussat]

Good point, and thanks for raising it. You are right that there is no pipeline yet: the packages were built locally, each in its own pinned container, and uploaded by hand.

Until there is one, the honest answer to "why trust these packages" is that you do not have to. The build and release steps are in docs/DEVELOPMENT.md (Build and Release), the same scripts that produced the release, and anyone who would rather not install a package built on someone else's machine is welcome to build their own from the tagged commit. I would not blame anyone for it. The source tarball is reproducible too, so building it again gives the same bytes as the one attached, and its sha256 can be checked against the release notes.

A release pipeline is noted for a later release, so the packages come from CI with a provenance attestation instead of from my machine.

[frank-w]

thanks somehow overseen the doc folder, sorry

do you plan to upstream your changes to libfprint?

[kpagnussat]

No need to apologise, it is easy to miss.

Yes, upstream libfprint is where this should end up, and the driver is already written with that in mind: packaging/in-tree/ carries it as a patch against a pinned libfprint tag. There are two things to get through first.

The first is the matcher. An image driver in libfprint normally captures and leaves matching to the framework, which uses NBIS, the NIST minutiae matcher. An 80x64 frame, about 6 x 5 mm of fingertip, gives NBIS too few minutiae to work with, so this driver carries its own matcher: plain C with GLib, written for this project, following the behaviour of the vendor's Windows engine. That is unusual for an upstream driver, and whether libfprint wants a driver-side matcher, or a way to plug one in, is a conversation to have with the maintainers before any merge request.

The second is evidence. A new driver is a lot to ask the maintainers to take on, and every figure so far comes from one person and one laptop. What would make the case is exactly what you just did: people with a 2df0:0003 using it day to day and reporting how it goes, on more laptops and more fingers. With enough of that, it is a merge request worth opening.

[kpagnussat]

1.0.2 is out: https://github.com/kpagnussat/canvasbio-cb2000/releases/tag/v1.0.2

@frank-w, your pipeline suggestion is in: this is the first release built by GitHub Actions instead of on my machine. The tag started the workflow, which ran the same build scripts with the tests and attached the files, and each one carries a build provenance attestation you can check yourself:

gh attestation verify libfprint-2-tod1-canvasbio-cb2000_1.0.2_amd64.deb --repo kpagnussat/canvasbio-cb2000

The source tarball it built is byte for byte the one built locally from the same commit.

The rest is maintenance: a damaged stored print is now reported as damaged instead of as a finger that does not match, one distance read from the print file is computed in 64 bits, and the tests run in every package build. Nothing changes for a working setup, and enrolled fingers keep working.

A note on why so much lands at once: development happens in a private repository, and this one only receives tested snapshots, one commit per release. So changes arrive in batches rather than commit by commit, and nothing is tagged until it has passed the offline tests and the device test on the sensor. The notes of each release say exactly what was run on it and what was not.