-
Olivier Fourdan authored
Trying to change the acceleration/threshold on Xwayland cannot work, and the corresponding handler xwl_pointer_control() is a no-op. Yet, an X11 client trying to change those on the touch device may possibly cause a crash because the touch device in Xwayland doesn't set that. Initialize the touch device's PtrFeedback to make sure that just cannot happen. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Closes: xorg/xserver#1137
ab76272a -
Olivier Fourdan authored
Trying to change the pointer control settings on a device without PtrFeedbackPtr would be a bug and a crash in the Xserver. Guard against that case by returning early with a BadImplementation error, that might kill the X11 client but the Xserver would survive. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Related: xorg/xserver#1137
dee2bb03 -
Peter Hutterer authored
In Weston, clicking the window decoration of an Xwayland client gives us a wl_pointer.button event immediately followed by a wl_pointer.leave event. The leave event does not contain any button state information, so the button remains logically down in the DIX. Once the pointer button is released, a wl_pointer.enter event is sent with the current button state (zero). This needs to trigger a ButtonRelease event but for that we need to ensure that the device is the same as the one we send ButtonPress events through. Fixes a regression introduced in a4095162. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com>
20c78f38 -
This fixes an problem left in f682e056 due to an incorrect cherry-pick. We must use old listener->listener to deliver the touch event. Otherwise grab won't let the event through and the abovementioned commit has no effect. Signed-off-by:
Povilas Kanapickas <povilas@radix.lt>
af17b5c4 -
Jeremy Huddleston Sequoia authored
There is a place where this code was called on the main thread. We're using a rather nasty anti-pattern to just call a block inline rather than synchonously calling it on the main thread if we're already on the main thread. This code could use a good overhaul, but I don't have time to rip it apart right now. This will address the immediate issue. Fixes: https://github.com/XQuartz/XQuartz/issues/40 Fixes: https://github.com/XQuartz/XQuartz/issues/48 Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
c9a3b14c