[RFC XI 2.1 - inputproto] Various fixes in response to Peter Hutterer's review

[Chase Douglas]

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