More XI 1.5 questions

[Peter Hutterer]

On Thu, Dec 18, 2008 at 01:30:41PM +0100, Thomas Jaeger wrote:
> Hi,
> 
> I've got a few more questions on input behavior.
> 
> > The second issue I encountered was a change in XTest behavior.  It's not
> > possible anymore for the core pointer and the devices to be in an
> > "inconsistent" state where a button is pressed on the device but appears
> > to be up as far as the core pointer is concerned.
> 
> 1. I'm still looking for way to be able tell when the button on a device
> is released while I'm pretending (at least as far as the core pointer is
> concerned) that the button is up.  So is it possible to detach a device
> in XI 1.5?  

Yes and no. Devices configured with SendCoreEvents (yes by default) are always
attached to either VCK or VCP. There's a DeviceControl that may support it,
though I don't actually know if it works.

> The other idea that I had was to use XSetPointerMapping.
> The problem with that is of course that it doesn't work while the button
> is pressed, so I'd have to mess with XFakeDeviceButtonEvent, which seems
>  prone to race conditions.  So I was wondering, I know that the spec
> says XSetPointerMapping should return MappingBusy if an affected button
> is in the down state, but this is a pain in the neck for every client
> that has to deal with this function.  Wouldn't it make more sense to
> always have the function succeed and generate appropriate Press/Release
> events if the state of a button changes?

If it's in the core protocol spec you will to get a presidential pardon to
change it. Sorry.

> 2. Currently, button grabs behave differently depending on whether
> buttons > 5 are involved.  For example, if the sequence is "8 down, 1
> down, 1 up, 8 up", then you'll miss the the last event due to the grab
> being released when all of the first 5 buttons are up (this goes for
> both Xi and core events).  Is this the intended behavior?  I don't think
> I've seen it documented anywhere and it's kind of painful to deal with.

Ignoring this for now, you already sent a patch for that. (thanks btw!)
 
> 3. What is the intended behavior of Xinput button grabs with
> GrabModeSync?  The two devices that I have here behave differently
> (xserver 1.5.99.3):  The trackpoint will still send motion events
> (clearly the more useful behavior), while the stylus works the same way
> the core pointer does and queues them up until an appropriate
> XAllowDeviceEvents call.  I wonder if this is related to the fact that
> bug #19034 only applies to the track point, not the stylus.

this is a weird bug and I don't quite know why the trackpoint is different
here. they should look the same to the server.
The indended behaviour is (and this is server >= 1.6).
Grabbing the VCP/VCK does not affect the physical device. Grabbing the
physical device does not affect VCP/VCK events. If a device is frozen through
GrabModeSync, all events must be enqueued until the device is thawed.

Cheers,
  Peter