On 11/29/2010 11:03 PM, Peter Hutterer wrote: > On Mon, Nov 29, 2010 at 04:07:24PM -0500, Chase Douglas wrote: > once you have the device in the hierarchy, it'll be hard _not_ to send > through the master device. we're sending single-touch events from > traditional touchscreens through the master device, though you could argue > that for these events (or absolute events in general) the abstraction is not > needed.
Maybe I'm missing your point, but it's not hard at all to _not_ send touch events through the master device. That's how I have it working right now in my patches. Single touch events from traditional (I assume you mean non-MT?) touchscreens are the same as pointer emulation of MT touchscreens. These can be sent through the MD as usual. I don't think ST touchscreens should actually expose a touch class device. It's a bit of a misnomer, but a touch class device is meant for multitouch devices. If you can't do multitouch, you're no better than an absolute mouse pointer input device. > we'd be sending dependent device touches through the master device, so just > by switching the mode the event delivery would change. this is just > confusing, imo. I agree, which is why I don't want to send any touch events through the MD :). > non-touch events from the same device would still go through > the MD, so unless you monitor the SD for these events (but ignore them, > because logical button state is largely on the master) you'd lose > serialisation. you couldn't tell whether a button event happened before or > after a touch event, at least not if you hit the time resolution. X is serialized by its nature of being a socket connection. We queue up all events in the evdev driver until the sync is seen, then we send button events first, then the rest of the events. I think a typical application will subscribe to all the currently subscribed for events on the MD (pointer motion, buttons, etc.), then subscribe for touch events on the SDs with touch classes. Coming out of the X connection pipe, the client will see button events on the MD, then see touch events on the SD. In fact, the only difference between sending touch events through the MD and the SD is that the MD events may be preceded by a DCE and will have the MD device ID instead of the SD device id. The ordering of events should not change. What do we gain by sending the events through the MD? Pointer events *must* be sent through the MD because the purpose of the MD is to coallesce motion from multiple devices into one logical cursor on screen. There's no similar need to do the same for touch events. In fact, I think it will just be that much more confusing when there are multiple multitouch devices connected to a single MD. > the argument you brought up in your last email is that DCEs are hard. That's > not really a technical reason against sending events through the master > though. No, I'll grant you that. However, it's the impetus for me wondering whether we need to deal with MD events and DCEs at all. Correct serialization of events is a possible reason for the requirement, but if everything works as I noted above I don't think sending events through MDs solves anything. It's not just DCEs either. How do we handle mixing touch events and traditional pointer grabs? Your initial protocol spec was defined such that touch events are not blocked during a grab. If we do touch broadcasting as I defined, what is the proper synchronization for MDs? It's my strong belief that multitouch devices are inherently different from traditional pointing devices. I believe this has been agreed upon by everyone since no one wants to apply traditional MD grabbing to touch events. Thus, the best approach is to separate the traditional pointing mechanisms from touch mechanisms. MDs are synonymous with traditional pointing mechanisms, and, imo, trying to fit touch events onto them presents conceptual and practical challenges that are not necessary. >> My point was that by not sending touch events through the MD we erect a >> clean barrier between pointer emulation and multitouch events. > > we have this barrier through the device flags. the DCE tells us which device > is now sending events, and the pointer event has the flag set. i'm not sure > why we need more barriers. The barrier isn't necessary, so yes, this isn't a hard requirement for not sending events through MDs. However, I believe it simplifies the scheme conceptually. XI is hard enough to wrap your head around, so anything that makes it easier to understand is useful. -- Chase _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
