On Tue, Mar 12, 2013 at 4:59 AM, Benjamin Tissoires <benjamin.tissoires@xxxxxxxxx> wrote: > On Tue, Mar 12, 2013 at 2:36 AM, Peter Hutterer > <peter.hutterer@xxxxxxxxx> wrote: >> On Mon, Mar 11, 2013 at 04:34:27PM -0400, Yufeng Shen wrote: >>> I have ran into cases where I want to make a touch end event to have a >>> touch cancel indication. >>> >>> This comes from trying to solve the problem of : >>> >>> If the touch sequence happens before the system suspends, and the touch >>> release event is >>> never received after the system resumes, userspace MT state tracking could >>> be in a bad state. >>> >>> ( see #5 from >>> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/968845 >>> for an example of how this could happen from lid close/open on MBA) >> >> ftr, this a bug in the driver and should be fixed now. >> >>> One possible workaround is to let the touch device driver to release all >>> existing touches on >>> resume, which has the effect of clearing all the MT states in userspace >>> touch stacks. >>> But the touch release/end event often will result in some gesture being >>> recognized and performed, >>> like a tap-to-click being generated. >>> >>> So I am wondering what's the best way to solve the problem of clearing the >>> touch states with >>> minimal side effect. One way I can think of is to have MTB protocol add >>> support of >>> a touch cancel indication on touch release, e.g. making TRACKING_ID = -2 >>> meaning that >>> the touch release is synthesized from the system and really has the meaning >>> of releasing and canceling the current touch, while TRACKING_ID = -1 >>> meaning that the touch release is reported back from the device. >>> >>> And from Xf86-input driver level, we can add a corresponding TouchCancel >>> for this. >> >> I can handle touch-cancel events in the synaptics driver to avoid >> tap-to-click but further details get a bit nasty. >> >> To actually add TouchCancel to the client-protocol means a new XI protocol >> revision, plus the stuff in the server _and_ the stuff in the client. that >> is quite some lag time here, and if a client cannot handle TouchCancel all >> we can do is do a TouchEnd - which will still trigger the gesture. >> >> even if you update the touch clients you're still lacking any solution for >> pointer-emulated clients. again, here we can only do a ButtonRelease event >> which again will trigger whatever it did. >> >> All the above can be implemented though. In fact, I suspect the protocol >> part is the easy bit (just a flag on TouchEnd) but the server part is >> reasonably nasty. >> >> the real counter-argument is that I think it is a partial solution only. >> From an X perspective touches also end when you vt-switch away from the >> server (device is disabled). but the kernel won't cancel the touch event for >> that. Or when the device is disabled by the client ("disable touchpad while >> typing" feature), So we'd have to maintain both implicit cancel and explicit >> cancel in the driver anyway. >> >> so yeah, I don't think adding this to the kernel would provide any >> significant benefit since we still need to handle all the other cases >> anyway. > > If the same effect is seen when VT-switching, it's definitively a user > space synchronization problem, not a kernel problem. > > I think we have all the pieces in term of protocol in the kernel for > this use case: > When coming back from resume, the kernel should guarantee that the > current input state is correct. If fingers are still present, then > their slots are still assigned, if they are missing, their slots > should be silently released (as if the released occurs while > sleeping). This is something the kernel can work on. > As for the user-space, when coming back from a situation where > inconsistency may have occurred (VT-switching, sleep/resume, events > dropped due to a SYN_DROPPED event, or device disabled by the client), > the user-space driver has to retrieve the current state of the kernel > driver through the correct ioctls. If it doesn't do it, then that > means that he is not following the evdev protocol. It's up to it to > notify or not the toolkit/gesture recognizer that events have been > dropped. what's your suggestion on implementing "notify the toolkit/gesture recognizer that events have been dropped" ? > > Cheers, > Benjamin -- 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
