Re: More XI 1.5 questions
On Mon, Dec 22, 2008 at 07:31:34PM +0100, Thomas Jäger wrote: > >> 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). I just noticed that: this should read server <= 1.6 For all currently released servers, grabs on core devices does not affect the physical devices and the other way round. Come XI2 with explicit MD/SD hierarchy support, a grab on an SD will temporarily detach the device from the MD. > > 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. > All right, I'll look into that a little bit more. The first two > conditions are satisfied, it's just the third one that isn't. By the > way, browsing through the source, it seems that XAllowEvents and > XAllowDeviceEvents do the same thing in most cases (AllowSome()'s core > parameter doesn't have any effect). Although I doubt that they are > any clients out there that depend on that (my program doesn't use > XAllowDeviceEvents at all). Well, you can't call XAllowEvents for an explicit device, so XADE is needed once you actively use XI and its grabs etc. btw. thank you for digging into this, much appreciated! Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: More XI 1.5 questions
On Mon, Dec 22, 2008 at 12:20 PM, Peter Hutterer wrote: > 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. Fair enough, I'm going the other route now. >> 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. I see. The way I solved this is that I'm releasing all buttons via XTest now if XSetPointerMapping fails. It works better than I thought, but there's always the chance that the button may have been released on the device while I'm pretending it is in the up state. But that's not a big deal (if it happens at all) since the user can always restore a consistent state by pressing the button again. >> 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. All right, I'll look into that a little bit more. The first two conditions are satisfied, it's just the third one that isn't. By the way, browsing through the source, it seems that XAllowEvents and XAllowDeviceEvents do the same thing in most cases (AllowSome()'s core parameter doesn't have any effect). Although I doubt that they are any clients out there that depend on that (my program doesn't use XAllowDeviceEvents at all). Thanks, Tom ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: More XI 1.5 questions
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
