-
0e272ac4
-
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
74aef85b -
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
20b86c40 -
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
6e6db055 -
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
5ad49102 -
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
f699aac2 -
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
cc9cf6f0 -
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
c0b2d3e0 -
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
aea15a76 -
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
59f22341 -
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
5e7c0762 -
Jeremy Huddleston Sequoia authored
Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
7d0bb7ed -
Jeremy Huddleston Sequoia authored
Fixes: https://github.com/XQuartz/XQuartz/issues/30 Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
520e7a13 -
When an X11 client issues an active grab on the keyboard, Xwayland forward this to the Wayland compositor using the Xwayland specific protocol "xwayland-keyboard-grab" if it can find the corresponding Xwayland window. Some X11 clients (typically older games) however try to issue the keyboard grab on the X11 root window, which has obviously no matching Xwayland window. In such a case, the grab is simply ignored and the game will not work as expected. To workaround that issue, if an X11 client issues a keyboard grab on the root window, Xwayland will search for a toplevel window belonging to the same X11 client that it can use as the grab window instead. This way, the grab can be forwarded to the Wayland compositor that can either grant or deny the request based on the window and its internal policies. The heuristic picks the first realized toplevel window belonging to the client so that the Wayland compositor will send it the keyboard events, and the Xserver grab mechanism will then take care of routing the events to the expected X11 window by itself. v2: Make the test more clear (Dor Askayo <dor.askayo@gmail.com>) Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Acked-by:
Jonas Ådahl <jadahl@gmail.com> See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/1249
c7730cfe -
Povilas Kanapickas authored
If a XI2 client started listening to touches due to a selection and then creates an active async grab that does not include touch events, then it currently won't get the touch end event which will produce inconsistent view of the pending touches. Note that we only need to consider touch listeners and can ignore pointer emulation. Under XI2 if a active grab replaces a passive implicit grab and the active grab does not include the button release event, the client won't get it either.
f682e056 -
This reverts commit 98e3db2a.
30e11535 -
Delivery of emulated events usually happens only to the owning client. If there are grabs, only the grabbing client may receive these events. This logic does not work during the touch event replay in DeactivatePointerGrab(), as the previous grab is no longer in the listener queue of the touch, so the next owner gets whole emulated event sequence. This may trigger implicit grabs. After replay, DeactivatePointerGrab() will update the global grab without regard to this new implicit grab, which leads to issues down the line. This change is effectively the same as 35e5a76c except that the change is limited to only emulated pointer events. Otherwise, in the case of a device grab we end up not sending any touch events to clients that selected XI_TouchOwnership event and should get touch events before they get ownership of touch sequence. Fixes #7 https://bugs.freedesktop.org/show_bug.cgi?id=96536
21312901 -
Olivier Fourdan authored
This add a new flag POINTER_RAWONLY for GetPointerEvents() which does pretty much the opposite of POINTER_NORAW. Basically, this tells GetPointerEvents() that we only want the DeviceChanged events and any raw events for this motion but no actual motion events. This is preliminary work for Xwayland to be able to use relative motion events for raw events. Xwayland would use absolute events for raw events, but some X11 clients (wrongly) assume raw events to be always relative. To allow such clients to work with Xwayland, it needs to switch to relative raw events (if those are available from the Wayland compositor). However, Xwayland cannot use relative motion events for actual pointer location because that would cause a drift over time, the pointer being actually controlled by the Wayland compositor. So Xwayland needs to be able to send only relative raw events, hence this API. Bump the ABI_XINPUT_VERSION minor version to reflect that API addition. v2: Actually avoid sending motion events (Peter) v3: Keep sending raw emulated events with RAWONLY (Peter) Suggested-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Related: xorg/xserver#1130
b5e1f136 -
Olivier Fourdan authored
That's what evdev/libinput drivers do. Suggested-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Related: xorg/xserver#1130
ebdb2e26 -
Olivier Fourdan authored
Xwayland supports relative motion events from the Wayland compositor via the relative-pointer protocol, and converts those to the absolute range in device units for raw events. Some X11 clients however wrongly assume relative values in the axis values even for devices explicitly labeled as absolute. While this is a bug in the client, such applications would work fine in plain Xorg but not with Xwayland. To avoid that issue, use the relative values for raw events without conversion, so that such application continue to work in Xwayland. Thanks Peter for figuring out the root cause. v2: Don't duplicate relative and absolute events (Peter) v3: Use POINTER_RAWONLY (Peter) Suggested-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Closes: xorg/xserver#1130
c5c5322a -
Olivier Fourdan authored
This is a cleanup patch, no functional change. Split the function dispatch_pointer_motion_event() into three separate simpler functions, relative motion with a warp emulator, relative motion and absolute motion. This makes the code a lot easier to read for me, rather than having everything in a single function with nested if/else conditions. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net>
71817928 -
Olivier Fourdan authored
The relative pointer only has 2 axis, if we want to route the mouse wheel events to that device, we need to add the axis definition, similar to what is done for the absolute pointer. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Related: xorg/xserver#1130
1abab61d -
Olivier Fourdan authored
We are using the relative pointer for motion events, but buttons and axis events still go through the absolute pointer device. That means additional DeviceChanged events that could be avoided if the buttons and axis events were coming from the same device as motion events. Route those events to the relative pointer if available so that motion, buttons and axis events come from the same device (most of the time). Suggested-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Related: xorg/xserver#1130
a4095162
- Xi/exevents.c 12 additions, 8 deletionsXi/exevents.c
- configure.ac 0 additions, 4 deletionsconfigure.ac
- dix/events.c 16 additions, 3 deletionsdix/events.c
- dix/getevents.c 29 additions, 24 deletionsdix/getevents.c
- hw/xfree86/common/xf86Module.h 1 addition, 1 deletionhw/xfree86/common/xf86Module.h
- hw/xquartz/GL/indirect.c 0 additions, 2 deletionshw/xquartz/GL/indirect.c
- hw/xquartz/Makefile.am 2 additions, 4 deletionshw/xquartz/Makefile.am
- hw/xquartz/X11Application.m 12 additions, 66 deletionshw/xquartz/X11Application.m
- hw/xquartz/X11Controller.h 1 addition, 14 deletionshw/xquartz/X11Controller.h
- hw/xquartz/X11Controller.m 0 additions, 15 deletionshw/xquartz/X11Controller.m
- hw/xquartz/applewmExt.h 0 additions, 6 deletionshw/xquartz/applewmExt.h
- hw/xquartz/console_redirect.c 0 additions, 482 deletionshw/xquartz/console_redirect.c
- hw/xquartz/console_redirect.h 0 additions, 46 deletionshw/xquartz/console_redirect.h
- hw/xquartz/mach-startup/bundle-main.c 4 additions, 65 deletionshw/xquartz/mach-startup/bundle-main.c
- hw/xquartz/mach-startup/stub.c 0 additions, 15 deletionshw/xquartz/mach-startup/stub.c
- hw/xquartz/man/Xquartz.man 1 addition, 1 deletionhw/xquartz/man/Xquartz.man
- hw/xquartz/pbproxy/pbproxy.h 0 additions, 11 deletionshw/xquartz/pbproxy/pbproxy.h
- hw/xquartz/pbproxy/x-selection.m 0 additions, 28 deletionshw/xquartz/pbproxy/x-selection.m
- hw/xquartz/quartz.c 0 additions, 6 deletionshw/xquartz/quartz.c
- hw/xquartz/quartzKeyboard.c 1 addition, 148 deletionshw/xquartz/quartzKeyboard.c