On 07.06.2017 15:12, Benjamin Tissoires wrote:
Hi Arek,
On Wed, Jun 7, 2017 at 9:27 AM, Arek Burdach <arek.burdach@xxxxxxxxx> wrote:
Hi Benjamin,
On 16.05.2017 11:46, Arek Burdach wrote:
On 16.05.2017 10:18, Benjamin Tissoires wrote:
On Mon, May 15, 2017 at 8:45 PM, Arek Burdach <arek.burdach@xxxxxxxxx>
wrote:
Hi Benjamin,
I found out what was wrong in the change that you've provided:
On 12.05.2017 16:28, Benjamin Tissoires wrote:
+ if (td->mtclass.quirks & MT_QUIRK_STICKY_FINGERS)
+ mod_timer(&td->release_timer, msecs_to_jiffies(250));
}
Should be:
mod_timer(&td->release_timer, jiffies + msecs_to_jiffies(100));
Right, thanks!
Delay should be added to current jiffies value. Also I found out that
250 ms
is too long delay - xserver recognize such a delay as a drag gesture.
Using
100 ms everything works perfectly!
Does 160 ms works too?
160 ms works too but I have a feeling that values closer to 200 ms gives
quite a laggy experience so I'd suggest to keep value closer to 100 ms.
Beside that I haven't seen situation that "normal" syn_report have been
repored after longer delay than 30 ms. Mean value is 9 ms and 95 pp ~10 ms
(tested by drags with evemu-record)
I'd rather have 10 times the maximum time
between 2 reports than 6.25 times it :)
We can use 96 ms if 160 doesn't work.
In fact 100 ms it is exactly 6 times the maximum time between 2 reports,
because 60 Hz frequency gives 16,(6) ms period
What do you think that should be changed
more in the patch to make it ready for being submitted as an official
patch?
Not much actually. I need to wrote down a commit message, sign it
(your sign-off-by can also be added given that you debugged it), and
that should be it.
Do you planning to submit this change? I think that other users would be
glad to take advantage of this fix :-)
Yes, sorry, it's still on my todo list. I am trying to fix the last
issue I can think of which is problematic:
if you happen touch again the sensor when the deferred timeout starts,
both threads will access the input node, and this can create some
nasty behaviors.
Indeed this situation can produce some nasty behavior like interrupted
dragging gesture but user need to click very fast to occur that.
I am not 100% sure we can rely on classic solutions (spinlock,
mutexes) because in these 2 concurrent threads we are in places where
we can not stop.
I'm very intrigued how it could be resolved without mutexes.
So I'll need to conduct more tests and find a better/simpler solution
to not hit that. Sorry for the delay.
No problem. Thank you for the notice.
Or do you want me to do it on your behalf?
I'd like you to give a test when I finally get something. However,
it's not on my top priority list, sorry for that.
I would test it with pleasure. BTW I didn't noticed any problem with
current solution so far and I'm using touchscreen quite often.
One more time thank you for your help!
Cheers,
Benjamin
I thought about some unit tests, but can't find any for hid drivers also
I
I have a test suite that can emulate hid devices and inject them in
hid-multitouch. The setup is a little bit manual, so I'll try to run
it today and see if there are differences with or without the patch.
Ok, waiting for signed patch
Cheers,
Arek
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
