New approach to multitouch using DIDs and bitmasked events

[Chase Douglas]

On Sat, 2010-07-03 at 01:08 -0400, Rafi Rubin wrote:
> On 07/02/10 21:09, Chase Douglas wrote:
> > I hacked some more today, and I'm not sure we need a separate XI2 event
> > type. I'm going to send out another RFC "pull request" with the work
> > soon, but as an overview I wanted to work on the "magicmouse" scenario.
> > The result is the following:
> 
> Another plug for multilevel hierarchy instead of the two level master/slave.

I'm not quite clear what you mean by this and what we would gain.

> I'm glad the xi2 pointers seem good enough now, that does seem simpler.  Just an
> extra flag for "no_core".  Then again, can't we just mask out MT events from the
> core, and then it won't matter?
> 
> > MT Touchscreen:
> >   - Device is marked as a DID
> >   - Starts out floating, can't be attached
> >   - MT touch coordinates are the first two valuators, XIDeviceEvents are
> >     in screen coordinates. However, an app can grab XIRawEvents for
> >     device coordinates. *
> >   - Since it's a DID, button events are also blocked for core, XI1
> 
> Slight problem with masking out buttons.  Henrik, didn't you add different
> device types (ie, MT pen) to your protocol?  What do buttons mean on a mt pen?

This may be a case where we do want to create multiple X input devices
for one physical device. One would be fore multitouch, the other would
be for pen input. The MT would act like a touchscreen, and the pen would
act like a typical touchpad.

> > Magic Mouse:
> >   - Device is *not* marked as a DID
> >   - Starts out attached to virtual core master pointer
> >   - First two axes are REL_X, REL_Y
> >   - Device is marked as relative (for core and XI1 events)
> >   - Abs MT axes are marked as absolute
> >     * Can only be sent through XI2 since XI can't handle mixed mode
> >   - Since Abs MT touches are not the first two axes, they are not
> >     translated to screen coordinates
> >   - Abs MT axes sent through XI2 are also sent through attached master
> >   - Button events are not blocked for core, XI1
> > 
> > I am not aware of any use case that is not covered by the above scheme
> > and requires a new XI2 event type. If you know of any, please let me
> > know.
> > 
> > * Raw events are only delivered to the root windows and windows with a
> > grab. This is a limitation currently, but I wonder why we can't just
> > deliver them like normal events?
> 
> Still trying to understand what raw events mean in the scope of X clients.
> Certainly I'm comfortable with using them outside, and I don't really see a
> downside.  Do you also expose physical metadata (size of sensor)?

Raw events just aren't translated into screen coordinates. You can read
more here:

http://cgit.freedesktop.org/xorg/proto/inputproto/tree/XI2proto.txt#n1546