In corollary to Bug 67563, I can trigger weston to stop processing touch events with a single touch device. It's hard to trigger, but by rapidly tapping the screen in random places, Weston eventually gets into a state where it stops sending touch events to the clients. After a little debugging, I found that input.c::notify_touch() gets invoked with a value of WL_TOUCH_UP by evdev.c::evdev_process_key() twice in a row when seat->num_tp==1 prior to the first WL_TOUCH_UP. This results in seat->num_tp getting decremented too many times, hence halting client touch notifications. In other words, the number of invocations of notify_touch(WL_TOUCH_DOWN) and notify_touch(WL_TOUCH_UP) are not symmetric. Beyond this, I'm not sure what triggers evdev_process_key() to handle two BTN_TOUCH 0 events in a row... since evtest BTN_TOUCH 1 and BTN_TOUCH 0 events appear to be symmetric. evtest logs are forthcoming.
Created attachment 86464 [details] server-debug.log
Created attachment 86465 [details] evtest.log
Created attachment 86466 [details] weston.log
$ grep "BTN_TOUCH.*value 1" evtest.log | wc -l 88 $ grep "BTN_TOUCH.*value 0" evtest.log | wc -l 88 $ grep "touch.*up" debug.log | wc -l 51 $ grep "touch.*down" debug.log | wc -l 47
I think I can see one problem looking at the evtest event log. At line 350 there are touch up and down events with no motion event in-between. The evdev code actually ignores the key down events and only sends the touch down event on the first motion event. The key up events cause it to directly send the touch up event. That would therefore cause it to send a touch up event without the corresponding down event and it would get confused and stop processing further events as you saw. If that is the problem then I guess the simple solution would be to get it to track the key down events instead of just relying on the motion events. $ head -n 350 evtest.log | grep "BTN_TOUCH.*value 0" | wc -l 48
Created attachment 86479 [details] [review] evdev: Process touch up events of single-touch devices Here is a patch on top of the one in 67563 to do the suggested change.
Created attachment 86480 [details] Test case I haven't got a single-touch device so I can't really test the patch properly but here is a simple test using uinput to generate a similar set of input as the one in Artie's log.
(In reply to comment #7) > Created attachment 86480 [details] > Test case > > I haven't got a single-touch device so I can't really test the patch > properly but here is a simple test using uinput to generate a similar set of > input as the one in Artie's log. Interesting, I was just writing the same uinput touch support in wayland-fits to test this ;-). I'll test your patch and let you know what I find. Thanks!
Comment on attachment 86479 [details] [review] evdev: Process touch up events of single-touch devices Review of attachment 86479 [details] [review]: ----------------------------------------------------------------- Tested and confirmed that this patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=69759
(In reply to comment #9) > Comment on attachment 86479 [details] [review] [review] > evdev: Process touch up events of single-touch devices > > Review of attachment 86479 [details] [review] [review]: > ----------------------------------------------------------------- > > Tested and confirmed that this patch fixes > https://bugs.freedesktop.org/show_bug.cgi?id=69759 Nice work Neil, that should indeed fix the problem. Thanks for verifying Artie. Patch committed as: commit be336c89182ce2acf608c889223cf7d1b8940083 Author: Neil Roberts <neil@linux.intel.com> Date: Tue Sep 24 20:05:07 2013 +0100 evdev: Process touch up events of single-touch devices ...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.