[fprint] elan patch + poc 0x903 and 0x0C03

[Igor Filatov]

Wow, thanks, Hans! This should be really useful. I'll take a closer look
later today.

On Wed, 17 Jan 2018, 09:57 Hans de Goede, <hdegoede at redhat.com> wrote:

> 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!  :
>
> https://fedorapeople.org/~jwrdegoede/elan-fingerprint/
>
> 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
> >
> https://github.com/iafilatov/libfprint/commit/fec2a1f3cffca1b1da2f9e379745db344bab2ab5
> > 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 <sebastien.bechet at osinix.com
> >:
> >> 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 :
> >>
> https://dlcdnimgs.asus.com/websites/global/products/jlHvIhXRAPm1WpRr/V1/images/main/response.png
> >> - 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
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fprint/attachments/20180117/8142bed6/attachment.html>