Wow, thanks, Hans! This should be really useful. I'll take a closer look later today. <div class="gmail_quote"><div dir="ltr">On Wed, 17 Jan 2018, 09:57 Hans de Goede, <<a href="mailto:hdegoede@redhat.com">hdegoede@redhat.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Sébastien and Igor, I too have an Elan fingerprint reader tucked away in a corner of my touchpad, my model is: 04f3:0c16 . Since I've a contact inside Elantech from my work on touchpads, I've been communicating with them to get some specifications and they have provided me with some command reference info, which I'm allowed to share! : <a href="https://fedorapeople.org/~jwrdegoede/elan-fingerprint/" rel="noreferrer" target="_blank">https://fedorapeople.org/~jwrdegoede/elan-fingerprint/</a> Unfortunately I have not yet had time to look at supporting my own reader and it does not look like I will have time for this soon. Still this should be helpful for you and Igor. Note that in calibration mode you are supposed to wait for the reader to give a certain reply rather then try X times. While I still hoping to have time for this soon I did ask some questions to clarify some things from the docs I got, the answers to which might be helpful: 1) Should the commands be executed in the order listed? [ELAN] : No, they are not sequence command. I think "Get image data(0x0009)" is the most important command for your developing. 2) The last 2 steps / commands get reg data / set reg are not exactly clear, do I need those at all? [ELAN] : No, they are used for control-register read/write. You don't need them, it's internal usage. 3) How should I get the actual image data when I'm done with the pre-scan polling? [ELAN]: You can use "get Image command ( 00 09)" to get Image data. (BTW, it's the ADC value, not offset value) Please refer to Pre_Scan_flow.pdf for more information. Sébastien, question, are you using yours in swipe mode, like Igor is? Regards, Hans On 16-01-18 17:09, Igor Filatov wrote: > Hi Sebastien, > > Thanks for your work. Please try > <a href="https://github.com/iafilatov/libfprint/commit/fec2a1f3cffca1b1da2f9e379745db344bab2ab5" rel="noreferrer" target="_blank">https://github.com/iafilatov/libfprint/commit/fec2a1f3cffca1b1da2f9e379745db344bab2ab5</a> > and see if it works for you. Also please tell me if you don't want > your email mentioned in the header. > > 2018-01-16 13:37 GMT+02:00 Sébastien Béchet <<a href="mailto:sebastien.bechet@osinix.com" target="_blank">sebastien.bechet@osinix.com</a>>: >> Hello Igor, >> >> On 2018-01-15 17:38, Igor Filatov wrote: >>> >>> I don't quite understand what happens though. You've replaced a number >>> of stages by plain image read commands (CALIBRATE, CAPTURE_START, >>> DEACTIVATE) which don't seem to do anything but read and discard the >>> image. Maybe it's fine to not do anything at all at those phases? My >>> scanner needed to "scan the air" a few times for calibration and such >>> reads always follow other specific commands (0x4023, 0x4024). Did you >>> try to just skip the reads instead? >> >> >> It is working when we skip the "scan the air" read command. Nevertheless the >> binary driver abuses the read: there must be a good reason? Do you think we >> can avoid calibrate_states? >> >>> Do 0903 and 0c03 have leds? If they do, how do you turn them on and off? >> >> >> - No LED for 04f3:0903. Device is integrated with the trackpad. >> See here : >> <a href="https://dlcdnimgs.asus.com/websites/global/products/jlHvIhXRAPm1WpRr/V1/images/main/response.png" rel="noreferrer" target="_blank">https://dlcdnimgs.asus.com/websites/global/products/jlHvIhXRAPm1WpRr/V1/images/main/response.png</a> >> - I don't know for 04f3:0c03. Konata? >> - BUT i have a good news: it seems 0x0b working. The bugframesup30.diff bug >> misled me (this is a _must_ patch) >> >>> Also the orientation. IIRC 0903 is square. Do you swipe the finger on >>> it? Square sensors could cause problems because it's impossible to >>> know how they are oriented relatively to the user. Stitching of frames >>> could fail if the assumptions in the driver are wrong. >> >> >> I tried examples / img_capture this morning. The orientation is good for >> 04f3:0903. >> Konata, can you try for 04f3:0c03? >> >> Igor, do you think i can try to adapt POC to orginal driver? What is the >> best solution? >> >> What do you think about this patch? Last problem for me is ELAN_FRAME_MARGIN >> >> Bye > > > </blockquote></div>