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
Make the caller of focus setting and grab starting check whether there
is a keyboard to update the focus state or start grabbing. It makes it
more obvious what to expect, as the call would be a no-op in when no
keyboard is present.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
The variable name 'l' usually refers to a GList iterator, but here it's
just a short hand for a specific list. Stop using this shorthand, since
it just makes it harder to read what list is used.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
