On 03/22/2010 03:58 PM, Micki Balanga wrote:
>
> Hi
> I would like to add more information about the Fake button.
> I will explain using this scenario:
> You touch the sensor with one finger and then remove the finger,
> Firmware will report six frames with fake fingers,(Indicate end of session)
> The driver will report this as fake fingers (Will send 3 events) and
> input_sync
> to inform user space application that the user removed finger from sensor.
> this information is needed in order to analyze the data received from
> N-trig firmware.
> Micki

Thank you for taking this to a discussion format.

It seems you have raised an issue that is an active discussion for multi 
touch handling in general and an issue that I have considered for n-trig 
support in specific.


The current published version of the driver does send one more sequence 
of events after it decides all fingers are off the screen.  That final 
sequence is necessary to tell single touch drivers that the tools are 
released (BTN_TOUCH is set to zero, etc).  This also resets the active 
contact count to zero for multi touch handlers, which look to see how 
many MT events come from each frame.

I had observed that sometimes the tablet looses contacts semi 
arbitrarily, and we get a zero contact group as a mistake.  In the 
patches I sent in early in February you will notice a solution that I 
was considering at the time.  I was also playing with correcting for 
events that looked like real contacts but were also just noise.  After 
rethinking my patches and reading the multi touch doc in the Documents 
tree, I chose to leave out these corrections.

That being said, I do have a specific patch to handle the set of end of 
stream events.  All that's needed is to count the empty groups and send 
the terminal events only when a counter hits the specified value 
(attached is a tiny patch I wrote when I needed that feature back really 
quickly when my screen started misbehaving during a meeting).

Note I have submitted that as a patch for 2 reasons.  First I couldn't 
be completely sure that there was a specific number of empty groups to 
signal end of stream which would be expected to be maintained over time. 
  And secondly the erroneous termination of stream has not been much of 
a problem in general.

You will note, that this is something that is simple enough that it 
makes perfect sense to put into the kernel.  There's little point in 
wasting the cycles to push that decision to user space.