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

[Sébastien Béchet]

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 --------------
A non-text attachment was scrubbed...
Name: poc_0903_0C03-20180116.diff
Type: text/x-diff
Size: 3941 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/fprint/attachments/20180116/d33bd000/attachment.diff>