Add support for Chipsailing 2541:2549

[ifeign]

Would it be possible to add support for the Chipsailing sensor with hwid 2541:2549? I've tried simply adding it to the driver in my own fork, and while it did show up when i ran fprintd-enroll, it wasn't actually functional.

Is there any information I can gather from my fingerprint reader that can help get it working?

I did find this Ubuntu driver for the fingerprint reader, but I am on Arch. Currently seeing if the .so files contained are of any use: https://en.ab2cd.com/Download.aspx?ClassID=27

I've uploaded the .so files for your convenience. They were pulled from the v22.04.deb file
2549-so-files.zip

[ifeign]

I found a slightly newer version of the driver (1.0.3) on the Chinese version of the website (ironically still in English): http://www.ab2cd.com/download.html

Uploaded the .so files from this one too, this time from the Ubuntu 24.04 deb

1.0.3-so-files.zip

[archeYR]

Looking briefly at disassembly it seems to use a different image resolution (112x88, probably still would work best with sigfm algorithm, but driver code needs to be adapted). The protocol is not clear to me, I think it would be easiest to debug the CS9711 driver on it and see where errors/deviations start to happen.

I did find this Ubuntu driver for the fingerprint reader, but I am on Arch. Currently seeing if the .so files contained are of any use

I know that would be far from ideal, but you can also create an AUR package that installs those files.

[ifeign]

I have attempted to create my own pkgbuild for this driver, but because I'm far from an expert I couldn't get it to work. I'll take another stab at it.

As for debugging the CS9711 driver, what information can I provide to you that could help?

I forgot to share the error from my fork of your repo where I simply added the HWID:

journalctl -f -u fprintd
Feb 11 15:47:17 GamingPCLinux fprintd[4800]: Device reported an error during identify for enroll: Init: expected 8 bytes but got 72 
Feb 11 15:47:20 GamingPCLinux fprintd[4800]: Got different state response than expected, continuing anyway
Feb 11 15:47:34 GamingPCLinux fprintd[4800]: libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know
Feb 11 15:47:34 GamingPCLinux fprintd[4800]: libusb: error [do_close] A cancellation hasn't even been scheduled on the transfer for which the device is closing
Feb 11 15:48:17 GamingPCLinux systemd[1]: fprintd.service: Deactivated successfully.
Feb 11 15:48:20 GamingPCLinux systemd[1]: Starting Fingerprint Authentication Daemon...
Feb 11 15:48:20 GamingPCLinux systemd[1]: Started Fingerprint Authentication Daemon.
Feb 11 15:48:20 GamingPCLinux fprintd[5063]: Got different state response than expected, continuing anyway
Feb 11 15:48:34 GamingPCLinux fprintd[5063]: libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know
Feb 11 15:48:34 GamingPCLinux fprintd[5063]: libusb: error [do_close] A cancellation hasn't even been scheduled on the transfer for which the device is closing

[archeYR]

Feb 11 15:47:17 GamingPCLinux fprintd[4800]: Device reported an error during identify for enroll: Init: expected 8 bytes but got 72 
Feb 11 15:47:20 GamingPCLinux fprintd[4800]: Got different state response than expected, continuing anyway

That tells us that this device uses a different type/length of response packets too. I am afraid I don't have time to reverse it, and without owning the device it's a much more tedious process. I would welcome the contribution though if you're able to take on this.

[ifeign]

I'm unfortunately not a developer so I'm not sure how much help I could be. Just for your reference, this is the reader I'm using

It seems the best approach currently is to try to repack the .deb driver to work on Arch. (Or I just buy a new fingerprint reader that will work.)

I am willing to provide you with the hardware to make things easier to reverse engineer if you are interested, because I think your open source driver is far more beneficial for the Linux community than some hard to find proprietary driver on a manufacturer website

[archeYR]

I am willing to provide you with the hardware to make things easier to reverse engineer if you are interested, because I think your open source driver is far more beneficial for the Linux community than some hard to find proprietary driver on a manufacturer website

This isn't really my driver, it was originally written by ddlsmurf. I overtook the project because original author did not have the device anymore, however due to lack of time I am only committed to maintain the existing code and eventually prepare it for upstream. So while I appreciate your offer, I am afraid I cannot spare enough free time for another project. Sorry.

[ifeign]

I am willing to provide you with the hardware to make things easier to reverse engineer if you are interested, because I think your open source driver is far more beneficial for the Linux community than some hard to find proprietary driver on a manufacturer website

This isn't really my driver, it was originally written by ddlsmurf. I overtook the project because original author did not have the device anymore, however due to lack of time I am only committed to maintain the existing code and eventually prepare it for upstream. So while I appreciate your offer, I am afraid I cannot spare enough free time for another project. Sorry.

Understood. Thank you for taking a look at this in the first place.

I'll have to try the other drivers or move on to different hardware.

[ddlsmurf]

@ifeign To write this driver I used wireshark USB interception and tested results using this html https://gist.github.com/ericlinagora/271ea7290507c0b0ad72b550e819357b . If you get that to work with your device it should be very easy to adapt the driver. Hope this helps sorry I can't do more. Disassembling the windows drivers was a complete waste of time when I wrote this, fyi, but I'm not good at that so maybe I was wrong.

edit: here are all the links that helped make it https://gitlab.freedesktop.org/libfprint/libfprint/-/issues/610 (including the udev shit to get the html working)

[ifeign]

@ifeign To write this driver I used wireshark USB interception and tested results using this html https://gist.github.com/ericlinagora/271ea7290507c0b0ad72b550e819357b . If you get that to work with your device it should be very easy to adapt the driver. Hope this helps sorry I can't do more. Disassembling the windows drivers was a complete waste of time when I wrote this, fyi, but I'm not good at that so maybe I was wrong.

edit: here are all the links that helped make it https://gitlab.freedesktop.org/libfprint/libfprint/-/issues/610 (including the udev shit to get the html working)

Thank you for all this info! I'll give it a try once I read through that gitlab issue. Hopefully this works