More XI 1.5 questions
peter.hutterer at who-t.net
Mon Dec 22 03:20:50 PST 2008
On Thu, Dec 18, 2008 at 01:30:41PM +0100, Thomas Jaeger wrote:
> 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 18.104.22.168): 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.
More information about the xorg