Hi Daniel
I am hoping to soon do a tidy up of the code that I am using to get
libfprint to work on our embedded systems, and would like to give you
the option to fold this back into the project.
I have a couple of questions:
1) Should I go ahead and modify against v0.05 - or would it be better to
wait until v0.06 ?
2) I was thinking of using compile switches that would alternate the
Making of the project. i.e. By default you get the normal standard
compile - but with the use of compile switches you could include extra
embedded libfprint code, and/or code from stripped down 3rd Party
libraries (like glib and/or the AES code etc.)
3) Regarding the use of external libraries that are just too large to
fit on some embedded systems (e.g. GLib).
Would you rather we keep the shrinking down of these libraries as a
separate project (outside of libprint), or is it okay to include
stripped down source files inside a say libfprint/glib_shrunk or
something like that?
GLib is also licensed under LGPL v2 - so is this okay from a licensing
point of view?
4) For now, I've been trying to make as few changes as possible to your
files, and have rather added new functions to a c file called embedded.c
Are you okay with this, or would you rather have all these changes
incorporated into the core.c / imgdev.c etc. files?
For example the following are in embedded.c at the moment:
void fp_embedded_init(struct fp_dev **p_fingerprint_device, struct
fp_img_dev **p_img_dev, struct fp_dscv_dev **p_dscv_dev);
void fp_embedded_exit(struct fp_dev **p_fingerprint_device, struct
fp_img_dev **p_img_dev, struct fp_dscv_dev **p_dscv_dev);
void fp_embedded_capture(struct fp_dev *p_dev, struct fp_img **p_img,
int p_unconditional);
Keep up the fantastic work.
Cheers
Jono
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint
