GNOME Bugzilla – Bug 623377
Add API to know the hardware input device that triggered an event
Last modified: 2010-12-22 19:23:53 UTC
Created attachment 165100 [details] [review] Patch to implement gdk_event_get_source_device() I'm attaching a patch that adds gdk_event_get_source_device(), this may be used in most situations to know the slave device that triggered an event (Done through XIEvent->sourceid in xi2). There are some situations where the slave device can't be guessed though, namely synthesized crossing events around a grab/ungrab operation, the master device will be used as the source device in these cases where no slave device can be obtained.
Do we really need this, separately from gdk_event_get_device ? Will you ever have source_device != device, both != NULL ?
Created attachment 165469 [details] [review] Updated patch Hrm, I indeed didn't hook this properly so this info goes through _gdk_windowing_got_event(), this is an updated patch that does that. I think there is a need for this API whenever some widget/app is interested in the slave device actually triggering the event, and not the master device proxying it. Given this device hierarchy: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ N-Trig MultiTouch id=12 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=19 [slave pointer (2)] gdk_event_get_device() would return the VCP, meanwhile gdk_event_get_source_device() would get me either the touchscreen or the touchpad devices, depending on which one I'm dealing with. One use case I can think of in GTK+ would be to hypothetically trigger kinetic scrolling if the source device is a touchscreen, OTOH we might need more GdkInputSource types and better heuristics before getting there...
Ok, makes sense to me now. And the patch looks reasonable. One question I have is if you really need to store two device pointers in the event. Shouldn't it be possible to infer the master device from the slave ?
Ping ?
(In reply to comment #3) > Ok, makes sense to me now. > And the patch looks reasonable. One question I have is if you really need to > store two device pointers in the event. Shouldn't it be possible to infer the > master device from the slave ? Hmm, that's a very good point, I'll rework the patch to get there, it'll possibly require some other API call though, or making gdk_device_get_associated_device() return the master device for a slave, what'd be most preferred?
Maybe we want to split it into two clearly different functions, like get_master_device / get_slave_device ? Or maybe having one get_associated_device function that always gives the other end of the master-slave pair is fine. Not sure whats better.
Thinking about it, having separate functions might make sense, since on one hand, master devices may have several slaves, thus requiring something like: GList * gdk_device_get_slave_devices (GdkDevice *device); And on the other hand, slave devices may not have a master devices (thus they are floating). gdk_device_get_associated_device() may remain for getting the paired pointer/keyboard for a device, being only useful for master devices, as it is now. This way the meaning of the returned device wouldn't vary.
Do you have a new patch ?
Ping
This has been done a while ago.