Hi Chase, I didn't have time to look into your Grail/Geis design in-depth. My comments are based on what I leant from your presentation at XDS. And it is based on the coming XInput 2.1. That is, I assume we have MT support in the X server.
Tell me as soon as I lose you. Ping On 10/4/10, Chase Douglas <chase.doug...@canonical.com> wrote: > As I've thought some more about the current grail architecture and the > future when we have XInput 2.1 with full multitouch support, I realized > there may be an issue with our current implementation. > > Grail currently takes MT input and looks for a subscribed gesture. If > there wasn't any, the MT input is discarded (leaving aside single touch > emulation). Once XInput 2.1 is available, including when we move gesture > recognition to the client side, we'll need to be able to pass through MT > events. A wrinkle is that we need to be able to support MT grabbing as > well. I think most of what you do now in Grail would be handled by XInput 2.1. We may still need to keep mtdev to translate type A to type B. But that is very much device specific. I think your current Grail or the coming XInput 2.1 deals with generic system wide MT events. Right? So, once XInput supports MT grabbing, it would be up to the client to tell X server that it is grabbing the events or not. Grail/Geis would be in the same position as all the other clients, assuming Grail and Geis will deal with system wide (or Unity in your term :) MT gestures on Ubuntu then. > When I thought about MT grabbing, I realized that grabbing really needs > to be done on a per-finger basis, and the client needs to decide early > on whether to grab the touch through the entire touch, or whether it > should allow events through to non-grabbing clients. I don't feel per-finger grabbing would work. My view of grabbing works like this: when the touch points/contacts are inside an MT enabled client, the client grabs the events and translates them into its specific events/gestures. The client ungrabs the events when all the touch points leave the surface. Next time when MT events coming in, grabbing will be decided again base on which client the touch points are in. Unity grabs the events if the touch points cover more than one client. Same thing happens to Unity. It ungrabs the events only when all touch points leave the surface. > Imagine you perform a two finger pinch gesture and then move directly > into a two finger drag. If a client subscribes only to the drag gesture, > it will receive gesture events for the drag once grail starts to > recognize it. However, this breaks down when we try to involve MT grabs. > We would need to wait through an entire touch sequence until a > subscribed gesture is found before we can decide whether to handle all > the events ourselves or replay them to other clients. I don't think Grail or XInput can make the decision. It is the client who needs to make the decision. I think most gestures are client specific. Grail/Geis can only deal with the system wide generic gestures. So, it should not care about if a client is doing a draging or pinching. It only knows that the client is grabbing the events. If the client doesn't support MT or doesn't grab the MT events by some reason, Unity kicks in to translate those MT into system wide gestures. Unity comes into play the last. It is a system wide default, which could be different for different distributions, I guess. > What I think we'll need to do is modify grail so that it recognizes a > subscribed gesture very soon after a touch begins. If no gesture was > recognized, the touch needs to be passed through as normal MT events for > the remaining duration of the touch. This allows a grabbing client to > make a decision on whether to replay events for the touch to > non-grabbing clients. This also means grail can't recognize gestures > based on touches that have already been disposed to pass-through status. I think I've covered this part already. Ping _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : multi-touch-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
