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 _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
