On Tue, 25 Sep 2012 15:13:24 +0200 Bastien Nocera <had...@hadess.net> wrote:
> Em Tue, 2012-09-25 às 16:02 +0300, Timo Teras escreveu: > > Hello list, > > > > I have reverse engineered the uru4500 encryption scheme from the > > binary only drivers. And I have a modified libfprint here that > > gives sensible data from this device - fprint_demo seems to work > > with it just nice. > > > > If I'm to clean up the patch (and someone can test it with the older > > devices) would it be acceptable as such for merging? > > > > Or should I document the encoding scheme, and someone else write the > > fprint driver modifications? > > Great news! > > I'm fine with accepting reverse-engineered drivers without Chinese > wall, as the clear goal is hardware interoperability. Documenting it > in the source would be best, if the size isn't humongous, otherwise > in a separate README file. It's not too large change. And with that we should be able to delete the code that tries to fiddle with the firmware. And this is actually what my current patch does: removes the firmware fiddling, and decrypts the image based on the image headers. Which would be the reason why it needs proper testing. Oh - I also fixed the capture modes. The device now actually turns off the background light when no longer in use. I'm also still looking at the parts that should make the image more or less crispier. > Once you've cleaned up the patch, attach it to Bugzilla, and we can > review from there. Will do. I'll clean up and file bug. Should have it done tomorrow or the day after. -Timo _______________________________________________ fprint mailing list fprint@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/fprint
