On Thu, Dec 2, 2010 at 10:46 AM, Daniel Stone <[email protected]> wrote: ... > OK, so would something like this suit you: > * at selection time, clients can choose whether or not to receive > not-for-you events > * at any point during a touch stream, the current owner of a touch can > tell the server that it should not send any more events for that > touch stream to non-owning clients > * at any point during a touch stream, non-owning clients can opt out > of receiving further events from that stream
Are these "not-for-you-events" touches outside any of the clients windows? Are we allowing to let the client select for all touch events, anywhere they occur? That sounds like a bad idea from a security / client isolation point of view. If on the other hand, that's not the case and clients only receive events that land inside one of their windows and only when they select for it, I really don't think we need the roundtrips to stop event delivery. We're not waking up a ton of clients, we're waking up the one client that's actually being touched. Either way, the requests to stop delivery to yourself or other clients don't make sense to me. If we're concerned about waking sleeping clients unecessary, we need to not wake them at all. Waking up a bunch of clients so they can tell us that they don't want to be woken up is broken. Especially if the premise is that they need to inspect the event stream a bit to decided whether or not they need the events. In that case, the clients wake up do some amount of work, and then opt of the stream eventually, but the benefit is negligible, since most gestures are pretty short lived anyway, and the big cost is waking the client in the first place. > * if a client which has not selected for not-for-you events becomes > the owner of a touch stream, an event is sent to that client with > the entire current state of the touch (i.e. dev->touch->last*) How would that happen? Kristian _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
