CanvasBio CB2000 2df0:0007 – activation stalls on first REQ_INIT command

[pleconte422]

USB ID / entry

2df0:0007

Outcome

Builds but does not enroll or verify

Distro, libfprint and fprintd versions

Kubuntu 26.04

Hardware

Galaxy Book5 360

What happened

Hardware:

• Samsung laptop
• Fingerprint reader: CanvasBio CB2000
• USB ID: 2df0:0007

System:

• Kubuntu 26.04
• Kernel: 7.0.0-31-generic
• libfprint system package: 1:1.95.1+tod1-0ubuntu2
• fprintd: 1.94.5
• tested against current upstream libfprint:
  v1.94.100-10-g6f9479c3

USB descriptors:
Interface 0, Vendor Specific
Endpoints:

• 0x01 OUT, Bulk, 512 bytes
• 0x82 IN, Bulk, 512 bytes
• 0x83 IN, Interrupt, 16 bytes
• 0x84 IN, Interrupt, 16 bytes

The experimental canvasbio_cb2000 driver builds successfully and
detects the device:

Selected device 0 (CanvasBio CB2000) claimed by canvasbio-cb2000 driver
Opening CanvasBio CB2000 device
Device opened successfully

However enrollment fails immediately during activation.

The first command is:

[activation_wake] cmd 1/10 CTRL_OUT req=0xdb value=0x0001 index=1

and the device returns:

Command transfer failed: endpoint stalled or request not supported

The driver then enters an endless recovery / USB reset / re-init loop.

I also tested changing wIndex from 1 to 0 for this first REQ_INIT
command. The result is identical: the device stalls immediately.

So the issue does not appear to be the bulk endpoint configuration.
The failure occurs on the first vendor-specific control request during
the WAKE_SEQ.

The device otherwise opens successfully with libusb/libfprint.

I can provide full G_MESSAGES_DEBUG logs or USB captures if useful.

lsusb:
2df0:0007 CanvasBio CanvasBio CB2000

Logs

[jedbillyb]

Thanks for the detail, especially for testing wIndex both ways. That saved a round trip.

I think the problem is upstream of everything you tried. Every CanvasBio CB2000 driver I can find in the wild targets 2df0:0003, the sensor in the Galaxy Book 3 360. Yours is 2df0:0007, and those are not the same part. Per the reverse-engineering notes in myso-kr/samsung-galaxy-book-fingerprint-sensor-device-730b, 2df0:0007 is match-on-chip with SDCP and TLS, off a Realtek UMDF driver, whereas the :0003 generation uses the much simpler host-side matching protocol.

That fits your symptom exactly. A sensor expecting a secured session will reject a bare vendor control request straight away, which is the stall you see on command 1 of 10, and it explains why changing wIndex made no difference: the value isn't what the firmware is objecting to. There is no combination of tweaks to that wake sequence that reaches a working device, because the sequence is written for different firmware.

For the record, there is no libfprint merge request for 2df0 at all, in any state, so there is no upstream effort to join yet either.

Two things would genuinely help, if you are up for it:

1. Which driver is this, exactly? A link to the source you built. If it is one of the :0003 repos then the above is confirmed outright. If it is something generated rather than reverse-engineered, that is also worth knowing, because a plausible-looking wake sequence that no hardware has ever acknowledged would produce precisely this failure.
2. A Windows-side USB capture. This is the valuable one. A usbmon or Wireshark trace of your Linux driver failing only re-confirms the stall, but a capture of the Windows vendor driver initialising the sensor contains the real sequence, which is currently the missing piece. If SDCP and TLS are involved you will see a handshake rather than a short burst of control requests, and that alone would settle it.

The Linux G_MESSAGES_DEBUG logs you offered I would skip. The issue text already has the part that matters.

Fair warning on scale: if this really is an SDCP/TLS match-on-chip sensor, supporting it means implementing that session layer, which is the same shape of problem as the Synaptics Tudor work and not a small patch. I am leaving this open as the tracking issue for 2df0:0007 either way, since the ID is not even on libfprint's unsupported-devices wiki list and it should at least be findable.