Before this commit, sudo x11-app, e.g. sudo gvim /etc/some-file, fails
when running a Wayland session. Where as doing this under a "GNOME on Xorg"
session works fine. For a user switching from the Xorg session to the
Wayland session, this is regression, which we want to avoid.
This commit fixes this by creating and passing an xauth file to Xwayland when
mutter starts it. Just like gdm or startx pass a xauth file to Xorg when they
start Xorg.
Fixes#643https://gitlab.gnome.org/GNOME/mutter/issues/643
As with the commits earlier, this also adds const qualifiers where
expected. However, the const variables are casted to non-const variants
so they can be passed to glib functions that take non-const variants but
expect const-like input.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
This protocol supersedes the internal gtk_text_input protocol that
was in place. Functionally it is very similar, with just some more
verbosity in both ways (text_change_cause, .done event), and some
improvements wrt the pre-edit text styling.
One of the current limitations of EGLStreams is that there's no way to
resize a surface consumer without re-creating the entire stream.
Therefore, while resizing, clients will send wl_surface::attach requests
so the compositor can re-create its endpoint of the stream, but no
buffer will be available actually. If we proceed with the rest of the
attach operation we'll be presenting an empty buffer.
In order to fix this, a separate wl_eglstream_controller protocol has
been introduced that clients can use to request a stream re-creation
without overloading wl_surface::attach for that purpose.
This change adds the required logic to create the corresponding
wl_eglstream_controller global interface that clients can bind to.
Whenever a client requests a stream to be created, we just need to
create and realize the new EGLStream buffer. The same buffer resource
will be given at a later time to wl_surface::attach, whenever new
content is made available by the application, so we can proceed to
acquire the stream buffer and update the surface state.
https://bugzilla.gnome.org/show_bug.cgi?id=782575
Instead of scheduling a meta_later, keep track of the unassociated
windows, and look for matches as soon as the MetaWaylandSurface is
created on our side.
This will ensure the surface is given the Xwayland role before receiving
the first wl_surface.commit.
This commit moves out non-core wl_surface related code into separate
code units, while renaming types to fit a common scheme. The changes
done are:
* ClutterActor based surface roles built upon
MetaWalyandSurfaceRoleActorSurface. This object has been renamed to
MetaWaylandActorSurface and related functionality has moved into
meta-wayland-actor-surface.c.
* The code related to roles backed by a MetaWindow (i.e. built upon
MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c
* The majority of subsurface related code was moved into into
meta-wayland-subsurface.c and the object was renamed
MetaWaylandSubsurface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=791938
Offer the text-input interface global, so it can be used by clients. The
MetaWaylandSeat will also let MetaWaylandTextInput intercept key events
before the keyboard interface handles those.
This protocol is limited to Xwayland only and is not visible/usable by
any other client.
Mutter uses the following mechanisms to determine if an X11 client
should be granted a grab:
- is "xwayland-allow-grabs" set?
- if set, is the client blacklisted?
- otherwise, has the client set the X11 window property
_XWAYLAND_MAY_GRAB_KEYBOARD on the window using a client message?
- if not, is it a client white-listed either via the default system
list or the settings "xwayland-grab-access-rules"?
https://bugzilla.gnome.org/show_bug.cgi?id=783342
When cleaning up the display name string management, the display name
string retrieved from libwayland-server was also passed to free() on
clean up. This is invalid as the display name string ownership is not
transferred to us. Fix this by strdup:ing the string before saving it.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
In order to give the clients the best chance to bind the wl_output
before we later remove it (for example on fast hot plugs or in the test
suite), flush the client sockets after creating the global.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
Plug the new MetaInhbitShortcutsDialog to the relevant Wayland protocol
implementation.
Also, remember the last user choice for a given surface to avoid asking
continuously the same question.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
Add a mechanism to MetaWaylandSurface that inhibits compositor's own
shortcuts when the surface has input focus, so that clients can receive
all key events regardless of the compositor own shortcuts.
This will help with implementing "fake" active grabs in Wayland and
XWayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
This commits adds support for exporting xdg_surface handles via
xdg_exporter and importing them via xdg_importer.
This bumps the required wayland-protocols version to 1.6.
https://bugzilla.gnome.org/show_bug.cgi?id=769786
meta_wayland_tablet_manager_update()/handle_event() are called before
the MetaWaylandSeat counterparts. If the event comes from a device
managed by MetaWaylandTabletManager, the event will be exclusively handled
by it.
The wp_pointer_constraints protocol is a protocol which enables clients
to manipulate the behavior of the pointer cursor associated with a seat.
Currently available constraints are locking the pointer to a static
position, and confining the pointer to a given region.
Currently locking is fully implemented, and confining is implemented for
rectangular confinement regions.
What else is lacking is less troublesome semantics for enabling the lock
or confinement; currently the only requirement implemented is that the
window that appears focused is the one that may aquire the lock.
This means that a pointer could be 'stolen' by creating a new window that
receives active focus, or when using focus-follows-mouse, a pointer
passes a window that has requested a lock. This semantics can be changed
and the protocol itself allows any semantics as seems fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
Add support for sending relative pointer motion deltas to clients who
request such events by creating wp_relative_pointer objects via
wp_relative_pointer_manager.
This currently implements the unstable version 1 from wayland-protocols.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
The code currently implements a function, get_time, that
fetches a timestamp. That duplicates code already in glib,
and the glib implementation is better, anyway, since it doesn't
skew backward when the system clock is changed.
This commit changes the code to use g_get_monotonic_time and
drop the get_time function.
https://bugzilla.gnome.org/show_bug.cgi?id=761613
During xwayland initialization we run main loop and dispatch wayland
events, so that xwayland can initialize. If some client during this
phase connects and creates surface, mutter crashes because
it is not initialized yet. If we bind wayland socket after xwayland
is initialized and main loop is not running anymore, no client can
connect to mutter during initialization and that is what we want.
https://bugzilla.gnome.org/show_bug.cgi?id=751845
If the user Alt-Tabs out of the window, we will be left thinking
the Alt key is still pressed since we don't see a release for it.
Solve this and other related issues for the nested X11 compositor
by selecting for KeymapStateMask which causes a KeymapNotify event
to be sent after each FocusIn, and when we get these events, update
the internal XKB state and send any necessary modifiers events to
clients.
https://bugzilla.gnome.org/show_bug.cgi?id=753948
The global wl_pointer_gestures object is now created, effectively
bridging pinch/swipe gestures with clients, so they're now
accessible to clients implementing the protocol.
MetaWaylandFrameCallback has been added a surface field, which is then
checked when destroying the surfaces. This prevents unintended callbacks
to run after a surface has been destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=745163
