RunXkbComp passes an invalid file path to xkbcomp if there's no
trailing slash.

Closes: xorg/xserver#1146


Suggested-by: Dylan Baker <dylan.c.baker@intel.com>
(cherry picked from commit 6c51818a)

Since commit 20c78f38, we use the relative pointer for enter/leave
events.

However, sprite_check_lost_focus() which verifies whether the pointer has
left an Xwayland surface still explicitly check for the absolute
pointer.

As a result, no LeaveNotify event is emitted anymore now when the
pointer crosses from an Xwayland surface to a Wayland native one.

Make sure to check the last slave device against get_pointer_event() as
well, not just the absolute pointer.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
Acked-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes: 20c78f38 - xwayland: use get_pointer_device() for enter/leave
                  handling too
(cherry picked from commit d7391f38)

Xwayland 21.1.0 release candidate 2.

Olivier Fourdan authored 3 years ago and Michel Dänzer committed 3 years ago

Xwayland won't emulate XWarpPointer requests if the cursor is visible,
this is to avoid having the cursor jumping on screen and preventing
random X11 clients from controlling the pointer in Wayland, while
allowing games which use that mechanism with a hidden cursor to work in
Xwayland.

There are, however, games which tend to do it in the wrong order, i.e.
show the cursor before moving the pointer, and because Xwayland will not
allow an X11 client to move the pointer while the cursor is visible, the
requests will fail.

Add a workaround for such X11 clients, when the cursor is being shown,
keep it invisible until the cursor is actually moved. This way, X11
clients which show their cursor just before moving it would still have a
chance to succeed.

v2: Add a timeout to show the cursor for well behaved clients.
v3: Some cleanup (Michel)
v4: Do not cancel cursor delay when updating the cursor to avoid
    delaying cursor visibility indefinitely if the client keeps
    settings different cursors (Michel)

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Jaap Buurman <jaapbuurman@gmail.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Closes: xorg/xserver#734
(cherry picked from commit 97ed0048)

Adam Jackson authored 3 years ago and Michel Dänzer committed 3 years ago

This effectively changes the versioning to be as if xserver 21.0 was
xserver 1.21.0. This should keep any client-side version checks that
know about the Xorg 7.0 -> xserver 1.0 epoch from getting confused.

Fixes: 1e72c3ce "Bump version to 21.0.99.1"

Xwayland 21.1.0 release candidate 1.

Don't need the separate glamor_option variable anymore.

Fixes: 274d54d1 "meson: Build Xwayland unconditionally"

Olivier Fourdan authored 3 years ago and Michel Dänzer committed 3 years ago

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
(imported from commit dee2bb03)

Olivier Fourdan authored 3 years ago and Michel Dänzer committed 3 years ago

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
(cherry picked from commit ab76272a)

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.

However, routing just the buttons and axis events is not sufficient. 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.

Route those events along with enter/leave 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>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Related: xorg/xserver#1130
(cherry picked from commit a4095162)
(cherry picked from commit 20c78f38)

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
(cherry picked from commit 1abab61d)

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>
(cherry picked from commit 71817928)

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
(cherry picked from commit c5c5322a)

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
(cherry picked from commit ebdb2e26)

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
(cherry picked from commit b5e1f136)

Preparation for a 21.1 release.

We're keeping it for unit tests, but we don't want to ship it from this
branch.

Also disable Xvfb in CI for ninja test. It's still built and used for
unit tests as part of ninja dist, but we don't want to run XTS on Xvfb.

Not used on this branch.

Not used on this branch.

Not used anymore on this branch.

Only meson is supported for Xwayland-only releases.

Olivier Fourdan authored 4 years ago and Olivier Fourdan committed 3 years ago

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

Fixes: https://github.com/XQuartz/XQuartz/issues/30


Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>