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 _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg