Synaptics 06cb:009b responds to the protocol but reports RomInfo.product=0x33 (not 0x30)

[granman3]

Summary

06cb:009b (MSI Creator 15 A10SET) is not in SupportedDevices, and as far as I can tell it has never been characterised publicly — the libfprint supported list starts at 06cb:00bd, and the pending native-Validity MR covers 009a but not 009b.

I ran a read-only probe and found that the device does answer the protocol: cmd 01 (RomInfo.get) returns status 0x0000 with a well-formed 38-byte response. It appears to be the same protocol family as 06cb:009a, but a different sensor generation — it reports product = 0x33, where the code assumes 0x30.

Filing this mainly to put the ROM signature on record, and to ask what would be needed to go further.

Hardware

ID 06cb:009b Synaptics, Inc.
bcdDevice 0x0154 · USB 2.0 full-speed · bMaxPower 100mA · 1 configuration
Interface 0: bInterfaceClass 0xff (vendor-specific), 5 endpoints
  EP 0x01  Bulk       OUT   64 B
  EP 0x81  Bulk       IN    64 B
  EP 0x82  Bulk       IN    64 B
  EP 0x83  Interrupt  IN     8 B
  EP 0x84  Interrupt  IN    16 B
No kernel driver bound to the interface.

Laptop: MSI Creator 15 A10SET. The same ID has been reported on the MSI GS66, so it looks like an MSI-favoured part.

What I did

Rather than run open(), I replicated only the first two reads from usb.py:send_init() with pyusb, and deliberately stopped before init_hardcoded — nothing was written, no firmware uploaded, no pairing attempted. The sensor still enumerates normally afterwards.

Results

cmd 01 — RomInfo.get() → status 0x0000

000010b604549a00000006140133000100009435490060840021000000000100000000000006

Decoded with unpack('<LLBBxBxxxB', rsp[0:0x10]):

Field	Value
timestamp	1409594896 → 2014-09-01 18:08:16 UTC
build	154 (consistent with bcdDevice 0x0154)
major	6
minor	20
product	0x33
u1	0

cmd 4302 — get_fw_info() → status 0x04af

Non-zero, but this is the branch usb.py:94 already handles as "fwext is not loaded / Clean slate". This machine has never run the Windows driver (Linux-only disk, no Windows partition), so an empty fwext partition is expected — I don't read this as a failure.

Where it stops

Two places assume hardware this sensor isn't:

1. sensor.py:607 — build_cmd_02():

   if self.rom_info.product != 0x30:
       raise Exception('Not implemented')

   This device reports 0x33.

2. table_types.py:65 — SensorCaptureProg.get() filters the 418-entry dev_info_table on rominfo.major, and I don't see an entry covering this combination.

So the command/transport layer looks compatible, but the capture programs for product = 0x33 don't exist in any table I can find — which is the part that can't be inferred without traffic from a working driver.

Environment

• Arch Linux, kernel 7.1.9
• libfprint 1.94.100, fprintd 1.94.5 — fprintd-list reports "No devices available"
• python-validity at a6bbc21 (master, 2025-06-10), pyusb 1.3.1

Questions

1. Is product = 0x33 a known variant? Does it correspond to a sensor generation you've seen, or is this new?
2. Is the != 0x30 guard a hard architectural limit, or a "nobody has tested otherwise" placeholder?
3. If I capture the Windows driver's initialization over USB (Windows VM with the sensor passed through, usbmon on the host), would that traffic be the right input to derive the 0x33 capture programs — and is there a preferred capture format?

Happy to run further read-only probes or produce captures if that's useful. I'd rather not attempt firmware upload or pairing blind without some indication it won't brick the sensor.