The function choose_xdisplay() calls open_display_sockets() which calls
ensure_x11_unix_dir().
We don't need to do that from within the loop though, as the directory
/tmp/.X11-unix is the same regardless of the display number.
Move the call to ensure_x11_unix_dir() from open_display_sockets() to
choose_xdisplay() prior to enter the display loop.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
In case of failure to open the display sockets, we would not propagatre
the error which can cause a crash when trying to show the error message.
Properly propagate the error to avoid the crash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
In the shutdown paths we check with the X11 display whether there's
remaining clients. However this happens in paths that happen after
the MetaX11Display vanished in the case of Xwayland crash.
Since in that situation the clients are forcibly vanishing too,
skip the client check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1677>
Closing automatically Xwayland once all relevant X11 clients are gone is
inherently racy, if a new client comes along right at the time we're
killing Xwayland.
Fixing the possible race conditions between mutter, Xwayland and the X11
clients may take some time.
Meanwhile, make that an experimental feature "autoclose-xwayland".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1673>
Currently, mutter checks for the presence of X11 windows to decide
whether or not Xwayland can be terminated, when Xwayland is started on
demand.
Unfortunately, not all X11 clients will map a window all the time, an
X11 client may keep the X11 connection opened after closing all its
windows. In that case, we may terminate Xwayland while there are some
X11 client connected still, and terminating Xwayland will also kill
those X11 clients.
To avoid that issue, check the X11 clients actually connected using the
XRes extension. The XRes extension provides the PID of the (local) X11
clients connected to the Xserver, so we need to match that against the
actual executable names, and compare with a list of known executables
that we can safely ignore, such as ibus-x11 or gsd-xsettings.
We also check against our own executable name, considering that the X11
window manager is also an X11 client connected to the Xserver.
Also, XRes returning the PID of local clients only is not a problem
considering that Xwayland does not listen to remote connections.
However, if the user spawns a client remotely on another system using
ssh tunneling (ssh -X), only clients which actually map a window will
be accounted for.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1537
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1671>
Changes in games between fullscreen and windowed modes may trigger
chaotic situations where the buffer and the frame size temporarily
disagree, producing rectangles with negative width/height. This is
usually followed by other updates that bring the pointer constraint
up to date.
This makes cairo panic and return an "error" empty region, which breaks
deeper down when using the region rectangles to apply the pointer
constraint.
If we hit this situation, ignore the frame rectangle, and just go with
the buffer rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1655>
Unfortunately there's situations where we can't fully rely on only
crossing events here. One such situation is pointer visibility changes
due to touch interaction, or e.g. after closing the lid.
In these situations the pointer position stays the same, picks the
same actor, yet we want to see the right surface as the pointer focus
again in the wayland side.
This used to happen on the first motion event after the pointer
visibility change before commit ad3f2b0b86, use motion events again
for picking so we don't break these usecases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1657>
These events may be emitted for touchpoints (in which case they contain
an event sequence). Ignore those as they are not relevant for pointer
picking, and shouldn't influence its focus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1657>
Just because of implementation details, this is only relevant to Wayland,
and is done via ::effects-completed handlers there. Ideally, Clutter should
notice by itself about effects starting, finishing, and affecting picking.
Doing this in generic code seems slightly cleaner in the interim.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
In the wayland code we are in synchronization with the events that
the ClutterStage is managing at the moment. Asking the ClutterSeat for
the pointer position gets ahead of the current events, and may result
in imprecise coordinates sent in wl_pointer.enter.
To be in consistence with the motion events that might be already
queued, we should ask the stage for the last known coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
As planned and prepared with the last commits, let ClutterStage take
care of tracking input devices and their respective actors. This means
we now can remove the old infrastructure for this from
ClutterInputDevice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1633>
To find XWayland output that should be the primary one, iterate through all
XWayland outputs, and compare their geometry to the geometry of the primary
logical monitor.
To avoid possible race conditions (Mutter's monitor configuration already
updated, but Xrandr not yet), set the output both after Randr notifications and
after 'monitors-changed' signal.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1407
Signed-off-by: Aleksandr Mezin <mezin.alexander@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1558>
When we're running under a polyinstantiated SELinux environment, we'll
likely start with an isolated and empty /tmp, meannig no /tmp/.X11-unix
directory to add things to. To make it possible to still function in
this kind of setup, make sure said directory exists.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1626>
Instead of using native backend platform data specifically, store
this info in ClutterMotionEvent. This includes time in usec since
it's just used for motion events, in the future it could make sense
to make these general to all events again, but it could make sense
to make ClutterEvent structs private before.
In order to express that a motion event has relative motion info,
the CLUTTER_EVENT_FLAG_RELATIVE_MOTION event flag has been added
for it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We had code in both backends that sort of independently associated
sequences to slots. Make both transform slots to sequences the same
way, so they may share the implementation convert those back to slots.
This helper now lives in Clutter API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We have this as platform-dependent data in the native backend, and
a bunch of fallback code done in place in the evcode users. Stop
making this platform-dependent data, and move it to the relevant
ClutterEvents.
The fallback code for the X11 backend case is about the same, but
now it is done directly by the X11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
The XIOErrorExitHandler expects (Display *, void *) whereas mutter uses
(Display *, MetaX11Display *).
That causes a warning at build time:
warning: passing argument 2 of ‘XSetIOErrorExitHandler’ from
incompatible pointer type [-Wincompatible-pointer-types]
813 | XSetIOErrorExitHandler (xdisplay, x_io_error_exit, display);
Actually, the MetaX11Display is not even used, so we can just use the
expected API and ignore the value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1621>
While browsing sysprof profiling reports, I saw surface-commit taking
significant times sometimes; trace attach too, to see whether such
things are due to e.g. texture uploads.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1616>
These use now more of a "pull" model, where they receive update
notifications and the relevant input position is queried, instead
of the coordinates being passed along.
This allows to treat cursor renderers all the same independently
of the device they track. This notifying of position changes should
ideally be more backend-y than core-y, a better location will be
figured out in future commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Instead of letting the wayland bits maintain an always-software
cursor renderer, let the cursor renderer be managed by the backend,
and only hook to it (as we do for pointer cursor) in the wayland
bits.
ATM, make the cursor renderer still always-software, although
ideally we should allow moving the HW cursor management between
renderers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Since we schedule frames for each stage view seperately now, surfaces receive
frame callbacks for each stage view they are visible on.
Only emit frame callbacks for the primary stage view.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
For X11 grabs, the pattern matching mechanism would simply ignore
applications which have neither WM_CLASS nor WM_NAME set.
When dealing with an override redirect window however, it is not
uncommon that these window have neither value set as these window are
supposed to be ignored by the window manager.
When the WM_CLASS or the WM_NAME is not set by the client, assume the
value is empty so the pattern matching can allow for these.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1249
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1254>
Commit 8bdd2aa7 would offset the window position by the difference
between the configured window size and the committed size from the
client to prevent the window from drifting while resizing.
This, however, did not take into account the actual geometry scale, so
when using any scale greater than 1, the window would rapidly drift away
due to that offset.
In order to solve this, we need to make sure we store away the pending
window configuration in the stage coordinate space, in order to not
loose precision. When we then calculate the offset given the result from
the client, it'll use the right scalars, while before, one scalar was in
surface coordinates, while the other in stage coordinates.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1490
