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.
We might unset focus, or already be out of focus (e.g. an X11 client or
clutter text entry is focused) when a text-input state is committed by
the client. We handled this before, except when text input was
explicitly disabled by the client, the Wayland text-input was in focus
by the input method, and it focused itself out.
Simplify the logic a bit by just dropping the state on the floor in all
cases where after any potential focus changes were done, we are not
focused.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/353
When repicking after a surface was destroyed, if the destroyed surface
was the drag focus, we'd try to focus-out from it after it was
destroyed, causing a NULL pointer dereference.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/336
To avoid a known race condition in the wl_output protocol documented in
https://phabricator.freedesktop.org/T7722, mutter delays the `wl_output`
destruction but nullify the `logical_monitor` associated with the
`wl_output` and the binding routine `bind_output()` makes sure not to
send wl_output events if the `logical_monitor` is `NULL` (see commit
1923db97).
The binding routine for `xdg_output` however does not check for such a
condition, hence if the output configuration changes while a client is
binding to xdg-output (typically Xwayland at startup), mutter would
crash while trying to access the `logical_monitor` which was nullified
by the change in configuration.
Just like `bind_output()` does for wl_output, do not send xdg-output
events if there is no `logical_monitor` yet.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
When we update the main monitor, there is a rule that makes it so that
popup windows use the same main monitor as their parent. In the commit
f4d07caa38 the call that updates and
fetches the main monitor of the toplevel accidentally changed to update
from itself, causing a indefinite recursion eventually resulting in a
crash.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/279
As with xdg-toplevel, a gtk-surface can be unmanaged by the compositor
without the client knowing about it, meaning the client may still send
updates and make requests. Handle this gracefully by ignoring them. The
client needs to reset all the state anyway, if it wants to remap the
same surface.
https://gitlab.gnome.org/GNOME/mutter/issues/240
As with xdg-toplevel proper, a legacy xdg-toplevel can be unmanaged by
the compositor without the client knowing about it, meaning the client
may still send updates and make requests. Handle this gracefully by
ignoring them. The client needs to reassign the surface the legacy
xdg-toplevel role again, if it wants to remap the same surface, meaning
all state would be reset anyway.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/240
A toplevel window can be unmanaged without the client knowing it (e.g. a
modal dialog being unmapped together with its parent. When this has
happened, take frame callbacks queued on a commit and cache them on the
generic surface queue. If the toplevel is to be remapped because the
surface was reassigned the toplevel role, the cached frame callbacks
will be queued on the surface actor and dispatched accordingly.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A window can be unmanaged without asking the client to do it, for
example as a side effect of a parent window being unmanaged, if the
child window was a attached dialog.
This means that the client might still make requests post updates to it
after that it was unmapped. Handle this gracefully by NULL-checking the
surface's MetaWindow pointer. We're not loosing any state due to this,
as if the client wants to map the same surface again, it needs to either
reassign it the toplevel role, or reset the xdg-toplevel, both resulting
in all state being lost anyway.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A toplevel window can be unmanaged without the client knowing it (e.g. a
modal dialog being unmapped together with its parent. When this has
happened, take frame callbacks queued on a commit and cache them on the
generic surface queue. If the toplevel is to be remapped, either because
the surface was reassigned the toplevel role, or if it was reset and
remapped, the cached frame callbacks will be queued on the surface actor
and dispatched accordingly.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A popup can be reset, and when that happens, window and actor are
destroyed, and won't be created again unless it is reassigned the
popup role.
If a client queued frame callbacks when resetting a popup, the frame
callbacks would be left in the pending state, as they were not queued on
the actor, meaning we'd hit an assert about the frame callbacks not
being handled. Fix this by caching them on the MetaWaylandSurface, so
that they either are cleaned up on destruction, or queued on the actor
would the surface be re-assigned the popup role.
https://gitlab.gnome.org/GNOME/mutter/issues/240
Sometimes it may be useful for roles to put callbacks in the generic
surface frame callback queue. The surface frame callback queue will
either eventually be processed on the next surface role assignment that
places the frame callbacks in a role specific queue, processed at some
other point in time by a role, or cleaned up on surface destruction.
https://gitlab.gnome.org/GNOME/mutter/issues/240
When a xdg-toplevel is reset, the window and actor are recreated, and
all state is cleared. When this happened, we earlied out from the
xdg-toplevel commit handler, which would mean that if the client had
queued frame callbacks when resetting, they'd be left in the pending
commit state, later hitting an assert as they were not handled.
Fix this by queuing the frame callbacks no the new actor, so that they
are emitted whenever the actor is eventually painted.
https://gitlab.gnome.org/GNOME/mutter/issues/240
This was done for input regions in commit 718a89eb2f (Thanks Jonas
for the archaeology!) but opaque regions follow the same scaling.
This brings less evident issues as opaque regions are just used for
culling optimizations.
Commit 6a92c6f83 unintendedly broke input/opaque region calculations
on hidpi. Most visible side effect is that clicking is only allowed
in the upper-left quarter of windows.
The surface coordinates are returned in logical unscaled buffer
size. We're however interested in actor coordinates (thus real
pixels) here.
As it is a bit of a detour how the scale to be applied is calculated,
refactor a meta_wayland_actor_surface_get_geometry_scale() function
that we can use it here, and use it consistently for surface size and
the given regions.
Commit a3da4b8d5b changed updating of
window monitors to always use take affect when it was done from a
non-user operation. This could cause feed back loops when a non-user
driven operation would trigger the changing of a monitor, which itself
would trigger changing of the monitor again due to a window scale
change.
The reason for the change, was that when the window monitor changed due
to a hot plug, if it didn't actually change, eventually the window
monitor pointer would be pointing to freed memory.
Instead of force updating the monitor on all non-user operations, just
do it on hot plugs. This allows for the feedback loop preventing logic
to still do what its supposed to do, without risking dangling pointers
on hot plugs.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/189
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/192
The bool determines whether the call was directly from a user operation
or not. To add more state into the call without having to add more
boolenas, change the boolean to a flag (so far with 'none' and 'user-op'
as possible values). No functional changes were made.
https://gitlab.gnome.org/GNOME/mutter/issues/192
As per specification
> The compositor ignores the parts of the input region that
> fall outside of the surface.
> The compositor ignores the parts of the opaque region that
> fall outside of the surface
This fixes culling problems under certain conditions.
Currently xdg-shell applies a geometry set with set_window_geometry
unconditionally. But the specification requires:
> When applied, the effective window geometry will be
> the set window geometry clamped to the bounding rectangle of the
> combined geometry of the surface of the xdg_surface and the
> associated subsurfaces.
This is especially important to implement viewporter and
transformation.
By using the shm file when sending the keymap to all clients, we
effectively allows any client to change the keymap, as any client has
the ability to change the content of the file. Sending a read-only file
descriptor, or making the file itself read-only before unlinking, can
be worked around by the client by using chmod(2) and open(2) on
/proc/<pid>/<fd>.
Using memfd could potentially solve this issue, but as the usage of
mmap with MAP_SHARED is wide spread among clients, such a change can
not be introduced without causing wide spread compatibility issues.
So, to avoid allowing clients to interfere with each other, create a
separate shm file for each wl_keyboard resource when sending the
keymap. We could eventually do this per client, but in most cases,
there will only be one wl_keyboard resource per client anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=784206
If a client maps a popup in response to a key-down event, but the
mapping doesn't occur until after the user has already released the same
button, we'd immediately dismiss the popup. This is problematic, as one
often presses and releases a key quite quickly, meaning any popup mapped
on key-down are likely to be dismissed.
Avoid this race condition by accepting serials for key down events, if
the most recent key-up event had the same keycode.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/180
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.
If the surface is gone before `meta_xwayland_keyboard_grab_end()` is
called, we would bail out early leaving an empty grab, which will cause
a segfault as soon as a key is pressed later on.
Make sure we clean up the keyboard grab even if the surface is gone.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/255
The string used to point to memory owned by libwayland-server, but
with the ability to override the display name, we took over ownership
by copying the string as necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
If a client asks for xdg-output before we have set the output's logical
monitor, we would end up crashing with a NULL pointer dereference.
Make sure we clear the resource's user data when marking an output as
inert on monitor change so that we don't end up with a Wayland output
without a logical monitor.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
meta_window_wayland_update_main_monitor() would skip the monitor update
if the difference in scale between the old and the new monitor would
cause another monitor change.
While this is suitable when the monitor change results from a user
interactively moving the surface between monitors of different scales,
this can leave dangling pointers to freed monitors when this is
triggered by a change of monitor configuration.
Make sure we update the monitor unconditionally if not from a user
operation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189
- Stop using CurrentTime, introduce META_CURRENT_TIME
- Use g_get_monotonic_time () instead of relying on an
X server running and making roundtrip to it
https://bugzilla.gnome.org/show_bug.cgi?id=759538
They are X11 specific functions, used for X11 code. They have been
improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and
gdk_x11_display_error_trap_* functions, instead of current code.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Commit 22723ca37 moved buffer realization to
meta_wayland_surface_commit() so that it wouldn't be part of
meta_wayland_buffer_attach().
However, creation of dmabuf buffers would call into
meta_wayland_buffer_attach() directly without realizing the buffer
first. attach() would then fail and mutter would effectively shut down
any clients using the zwp_linux_dmabuf protocol (note that if such
client was Xwayland, mutter itself would shut down as well).
Add the missing bit in order to make zwp_linux_dmabuf protocol work
again.
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
Clients using EGLStream-backed buffers will expect the stream to be
functional after wl_surface::attach(). That means the compositor-side
stream must be created and a consumer attached to it.
To resolve the above, this change realizes buffers even when the attach
operation is deferred (e.g. synchronized subsurfaces).
https://bugzilla.gnome.org/show_bug.cgi?id=782575
When dealing with synchronized subsurfaces, we defer buffer attachments
until the parent surface state is applied.
That causes interaction issues with EGLStream backed buffers, as the
client expects the compositor-side stream to be functional after it
requests a wl_surface::attach.
By allowing the compositor to realize buffers without attaching them, we
could resolve the issue above if we define a realized EGLStream buffer
as a functional EGLStream (EGLStream + attached consumer).
This change moves the texture consumer creation part from the attach
function to the realize one.
https://bugzilla.gnome.org/show_bug.cgi?id=782575
It knows better when it's needed. For now, just do it just as before,
before drawing. Eventually, we can conditionalize where to realize
depending on the cursor sprite position.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Use a common entry point into the cursor renderer implementations HW
cursor realization paths for all cursor sprite types. This is in
preparation for realizing at more strategic times.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Introduce a new type MetaCursorSpriteXcursor that is a MetaCursorSprite
implementation backed by Xcursor images. A plain MetaCursorSprite can
still be created "bare bone", but must be manually provided with a
texture. These usages will eventually be wrapped into new
MetaCursorSprite types while turning MetaCursorSprite into an abstract
type.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Rename the two cursor role types according to the convention used by the
other roles. This means that MetaWaylandSurfaceRoleCursor was renamed to
MetaWaylandCursorSurface, and MetaWaylandSurfaceRoleTabletCursor was
renamed to MetaWaylandTabletCursorSurface. The corresponding filenames
were renamed accordingly too.
https://gitlab.gnome.org/GNOME/mutter/issues/77
And ensure the actor is no longer reactive even though it might live longer
because of close effects, GCs, and whatnot. This ensures the actor is not
eligible for pointer picking within the destruction of its surface.
Closes: #188
The order of role creation is undetermined, so we can't account that
the parent surface will have a role (and an actor) at the time of
creating the wl_subsurface role for a child surface.
So we must do it both ways, add the subsurface as a child on
get_subsurface() if the parent already got a role, and lazily add
child subsurface actors to the current one if the parent surface got
it at a later point.
Related: #132
After 20176d03, the Wayland backend only synchronizes with the
compositor after a geometry was set, and it was different from
the current geometry.
That commit was mistakenly comparing the geometry before chaining
up, which would yield a false negative on the case where the
client didn't call set_geometry() before commit().
Fix that by caching the old geometry locally, chain up (and thus
apply the new geometry rectangle), then comparing the old and
current geometry rectangles.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/150
The destroyed signal that was emitted if an imported surface was not
available when created, for example if the handle was invalid or
already unexported, was emitted on the wrong resource.
To check if a subsurface is effectively synchronized, we walk the
subsurface hierarchy to look for a non-subsurface parent or a subsurface
being synchronized.
However, when client is closing, the parent surface might already be
gone, in which case we end up with a surface being NULL which causes a
NULL pointer dereference and a crash.
Check if the parent surface is NULL to avoid the crash, and consider
it's already synchronized if it is NULL to avoid further updates.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/124
The current implementation of the XdgSurface v6 protocol does not check
if the window changed before calling meta_window_wayland_move_resize().
The problem with this approach is that calling this function is a costly
operation since we enter the compositor side. In GNOME Shell case, it is
in JavaScript, which triggers a GJS trampoline. Calling this function on
every mouse movement is naturally as terrible as it could be - and is
exactly what happens now.
This commit adds the necessary checks to only call move_resize() when
the window actually changed, or when it needs to be updated.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Issue: #78
This will be used by the next commit to determine when a window
geometry change should be ignored or not. Normally, it would be
enough to just check if the position and sizes changed.
The position, in this case, is relative to the client buffer, not
the global position. But because it is not global, there is one,
admitedly unlikely, situation where the window state is updated
while the client size and relative positions don't change.
One can trigger this by e.g. tiling the window to the half-left of
the monitor, then immediately tile it to half-right. In this case,
the window didn't change, just it's state, but nonetheless we need
to notify the compositor and run the full move/resize routines.
When that case happens, though, the MetaWindowWayland is tracking
the pending state change or a move. And this is what we need to
expose.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Issue: #78
In the old, synchronous X.org world, we could assume that
a state change always meant a synchronizing the window
geometry right after. After firing an operation that
would change the window state, such as maximizing or
tiling the window,
With Wayland, however, this is not valid anymore, since
Wayland is asynchronous. In this scenario, we call
meta_window_move_resize_internal() twice: when the user
executes an state-changing operation, and when the server
ACKs this operation. This breaks the previous assumptions,
and as a consequence, it breaks the GNOME Shell animations
in Wayland.
The solution is giving the MetaWindow control over the time
when the window geometry is synchronized with the compositor.
That is done by introducing a new result flag. Wayland asks
for a compositor sync after receiving an ACK from the server,
while X11 asks for it right away.
Fixes#78
These paths implicitly relied on the forwarded IM key events having
a source_device backed by a real HW device. This assumption is no
longer held true since commit b5328c977.
Explicitly check the INPUT_METHOD flag so they are handled as they
should despite not being "real HW" events.
We used to maintain an actor for cursors, even though we would possibly
use hw overlays or even some other overlay actor for those. This happens
no more, so check whether we are dealing with an actor-backed surface role
before fiddling with it.
All surface roles that do need a backing actor inherit from this
class, it makes sense to move actor management there. This also
means the MetaWaylandActorSurface is in charge of emitting
::geometry-changed on the MetaWaylandSurface.
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.
In the synchronized subsurface case, the destination list may
contain other elements from previous wl_surface.commit calls.
Resetting the list will leave those dangling frame callbacks
that will lead to invalid writes when those get to be destroyed
(eg. on client shutdown).
Right now if Xwayland crashes, we crash, too.
On some level that makes sense, since we're supposed to control the
lifecycle of Xwayland, and by it crashing we've lost that control.
But practically speaking, the knock-on crash adds noise to the logs,
bug trackers, and retrace servers that only makes debugging harder.
And the crash isn't something mutter can "fix", since it's
ultimately from a bug in Xwayland anyway.
This commit makes mutter exit instead of crash if Xwayland goes away
unexpectedly.
Right now we explicitly g_clear_error any error we find, but that
makes it tricky to return early from the function, which a
subsequent commit will want to to do.
This commit switches GError to use g_autoptr so the error clearing
happens automatically.
When moving the pending state of an effectively synchronized subsurface
so it is applied together with the parent, perform a merge of the source
MetaWaylandPendingState into the destination one, instead of simply
overwriting the struct.
The other approach had 2 kind of leaks, one that would happen everytime
a wl_surface.commit happens on a sync subsurface (both surface/buffer
damage regions are leaked). The other more unlikely one would apply on
the rest of pending state data, happening whenever the compositor gets
>1 wl_surface.commit calls on the subsurface before the parent surface
gets its own.
The function has also been renamed to use the more descriptive "merge"
term.
Related: gnome-shell#64
Compositor effects change the actor size and position, which can lead to
inconsistent output enter/leave notifications, leaving clients' surfaces
without any output set.
Update output enter/leave notifications after all compositor effects are
completed so that we give clients accurate output location.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/104
When using two monitors size by side with different scales, once the
cursor moves from one output to another one, its size changes based on
the scale of the given output.
Changing the size of the cursor can cause the cursor area to change
output again if the hotspot is not exactly at the top left corner of the
area, causing the texture of the cursor to change, which will trigger
another output change, so on and so forth causing continuous surface
enter/leave event which flood the clients and eventually kill them.
Change the logic to use only the actual cursor position to determine if
its on the given logical monitor, so that it remains immune to scale
changes induced by output scale differences.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/83
This state tracks hardware devices' state, thus shouldn't be triggered by
events that were emulated/forwarded by the IM. Those may include modifiers
and would result in xkb_state being doubly set, and possibly stuck.
https://gitlab.gnome.org/GNOME/mutter/issues/74Closes: #74
Commit d714a94d9 added support for stable xdg-shell surfaces while
preserving old unstable zxdg-shell v6 ones, but committed a mistake
in checking for both in the xdg_exporter.export error condition
paths. We want to check that the surface is neither of both.
https://gitlab.gnome.org/GNOME/mutter/issues/63Closes: #63
Make the Wayland objects push the state relevant to their role to the
MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state
from the associated surface.
This makes the relationship between the actor and the objects that
constructs it more clear; the actor is a drawable that the protocol
objects control, not the other way around.
This will make it easier to "detach" a surface actor from a surface,
which is necessary when unmapping a window while the underlying surface
is yet to be destroyed and potentially reused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=791938
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
If text_input_enable() is called when there no active IM (eg. running plain
mutter), some ClutterInputFocus method calls that are not allowed while
unfocused will end up called, triggering critical warnings.
If there is no IM return early here, all other calls are superfluous then.
We currently don't handle NULLs on these correctly, yet they can be
so when running nested. Just refrain from sending those wp_tablet(_pad)
events in that case.
The window checks in the XPropertyEvent handler were wrong both
ways, so transfers would be left stale after the first chunk was
dealt with.
https://gitlab.gnome.org/GNOME/mutter/issues/1Closes: #1
Plain input stream read() calls don't provide hard guarantees about
the number of bytes read, but the async method callback sort of
relies on bytes being less than requested only when reaching the
end of the transmitted data. If that happens mid transfer, that
doesn't bode well.
This is actually the behavior of g_input_stream_read_all(), so
switch to using it.
If for whatever reason, there are stalled files in /tmp/.X11-unix/ the
bind() to the abstract socket will succeed but not the bind() to the
to the UNIX socket.
This causes gnome-shell/mutter to fail because it cannot start Xwayland
(while it could actually, by using a different display).
In case of failure to bind to the UNIX socket, try the next display
instead of failing, to avoid stalled entries in /tmp/.X11-unix.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/13
The shortcut inhibitor protocol states that the “active” event should be
sent every time compositor shortcuts are inhibited on behalf of the
surface.
However, mutter would send that event only if the surface is focused,
which might not be the case if focus is on a shell surface.
Send the “active” event unconditionally to match the protocol
definition.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/10
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 is the implementation of the internal text-input protocol that will
be used to communicate IMs (to be implemented by gnome-shell) with clients.
The text_input protocol has its own focus expressed through enter/leave
events, that will typically follow the keyboard's.
The client will be able to communicate its current status (eg. focus state,
cursor rectangle in surface coordinates, text surrounding the cursor
position, ...) and will receive commands from the compositor (eg. preedit
text, committing a string, ...).
Whenever there is an active input method, the compositor will route key
events directly through it. The client will not receive wl_keyboard
events if the event is consumed by the IM.
Issuing a shortcut inhibit request for a surface without a window set
will lead to a crash when trying to show the shortcut inhibitor dialog.
In such a case, it's safer to deny the request.
https://bugzilla.gnome.org/show_bug.cgi?id=792599
The events might fall through if there's no corresponding active
pointer/keyboard/touch interface. Barring bugs this should be safe to do,
just a bit wasteful.
When maximizing a window, the previous location is saved so that
un-maximize would restore the same original window location.
However, if a Wayland client starts with a window maximized, the
previous location will be 0x0, so if we have to force placement in
xdg_toplevel_set_maximized(), we should update the location as well so
that the window is placed on the right monitor when un-maximizing.
For that purpose, add a new flag to force the update of the window
location, and use that flag from xdg_toplevel_set_maximized().
https://bugzilla.gnome.org/show_bug.cgi?id=783901
When closing a window and showing a new one, the new one may not be
granted input focus until it gets a buffer on Wayland.
If another window is chosen to receive focus and raised on top of stack,
the newly mapped window is focused but placed underneath that other
window.
Meaning that for Wayland surfaces, we need to defer adding the window to
the stack until we actually get to show it, once we have a buffer
attached.
Rather that checking the windowing backend prior to decide if a window
is stackable or not, introduce a new vfunc is_stackable() which tells
if a window should be added to the stack regardless of the underlying
windowing system.
Also add meta_window_is_in_stack() API rather than checking the stack
position directly (replacing the define WINDOW_IN_STACK only available
in stack.c) and remove a window from the stack only if it is present
in the stack, so that the test in meta_stack_remote() becomes
irrelevant.
https://bugzilla.gnome.org/show_bug.cgi?id=780820
Wayland clients using the wl_shell interface were never receiving mouse
input. It meant they also couldn't be raised with a click.
This was because the call to meta_wayland_surface_set_window for wl_shell
surfaces did nothing while surface->window == window already. As such, it
never called clutter_actor_set_reactive() and the wl_shell window remained
a non-reactive actor.
Just make sure surface->window isn't already set before calling
meta_wayland_surface_set_window so it can actually do what it's meant to.
https://bugzilla.gnome.org/show_bug.cgi?id=790309
If input happens to be grabbed somewhere along the shell, and ungrabbed
while a touch operation is ongoing, the wayland bits will happily start
sending wl_touch.update events from an undeterminate point, without
clients having ever received wl_touch.down for that id.
Consider those touches grabbed for the entirety of their lifetime, if
wl_touch.down wasn't received by the client, no other events will.
https://bugzilla.gnome.org/show_bug.cgi?id=776220
On VT switch, the xkb state layout index is lost and reset to the first
group, so if the first layout is not the last one being used, the xkb
state used in both meta-wayland-keyboard.c and clutter/evdev will be
desynchronized with the keyboard source indicator in the gnome-shell UI.
Save the effective layout chosen along with the seat so it can be
restored when reclaiming devices.
Use the saved layout index from the clutter/evdev's seat to restore the
layout in meta-wayland-keyboard, so that switching VT doesn't reset the
layout and causes further discrepancies with the layout indicator in the
gnome-shell UI.
https://bugzilla.gnome.org/show_bug.cgi?id=791383
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
Add a new client message "_XWAYLAND_MAY_GRAB_KEYBOARD" that X11 clients
can use to tell mutter this is a well behaving X11 client so it may
grant the keyboard grabs when requested.
An X11 client wishing to be granted Xwayland grabs by gnome-shell/mutter
must send a ClientMessage to the root window with:
- message_type set to "_XWAYLAND_MAY_GRAB_KEYBOARD"
- window set to the xid of the window on which the grab is to be issued
- data.l[0] to a non-zero value
Note: Sending this client message when running a plain native X11
environment would have no effect.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
MetaWindowXwayland derives from MetaWindowX11 to allow for some Xwayland
specific vfunc that wouldn't apply to plain X11 windows, such as
shortcut inhibit routines.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
The xdg-output protocol aims at describing outputs in way which is
more in line with the concept of an output on desktop oriented systems.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
This is however much useful for Xwayland to advertise the output size
and position to X11 clients which need this to configure their surfaces
in the global compositor space as the compositor may apply a different
scale from what is advertised by the output scaling property (to achieve
fractional scaling, for example).
This was added in wayland-protocols 1.10.
https://bugzilla.gnome.org/show_bug.cgi?id=787363
If a parent doesn't have a window, it means it could have been
dismissed (for example due to a input serial race), but the more recent
popup might win the input serial race and try to map anyway. This would
result in a crash later on when trying to process the placement rule,
as the parent already has no window.
https://bugzilla.gnome.org/show_bug.cgi?id=790358
Move the top-most-popup correctness check to the finish_popup_setup()
function after checking the serial. If we pass the serial check, we
should have reached a state that if there are any popups they should be
the one from the same client.
Also avoid failing a client that correctly set the top-most popup at map
time, but where at the time of processing the top most popup have
already been dismissed by the compositor for some arbitrary reason.
https://bugzilla.gnome.org/show_bug.cgi?id=790358
MetaWaylandKeyboard maintains its own xkb_state used to update Wayland
clients.
Add the necessary hooks to make sure the sticky keys modifier masks set
in clutter-evdev are also applied in MetaWaylandKeyboard's xkb_state so
that Wayland clients also benefit from sticky keys.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
We tried to get the geometry scale, which may depend on the main
logical monitor assigned to the window. To avoid dereferencing a NULL
logical monitor when headless, instead assume the geometry scale is 1.
https://bugzilla.gnome.org/show_bug.cgi?id=788764
The layout group determines what actual keyboard layout in the keymap
to use when translating modifier state and key codes to key syms.
When changing a keymap to another, the layout groups has no relation to
the layout groups in the old keymap, thus there is no reason to
transfer it to the new state.
This fixes an issue where the xkb state in meta-wayland-keyboard.c got
desynchronized with the xkb state in clutter-device-manager-evdev.c.
https://bugzilla.gnome.org/show_bug.cgi?id=789300
The handlers depend on a role being assigned. Destroying the window
causes it to become unmapped, which would sometimes trigger one of the
handlers, resulting in an is-assigned assert hitting in one of the
handlers. Avoid this by disconnecting the handlers earlier, so that
there is no risk that any them being triggered before the role is
assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=789552
In the unlikely case that a surface is moved by the compositor while
holding a pointer confinement, we also need to update the pointer
position when the surface actor gets moved.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
Both notify::position on the surface actor and position-changed on
MetaWindow are listened to, in order to trigger wl_output updates for
wl_surfaces whenever the surfaces move across them.
Both signals are necessary in order to cater for toplevel and subsurface
relocations (Because it's the parent window actor what changes position
in this last case).
Also, shuffle signal disconnection, so each signal goes away with
the object reference held by MetaWaylandSurface.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
Adding an internal signal and use it to update the internal state before
emitting "monitors-changed" which will be repeated by the screen to the world.
https://bugzilla.gnome.org/show_bug.cgi?id=788860
The modifier event was only added in v3 of the client; sending it to
older clients (e.g. GStreamer waylandsink) causes them to disconnect
immediately.
Send the older 'format' event to all clients, and only send the newer
'modifier' event to resource versions 3 or above.
https://bugzilla.gnome.org/show_bug.cgi?id=788558
Following up the previous patch, this patch makes the
Wayland backend send the edge constraints through a
custom protocol extension internal to GTK.
As it mature, we can think of upstreaming the protocol
to Wayland itself.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
We would free the shortcut inhibit data only when the client destroys
its request, which is not the case when the clients itself is
destroyed, leading to a leak of the shortcut inhibit data.
Free the data on resource destruction instead, and simply destroy the
resource on destroy request.
https://bugzilla.gnome.org/show_bug.cgi?id=787568
On Wayland, the grab()/ungrab() in gtk+/gdk are wired to the shortcut
inhibitor mechanism, which in turn shows the dialog, which can take
focus away from the client window when the dialog is shown.
If the client issues an ungrab() when the keyboard focus is lost, we
would hide the dialog, causing the keyboard focus to be returned to the
client surface, which in turn would issue a new grab(), so forth and so
on, causing a continuous show/hide of the shortcut inhibitor dialog.
To avoid this issue, keep the dialog around even if the shortcut inhibit
is canceled by the client, so that the user is forced to make a choice
that we can reuse on the next request without showing the dialog again.
Instead of hiding the dialog when the shortcut inhibitor is destroyed by
the client, we simply mark the request as canceled and do not apply the
user's choice.
https://bugzilla.gnome.org/show_bug.cgi?id=787568
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
This avoids updating state (such as position, size etc) when going
headless. Eventually, when non-headless, things will be updated again,
and not until then will we be able to update to a valid state.
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
Apparently my understanding of Cogl pixel formats, or at least their
use, was somewhat shaky.
Un-invert the inversion of the DRM FourCC -> Cogl pixel format mapping
when creating dmabufs from clients, fixing inverted channel ordering
seen from GL clients, e.g. gold highlights in gtk4-demo when using the
GSK GL backend when they should be blue.
https://bugzilla.gnome.org/show_bug.cgi?id=786677
The meta_wayland_surface_hide_inhibit_shortcuts_dialog() function
disconnected the "destroy" handler, but we'd still be listening on
response events. Change this to just hide the dialog, leaving the data
intact with the proper life time signal in place.
https://bugzilla.gnome.org/show_bug.cgi?id=786385
The 'data' object is attached to the MetaWaylandSurface as a GObject
qdata. It is created once, and stays allocated until the surface is
destroyed. To make things clearer, connect to the "destroy" signal just
after creating, and from a on_surface_destroyed() callback call the
.._free() function.
https://bugzilla.gnome.org/show_bug.cgi?id=786385
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
The cursor surface would be remembered until the next proximity in
event, causing flashing of the old cursor till the client underneath
the tablet tool sent the zwp_tablet_tool.set_cursor request.
Forgetting about the cursor surface on proximity out makes the cursor
invisible till the request is made.
More specifically, avoid crossing events, since clutter does not set
modifier/button state on those. Fixes implicit grabs being broken when
the pointer moves past the surface boundaries.
https://bugzilla.gnome.org/show_bug.cgi?id=785347
Since a wl_buffer is independent of the GL context in use (unlike, e.g.,
a GL renderbuffer), EGLImages with the EGL_WAYLAND_BUFFER_WL target must
pass EGL_NO_CONTEXT as the context. Quoting from the
EGL_WL_bind_wayland_display spec:
After querying the wl_buffer layout, create EGLImages for the
planes by calling eglCreateImageKHR with wl_buffer as
EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
context.
The check was already present inside _cogl_egl_create_image.
https://bugzilla.gnome.org/show_bug.cgi?id=785263
Signed-off-by: Daniel Stone <daniels@collabora.com>
Adds basic support for the "wheel" event from the Wayland tablet protocol.
Ideally we would accumulate the angle and report a wheel event with an
appropriate value for "clicks". We can get away with a much cruder method
for the time being, however, since no Wacom tablet puck actually provides
a smooth scrollwheel. Checking whether the angle in CLUTTER_INPUT_AXIS_WHEEL
exceeds a nominally-small threshold is sufficient to determine that the
wheel has advanced by at least one physical click.
https://bugzilla.gnome.org/show_bug.cgi?id=783716
When updating the main monitor, make sure to update the toplevel main
monitor before trying to use that as the main monitor for non-toplevel
windows (such as popups). Without this, when the main monitor is
updated as a side effect to monitors being changed (for example due to
a hot plug event, or coming back from being suspended) the
main monitor pointer may, after 'monitors-changed' has completed, point to
freed memory resulting in undefined behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=784867
To be able to render the pointer cursor sprite at sub-(logical)-pixel
positions, track the pointer position using floats instead of ints.
This also requires users of the cursor sprite rect to deal with
floating points, when e.g. finding the logical monitor etc.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When the logical layout mode is used, allow configuring the scaling to
be non-integer. Supported scales are so far hard coded to include at
most 1, 1.5 and 2, and scales that doesn't result in non-fractional
logical monitor sizes are discarded.
Wayland outputs are set to have scale ceil(actual_scale) meaning well
behaving Wayland clients will provide buffers with buffer scale 2, thus
being scaled down to the fractional scale.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Window moving and resizing depends on the `meta_wayland_seat_get_grab_info`
function succeeding. At the moment, tablet tools do not generate implicit
grabs like the pointer and touch. This commit adds the necessary elements
to track implicit grabs and retrieve their information.
https://bugzilla.gnome.org/show_bug.cgi?id=777333
Previously, the function only returned `TRUE` if the given surface was
equal to the given pointer's focused surface. This changes the behaviour
to also return `TRUE` if any of the given surface's subsurfaces are
equal to the pointer's focused surface.
https://bugzilla.gnome.org/show_bug.cgi?id=781811.
Use the "destroy" MetaWaylandSurface signal instead of the wl_resource
destroy signal for tracking the lifetime of the surface with pointer
focus.
As unsetting the focus may have side effects due to handlers of the
"focus-surface-changed" signal, connect the signal after the default
handler to make sure other clean up facilities have the chance deal with
the surface destruction before we try to unset the focus.
https://bugzilla.gnome.org/show_bug.cgi?id=783113
Relayouts in clutter may trigger synthesized crossing events if the
actor below the pointer changes. In that situation we do need to
repick() the MetaWaylandPointer to end up with the right current
wayland surface.
https://bugzilla.gnome.org/show_bug.cgi?id=755164
If a client changes the state of a surface to issue a set_maximize, this
causes apply_pending_state() to be called before mutter has placed the
window.
If the monitor on which the window is to be shown initially is different
from the one where the pointer is placed, this causes the effect to be
played at the wrong location before the window eventually reaches its
location on another monitor.
Force the window to be placed prior to change its state to maximized in
xdg-shell so that mutter won't relocate the window afterwards.
This also avoids sending an xdg_toplevel.configure with a size of 0x0
which would cause the client to initially draw its surface with some
arbitrary size.
https://bugzilla.gnome.org/show_bug.cgi?id=782183https://bugzilla.gnome.org/show_bug.cgi?id=781353
If we translate between text/plain;charset-utf-8 from the wayland side to
UTF8_STRING on the X11 side, we want to continue all further X11 selection
requests using the same translated UTF8_STRING atom than we use in the
first XConvertSelection call.
https://bugzilla.gnome.org/show_bug.cgi?id=782472
Previously we would bail out early in xdg_toplevel_role_commit() if no
geometry change was set, ignoring the possible min/max size hints
changes.
But setting a min/max size hint without changing the geometry is
perfectly valid, so we ought to apply the min/max changes regardless of
a geometry change.
https://bugzilla.gnome.org/show_bug.cgi?id=782213
If the client doesn't set a geometry using xdg_shell, we'll compute its
geometry based on its surface and subsurfaces.
Yet, we translate that as a window (re)size only when there is a pending
geometry, that we don't have when we computed the geometry by ourself.
Make sure we set the pending new geometry flag when computing the
geometry when it actually changed.
https://bugzilla.gnome.org/show_bug.cgi?id=782213
A client can still commit state to a destroyed subsurface. It wont
update anything on the screen, since the subsurface will not be
visible, but mutter should still handle it and not crash.
https://bugzilla.gnome.org/show_bug.cgi?id=781391
This commit adds support for rendering onto enlarged per logical
monitor framebuffers, using the scaled clutter stage views, for HiDPI
enabled logical monitors.
This works by scaling the mode of the monitors in a logical monitors by
the scale, no longer relying on scaling the window actors and window
geometry for making windows have the correct size on HiDPI monitors.
It is disabled by default, as in automatically created configurations
will still use the old mode. This is partly because Xwayland clients
will not yet work good enough to make it feasible.
To enable, add the 'scale-monitor-framebuffer' keyword to the
org.gnome.mutter.experimental-features gsettings array.
It is still possible to specify the mode via the new D-Bus API, which
has been adapted.
The adaptations to the D-Bus API means the caller need to be aware of
how to position logical monitors on the stage grid. This depends on the
'layout-mode' property that is used (see the DisplayConfig D-Bus
documentation).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
If the dnd window ends up lower in the overall stack than the window
it's supposed to fence, the drop might end up in some other window
underneath the expected target window.
Maps and raises the dnd window each time it's shown so that it's always
placed above.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=779800
QT apps reject DnD if the timestamp received in the SelectionRequest
event isn't the same it gave in XdndPosition/Drop client messages.
Bookkeeping and using it in XConvertSelection makes it happy again.
https://bugzilla.gnome.org/show_bug.cgi?id=779757
We are keeping accounting of the focus window as seen by the DnD bridge
right here, so use it instead of the MetaWaylandDragGrab focus as it may
lag behind the real focus (i.e. till the drag source notices the window
and sends XdndEnter to it).
This leads to the window trying to be repositioned more often than
necessary when the drag source takes long to send the XdndEnter client
message, and maybe not repositioned at all if the pointer leaves the
surface while no XdndEnter message was received.
https://bugzilla.gnome.org/show_bug.cgi?id=763246
We currently wait for the selection being cleared by the drag source,
which might not happen on not quite educated clients. This may leave
a stuck XDND grab in the compositor side.
We can actually do a bit better, and clear the grab if:
1) The drag source sent XdndDrop to the wayland drag destination.
2) There's no accepting drag destination and all pointer buttons are
released.
3) As usual, whenever the drag source clears the selection data
https://bugzilla.gnome.org/show_bug.cgi?id=763246
No XDnD events which notify DnD status change comes in Wayland. To emulate XDnD
behavior, MetaDnd checks whether there is a grab or not when the modal window
starts showing. When there is a grab, it processes the raw events from
compositor, and emits DnD signals for plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=765003
Operate on MetaMonitor's instead of MetaOutput's, as the latter may be
only a subset of an actual "monitor" when referring to the physical
computer equipment.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
When a logical monitor constains monitors with different subpixel
ordering, make the wl_output have the subpixel order 'unknown' so that
clients don't make assumptions given only a subset of the monitors of
the given region.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Don't try to mirror the physical dimension, since that's a property of
one of the monitors, not of the logical monitor. Callers are changed to
deal with choosing the monitor to represent the logical monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of storing the logical monitors in an array and having users
either look up them in the array given an index or iterate using
indices, put it in a GList, and use GList iterators when iterating and
alternative API where array indices were previously used.
This allows for more liberty regarding the type of the logical monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Move the last piece of monitor grid getter API to the monitor manager
away from MetaScreen. The public facing API are still there, but are
thin wrappers around the MetaMonitorManager API.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Turning a rectangle into a logical monitor also has nothing to do with
the screen (MetaScreen) so move it to MetaMonitorManager which has that
information.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Let the backend initialize the cursor tracker, and change all call
sites to get the cursor tracker from the backend instead of from the
screen. It wasn't associated with the screen anyway, so the API was
missleading.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
It checks whether a surface is on a given "logical monitor", not
output. Output here is the Wayland name for the same thing, but should
not be confused with MetaOutput.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In preparation for further refactorizations, rename the MetaMonitorInfo
struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor
will be split into a MetaMonitor type.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Use the proposed EGL_WL_wayland_eglstream EGL extension instead of the
file descriptor hack that was used as a temporary solution.
Note that this results in EGL clients will no longer work if they are
running on a Nvidia driver with a version older than 370.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Instead of having a way to determine the type of a buffer, add a
realization step that implicitly detects the buffer type. This makes it
possible to both realize (i.e. creating needed objects from the buffer)
and determine the type at the same time, which may be the only possible
way (for example, the only way to know whether a buffer is a EGLStream
is to create the EGLStream from it).
https://bugzilla.gnome.org/show_bug.cgi?id=773629
When the monitor the surface is on has a scale other than 1, the
coordinate of the window menu popup position needs to be scaled, as it
is reported in logical pixels, while the stage is still in physical
pixels.
https://bugzilla.gnome.org/show_bug.cgi?id=776055
A window manager must select the SubstructureRedirect mask on the root
window to receive the MapRequest from the X11 clients and manage the
windows. Without this event mask set, a window manager won't be able to
map any new window.
The Wayland selection code in mutter can change/clear the event mask on
the requestor window from a XSelectionRequest event when the window is
not managed by mutter/gnome-shell.
A rogue or simply buggy X11 client may send a XConvertSelection() on the
root window and mutter will happily change/clear its own event mask on
the root window, effectively turning itself into a regular X11 client
unable to map any new X11 window from the other X11 clients.
To avoid this, simply check that the requestor window is not the root
window prior to change/clear the event mask on that window.
https://bugzilla.gnome.org/show_bug.cgi?id=776128
Commit 5eb5f72 - wayland: Check surface outputs after mapped state
changes connected the ::mapped signal handler, we need to disconnect it
on destroy to avoid a possible assertion failure in
update_surface_output_state()
https://bugzilla.gnome.org/show_bug.cgi?id=776036
Commit 4295fdb892 made us skip focusing
all xdg_popups instead of just non-grabbing ones as intended. This
means that when unmanaging a window we might select a xdg_popup window
to focus (in meta_stack_get_default_focus_window() ) but then since we
don't actually focus it we go on unmanaging the focused window which
triggers an assertion, as it should.
To avoid this and still fixing bug 771694 we can make use of the
MetaWindow->input property for non-grabbing xdg_popup windows since
their semantics, in this regard, are the same as no input X11 windows.
This way, when unmanaging a focused window while a xdg_popup is up,
we'll either give focus to the xdg_popup or not select the popup at
all to be focused if it's non-grabbing.
https://bugzilla.gnome.org/show_bug.cgi?id=775986
This reverts commit 989ec7fc60.
We now rely on accurately knowing if a window moved and/or resized in
meta_window_move_resize_internal() so the wayland implementation can't
lie any longer.
https://bugzilla.gnome.org/show_bug.cgi?id=770345
This commit adds for a new type of buffer being attached to a Wayland
surface: buffers from an EGLStream. These buffers behave very
differently from regular Wayland buffers; instead of each buffer
reperesenting an actual frame, the same buffer is attached over and
over again, and EGL API is used to switch the content of the OpenGL
texture associated with the buffer attached. It more or less
side-tracks the Wayland buffer handling.
It is implemented by creating a MetaWaylandEglStream object, dealing
with the EGLStream state. The lifetime of the MetaWaylandEglStream is
tied to the texture object (CoglTexture), which is referenced-counted
and owned by both the actors and the MetaWaylandBuffer.
When the buffer is reattached and committed, the EGLStream is triggered
to switch the content of the associated texture to the new content.
This means that one cannot keep old texture content around without
copying, so any feature relying on that will effectively be broken.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Add support for inverted Y Wayland buffers. OpenGL textures are by
default inverted, so adding support for EGL_WAYLAND_Y_INVERTED_WL
effectively means adding support for non-inverted, which makes the
MetaShapedTexture apply a transformation when drawing only when querying
EGL_WAYLAND_Y_INVERTED_WL resulted in the response "EGL_FALSE".
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Don't rely on the Cogl layer having Wayland specific paths by
determining the buffer type and creating the EGLImage ourself, while
using the newly exposed CoglTexture from EGLImage API. This changes the
API used by MetaWaylandSurface to make the MetaWaylandBuffer API be
aware when the buffer is being attached. For SHM and EGL buffers, only
the first time it is attached will result in a new texture being
allocated, but later for EGLStream's, more logic on every attach is
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Similarly to Weston (where this code originated), there were two errors
in the X11 lockfile handling.
Firstly, after reading 11 characters from the lock file (which could
have been placed by any process), there was no guarantee of
NUL-termination, meaning strtol could've theoretically run off the end
of the string.
Secondly, whilst writing the new lock, the trailing NUL byte was not
correctly accounted for. The size passed as an input to snprintf takes
the maximum size of the string including the trailing NUL, whilst the
return (and the input to write) gives the actual size of the string
without the trailing NUL.
The code did attempt to check the return value, however snprintf returns
the size of the _potential_ string written, before snprintf culls it, so
this was off by one, and the LF was not being written.
Signed-off-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=774613
Stylus configuration (stylus buttons, pressure) was handled
at the very high level, doing the button and pressure translations
right before sending these to wayland clients.
However, it makes more sense to store these settings into the
ClutterInputDeviceTool itself, and have clutter apply the config
at the lower level so 1) the settings actually apply desktop-wide,
not just in clients and 2) X11 and wayland may share similar
configuration paths. The settings are now just applied whenever
the tool enters proximity, in reaction to
ClutterDeviceManager::tool-changed.
This commit moves all handling of these two settings to
the clutter level, and removes the wayland-specific paths
https://bugzilla.gnome.org/show_bug.cgi?id=773779
And remove the wayland-specific handling. This works for both Wayland and
X11 (provided the compositor receives pad events through a passive grab
there).
https://bugzilla.gnome.org/show_bug.cgi?id=773779
The keyboard focus semantics for non-grabbing xdg_shell v6 popups is
pretty undefined.
Same applies for subsurfaces, but in practice, subsurfaces never receive
keyboard focus, so it makes sense to do the same for non-grabbing
popups.
https://bugzilla.gnome.org/show_bug.cgi?id=773210
We shouldn't cancel the pointer grab when there is a compositor grab,
since that'd break things like drag-n-drop via the overview and
alt-tabs.
The original reason for cancelling the pointer grab on compositor grabs
was to avoid a re-entry when a compositor grab was activated while
there was an active pointer constraint grab. The re-entry would happen
when the compositor grab cleared the pointer focus. Clearing the focus
would trigger the pointer constraint to be deactivated, which would end
its grab. Ending the grab would reset the grab to the default one, which
could focus the same surface again, triggering the constraint to
re-enable before it finished disabling.
This is now avoided because the default grab handler is now aware of
compositor grabs, and won't override the cleared pointer focus until
the compositor grab ends.
https://bugzilla.gnome.org/show_bug.cgi?id=772914
Teach the default grab about compositor grabs (i.e.
display->event_route) so that it can avoid setting a pointer focus when
after the compositor grab actively unset the pointer focus.
https://bugzilla.gnome.org/show_bug.cgi?id=772914
When disabling the device/capability, we can't rely on cancelled events
being emitted timely, because the capability will be already disabled by
then, all touches must be cancelled immediately then.
https://bugzilla.gnome.org/show_bug.cgi?id=772929
When the monitor is scaled (i.e. HiDPI scaling) the placement coordinates
ere still in unscaled xdg_surface window geometry coordinate space when
used to place the window. Fix this by scaling the coordinates by the
monitor scale of the parent toplevel window before using them.
https://bugzilla.gnome.org/show_bug.cgi?id=771841
As meta_window_place_with_placement_rule will trigger a configure event
being sent ensure that the popup is placed on the correct monitor first
to ensure the right scale factor is applied.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=771841
Directly set the monitor of the toplevel window for the popup to avoid
the change not being applied due to later constraints calculation.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=771841
Always use the monitor of the toplevel surface's window, so that the
popup menu and the parent will always have the same scale. This fixes
the dimensions sent in the xdg_popup configure event.
https://bugzilla.gnome.org/show_bug.cgi?id=771841
When Xwayland confines, the surface dimensions will include the server
side window manager decorations. We don't want the decorations to be
included in the constraint region so intersect the calculated input
region with the parts of the buffer rect that is not part of the window
frame.
https://bugzilla.gnome.org/show_bug.cgi?id=771859
Put the conditions for enabling a pointer constraint in a helper
function, and use that in both maybe_enable() and maybe_remove(). The
constraint region checking is still only done in maybe_enable()
however.
This changes the conditions for maybe disabling the constraint on focus
change and other trigger points, namely it makes constraints by Xwayland
not disable when they shouldn't due to the constraining window being an
override-redirect window.
https://bugzilla.gnome.org/show_bug.cgi?id=771859
When the grab is cancelled, for example because of an Alt-tab, VT
switch etc, disable or remove (depending on the constraint type) the
constraint. This avoids a re-entry issue when the focus is returned and
the focus listener tries to re-enable a disabled constraint.
https://bugzilla.gnome.org/show_bug.cgi?id=771859
Dismiss the popup when the grab is cancelled, so that if the grab is
ended for whatever reason (such as VT switching or the last pointer
being disconnected), it doesn't try to end the grab when it isn't
active.
This fixes a crash when VT switching back and forth while a popup grab
is active.
https://bugzilla.gnome.org/show_bug.cgi?id=771858
Previously a grab could suddenly end without the grabber knowing
anything about it. Some grabs assume they won't suddenly end without
notice, and can use then new 'cancel' vfunc to be notified.
Currently a grab is cancelled when a new one is started (i.e. in
meta_wayland_pointer_grab_start()), when a non-popup compositor wide
event route is initiated, and when the seat looses the pointer
capability.
https://bugzilla.gnome.org/show_bug.cgi?id=771858
Instead of using meta_wayland_pointer_end_grab() which focuses the new
grab, add a new helper mean to be used to reset the grab state without
changing the pointer focus. When using this function, the call site is
supposed to explicitly manage focus.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
Make the caller of focus setting check whether there is a pointer to
update the focus state of. It makes it more obvious what to expect, as
the call would be a no-op in when no pointer is present.
Grabbing is still allowed without the presence of a pointer because it
is used by popups even on touch-only systems.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
