First XI2 server implementation

[Peter Hutterer]

On Sat, Mar 21, 2009 at 07:59:53AM -0700, Keith Packard wrote:
> On Sat, 2009-03-21 at 22:27 +1000, Peter Hutterer wrote:
> 
> >   - raw events do not include button state
> 
> Very sensible
> 
> >   - FP1616 type implemented as INT16.CARD16
> 
> Not int32_t here? Or do sub-pixel desiring apps really need to pull two
> values out?

It's all done by the library anyway, libXi provides a double for these values.
Clients won't notice the difference.

> >   - Enter/leave events include button/modifier state
> >   - Focus events added - basically identical to enter/leave events.
> 
> Do the focus events get delivered on enter/leave in pointer-root mode?

The focus model is the same as it was before, just the wire format has been
added. So DeliverFocusedEvent() now delivers both XI2 and XI1. Not sure about
this specific case you mentioned, but if it was covered in the old model, then
it is covered now. If not - then the model is buggy anyway.
 
> > - While the protocol and the library support subpixels, the server doesn't
> >   actually send them down the wire yet.
> 
> Any reason that scaled input devices can't do this? It seems like some
> fairly important new functionality that would be nice to see
> demonstrated.

Mostly "laziness". I marked the few places where we need to drop subpixel info
in (dix/getevents.c and dix/eventconvert.c, mostly) with FIXMEs so it should
be trivial to add this. Wanted to get a working version first though.
 
> > There are no protocol requests to grab for XI2 events yet. There's a reason
> > for that: I'm currently experimenting with getting rid of the master
> > pointer/master keyboard distinction in favour of a single master device that
> > is both at the same time.
> > This turned out to be ... tricky.
> 
> Yeah, I suspect grabs will make this difficult at best.
> 
> > I will post additional protocol request once I figured out the grab semantics
> > for the single master device case. So far, I have not been able to reach the
> > level of intoxication required to sort them out.
> 
> I know it's a nice clean-up, but frankly, having two virtual core
> devices matches the existing core semantics and not doing it will likely
> cause on-going pain with grabs.
 
The main motivator for this is the abundance of devices that aren't pointer OR
keyboard but rather pointer AND keyboard. This makes the existing core
semantics already difficult:
If such a device is attached to the VCP, its key class will be copied into the
VCP. The key event however can be routed through the VCP (in which case the
keyboard grab on the VCK is either ineffective or needs to be special-cased)
or it can be routed through the VCK, in which case they key event comes from a
potentially non-matching key class on the device. Right now, this happens with
multimedia keys on a number of combo devices.
So the current solution isn't pretty either and needs to be fixed. which one
is easier to fix remains to be seen.

Cheers,
  Peter