Commit Graph

25699 Commits

Author SHA1 Message Date
Carlos Garnacho
f988a9caaa x11: Clear X11 selection source after unsetting owner
The X11 selection source was being preserved after unsetting its
ownership. This is no leak as it would be eventually replaced by
another source, or destroyed on finalize. But it's pointless to
keep it.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1205
2020-04-17 14:37:30 +02:00
Carlos Garnacho
b7366b5b53 wayland: Drop unused struct variable
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
2020-04-17 00:51:00 +02:00
Carlos Garnacho
5e8d8b9ade wayland: Move the primary data device manager to its own file
Instead of having everything clumped at MetaWaylandDataManager,
split the primary selection to its own struct. This manager is
handled separately from wl_data_device_manager and other selection
managers, so they would be able to interoperate between them, even.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
2020-04-17 00:50:57 +02:00
Carlos Garnacho
4726f3d5d3 wayland: Move primary data offers to their own file
Following the MetaWaylandDataOffer split.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
2020-04-17 00:46:23 +02:00
Carlos Garnacho
91ef7515de wayland: Move MetaWaylandDataOffer to its own file
This is still an openly defined struct, as we will need accessed
by "subclasses". Same principle applies than with the
MetaWaylandDataSource refactor, this is not meant to introduce
functional changes, so just go with it.

On the bright side, the interactions are now clearer, so it could
be made saner in the future.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
2020-04-17 00:46:23 +02:00
Carlos Garnacho
317f6c0910 wayland: Move MetaWaylandDataSourcePrimary to its own file
Following the MetaWaylandDataSource split, this goes next.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
2020-04-17 00:46:23 +02:00
Carlos Garnacho
6a3d521466 wayland: Split MetaWaylandDataSource into a separate file
The split wasn't 100% clean, and some extra private API had to be
added for it (but well, looking at the API, it's already evident
there's a cleanup/streamlining task due). This is meant to be a
refactor with no functional changes, so just go with it.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
2020-04-17 00:46:21 +02:00
Carlos Garnacho
1363246d44 wayland: Rely on MetaSelection::owner-changed for .selection event emission
We already have a signal callback that translates selection ownership changes to
data_device/primary .selection events. Given both will be run when a data source
is being replaced, and this event emission being deleted is kinda short sighted
in that in only knows about Wayland, rely entirely on MetaSelection::owner-changed
emission.

Fixes spurious .selection(null) events being sent when a compositor-local source
takes over the selection without the focus changing (eg. screenshot to clipboard).

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1160

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1204
2020-04-16 22:25:00 +00:00
Carlos Garnacho
0b6560fac4 wayland: Do not cancel old data source when setting new selection
This is taken care already by the MetaSelection machinery, by
deactivating the previous selection source when setting a new one.
That works across X11 and internal selection sources. This
only works when replacing one wayland source with another, and
actually results in doubly .cancelled events due to the other
paths.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1177

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1203
2020-04-16 19:27:51 +00:00
Carlos Garnacho
d4c3870286 wayland: Shuffle wl_data_source.cancelled version checks on DnD
We are meant to send a .cancelled event after the drop is performed
in certain situations, but only for version>3 clients. Since this is
all version 3 business, only set the drop_performed flag for v3
clients. This drops the need to perform version checks at the time
of cancelling (which is present for other usecases in v1).

Fixes emission of wl_data_source.cancelled for v1 clients.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1177

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1203
2020-04-16 19:27:51 +00:00
Carlos Garnacho
4bdf9a1e70 core: Cater for reading selection in chunks
For the cases where we read a fixed size from the selection (eg. imposing
limits for the clipboard manager), g_input_stream_read_bytes_async() might
not read up to this given size if the other side is spoonfeeding it content.

Cater for multiple read/write cycles here, until (maximum) transfer size is
reached.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
1909977a67 x11: Do not trust there is task in error paths
Flushing the X11 selection output stream may happen synchronously or
implicitly, in which case there is not a task to complete. Check there
is actually a task before returning errors. We additionally set the
pipe_error flag, so future operations will fail with an error, albeit
with a more generic message.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
655a783891 x11: Don't stall on write_async()
If a write_async() comes up while we are flushing on the background,
the task will be queued, but not deemed a reason on itself to keep
flushing (and finish the task) after a property delete event.

To fix this, do not ever queue up write_async tasks (this leaves
priv->pending_task only used for flush(), so the "flush to end"
behavior in the background is consistent). We only start a
background flush if there's reasons to do it, but the tasks are
immediately finished.

All data will still be ensured to be transfered on flush/close,
this makes the caller in this situation still able to reach to it.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
a4596becc4 x11: Fix iterative INCR property checks
It does not make sense to check for the stream not being closed,
this might happen multiple times during the lifetime of the stream
for a single transfer. We want to notify the INCR transfer just
once.

Check for the explicit conditions that we want, that the remaining
data is bigger than we can transfer at once, and that we are not
yet within the INCR transfer.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
7015bb3efd x11: Don't exceed transfer size in INCR chunks
The stream automatically flushes after data size exceeds the
size we deem for INCR chunks, but we still try to copy it all.
Actually limit the data we copy, and leave the rest for future
INCR chunks.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
d2c762cc66 x11: Don't invariably queue a pending delete request
We don't need doing this roundtrip for non-INCR transfers.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
04d429b743 x11: Finish INCR transfers properly
INCR transfers are mandated to finish with a final 0-size XChangeProperty
roundtrip after the final data chunk. Actually honor this and ensure we
iterate just once more for this.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
0b21dcfe08 x11: Wait till data is flushed before notifying on the pending task
It does not make sense to notify flushes mid-transfer. We should wait
till the data is actually finished before notifying on the pending
task.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
7c939d78c2 x11: Only send SelectionNotify on first INCR chunk
This should only be sent if the selection can be sent at once, or
if we are right about to notify on the first chunk of an INCR
transfer.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
8a2b82897d x11: Ensure flush() Flushes all output stream data
This seemed to work under the assumption that a flush() call can
only result in one INCR roundtrip. This is evidently not true, so
we should hold things off until all pending data is actually flushed.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
e95c365cf0 x11: Unset pending flush flag right before notifying on task
Together with some other state. We can do this altogether on task
notification, instead of lost somewhere in this function flow.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
a32cb7133b x11: Intern INCR atom
We want to use it, despite it not existing previously.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
967966cdee x11: Flag flushes despite having less than the element size
If say we want 32bit data, but have 2 bytes stored, we would simply
ignore flush requests. Allow (and don't clear) the needs_flush flag
if we have less than the element size accumulated.

Instead handle this in can_flush(), so it's triggered whenever we
have enough data to fill 1 element, or if the stream is closing
(seems a broken situation, but triggered by the caller).

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Carlos Garnacho
06d67b6abf x11: XMaxRequestSize returns 4-byte units
XMaxRequestSize/XMaxExtendedRequestSize are documented to return
the maximum size in 4-byte units, whereas we are comparing this
to byte lenghts. We can afford 4x the data here.

Since I don't know the payload size of the XChangeProperty request,
be generous and allot 400 bytes for it, we have some to spare.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
2020-04-16 16:26:04 +00:00
Marco Trevisan (Treviño)
f15ce01e2b monitor-unit-tests: Ensure configuration is preserved in laptop with closed lid
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1200
2020-04-16 15:14:03 +00:00
Marco Trevisan (Treviño)
e48516679c monitor-config-manager: Fallback to closed laptop lid configuration
When closing the lid of a laptop, we reconfigure all the monitors in order
to update the CRTCs and (if enabled) the global UI scaling factor.

To do this, we try first to reuse the current configuration for the usable
monitors, but if we have only monitor enabled and this one is on the laptop
lid we just end up creating a new configuration where the primary monitor is
the laptop one (as per find_primary_monitor() in MetaMonitorConfigManager),
but ignoring the user parameters.

In case the user selected a different resolution / scaling compared to the
default one, while the laptop lid is closed we might change the monitors
layout, causing applications to rescale or reposition.

To avoid this, when creating the monitors configuration from the current
current state, in case we have only one monitor available and that one is
the laptop panel, let's just reuse this configuration.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1200
2020-04-16 15:14:03 +00:00
Jonas Ådahl
65a6c4c361 compositor: Add support for direct scanout of Wayland surfaces
Try to bypass compositing if there is a fullscreen toplevel window with
a buffer compatible with the primary plane of the monitor it is
fullscreen on. Only non-mirrored is currently supported; as well as
fullscreened on a single monitor. It should be possible to extend with
more cases, but this starts small.

It does this by introducing a new MetaCompositor sub type
MetaCompositorNative specific to the native backend, which derives from
MetaCompositorServer, containing functionality only relevant for when
running on top of the native backend.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
b51c468c0f later: Listen to MetaCompositor signal instead of clutter
We need to coordinate with MetaCompositor during pre-paint so that we
have control over whether MetaLater callbacks happen first, or the
MetaCompositor pre-paint logic.

In order to do so, make MetaLater listen to a new signal "pre-paint" on
MetaCompositor, that is called MetaCompositors own pre-paint handling.

This fixes an issue where the top window actor was calculated after the
MetaCompositor pre-paint handling, meaning the top actor being painted
was out-of-date.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
2e7d02f1ce later: Make MetaCompositor the owner of the MetaLaters state
Since the order of destruction during MetaDisplay tear down is a bit
unordered, there are pieces that try to destruct its compositing
dependent pieces (i.e. queued MetaLater callbacks) after MetaCompositor
has been cleaned up, meaning we need to put some slightly awkward NULL
checks to avoid crashing.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
dc4fe780f7 display: Initialize MetaCompositor in two steps
MetaCompositor is the place in mutter that manages the higher level
state of compositing, such as handling what happens before and after
paint. In order for other units that depend on having a compositor
instance active, but should be initialized before the X11 implementation
of MetaCompositor registers as a X11 compositing manager, split the
initialization of compositing into two steps:

 1) Instantiate the object - only construct the instance, making it
    possible for users to start listening to signals etc
 2) Manage - this e.g. establishes the compositor as the X11 compositing
    manager and similar things.

This will enable us to put compositing dependent scattered global
variables into a MetaCompositor owned object.

For now, compositor management is internally done by calling a new
`meta_compositor_do_manage()`, as right now we can't change the API of
`meta_compositor_manage()` as it is public. For the next version, manual
management of compositing will removed from the public API, and only
managed internally.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
d682cdb078 util: Move MetaLater to its own file
While at it, fix some style inconsistencies, for now use a single
singleton struct instead of multiple static variables, and
other non-functional cleanups. Semantically, there is no changes
introduced.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
ff7a42b8bc wayland: Add API to acquire a CoglScanout from a surface
This will check whether the current backing buffer is compatible with
the primary plane of the passed CoglOnscreen. Since this will extend the
time before a buffer is released, the MetaWaylandBufferRef is swapped
and orphaned if a new buffer is committed before the previous one was
released. It'll eventually be released, usually by the next page flip
callback.

Currently implemented for EGLImage and DMA-BUF buffer types.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
4b1805c306 wayland/dma-buf: Handle getting dma-buf from detached buffer handle
We might still have a MetaWaylandBuffer for a wl_buffer that was
destroyed. Handle trying to fetch the MetaWaylandDmaBufBuffer from such
a buffer gracefully.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
03c00e4944 wayland/dma-buf: Minor style fix
Indentation was off.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
cb05b16414 wayland/dma-buf: Don't advertise modifier support by default
Advertising support for modifiers means we will most likely not not be
able to scan out client buffers directly, meaning it just as likely that
we won't be able to scan out even fullscreen windows without atomic KMS.

When we have atomic support, we should advertise support for modifiers
if atomic is used to drive the CRTCs, as we by then can check whether we
can scan out directly, place in an overlay plane, etc.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
b9fe9c736a onscreen/native: Add API to check whether buffer is scanout compatible
While this is fairly incomplete, as to check things fully we need to use
TEST_ONLY in atomic to try out a complete assignment on the device, but
this works well enough for legacy non-modifier cases.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
3dd8861fbf renderer/native: Add API to get primary GPU
Will be used when acquiring scanouts from Wayland buffers.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
753066598f clutter/view: Make it possible to assign a temporary direct scanout
Make it possible to cause the next frame to scan out directly from the
passed CoglScannout. This makes it possible to completely bypass
compositing for the following frame.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:52 +02:00
Jonas Ådahl
3da8c1bfdc cogl/onscreen: Add API to scanout a buffer directly
Instead of always swapping buffers and flipping the back buffer, make it
possible to scan out a provided buffer directly without swapping any EGL
buffers.

A buffer is passed as an object implementing the empty CoglScanout
interface. It is only possible to do this in the native backend; and the
interface is implemented by MetaDrmBufferGbm. When directly scanned out,
instead of calling gbm_surface_lock_front_buffer() to get the gbm_bo and
fbid, get it directly from the MetaDrmBufferGbm, and use that to create
the page flip KMS update.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 15:05:15 +02:00
Jonas Ådahl
f8ee974628 wayland/buffer-ref: Add helpers for use count tracking
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 14:08:19 +02:00
Jonas Ådahl
f36120757f wayland: Make MetaWaylandBufferRef reference counted
So that we can have a more dynamic ownership.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 14:08:19 +02:00
Jonas Ådahl
bc178b711f clutter/actor: Add semi-private API to check for transitions
Transitions are used for animating actors when e.g. going from/to
fullscreen, and the like. We need to know such things when deciding
whether to avoid compositing a window actor, so make add API visible to
mutter that checks whether there are any transitions active.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 14:08:19 +02:00
Jonas Ådahl
5dad87cfb9 surface-actor-x11: Move window related unredirect logic to MetaWindowX11
Better to have the relevant object figure out whether it is a good
position to be unredirectable other than the actor, which should be
responsible for being composited.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 14:08:19 +02:00
Jonas Ådahl
0f8f607e4c window/x11: Use G_DECLARE_DERIVABLE_TYPE()
This removes the MetaWindowX11::priv pointer. It is replaced with a
meta_window_x11_get_private() helper function, and another method to get
the client rect without going through MetaWindowX11Private.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 14:08:19 +02:00
Jonas Ådahl
282aada13a drm-buffer/gbm: Support both surface and standalone buffers
Surface buffers are created with meta_drm_buffer_new_acquire(), taking a
gbm_surface acquiring the gbm itself, and meta_drm_buffer_new_take()
that takes over ownership of a passed gbm_bo.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 14:08:19 +02:00
Jonas Ådahl
47002bf0cd wayland/surface: Put buffer reference on heap
Currently a buffer use count always reaches zero before it is replaced.
This is due to the fact that at the point a new buffer is attached, the
last potential user releases it (the stage) since the currently
displayed frame has a composited copy of the buffer.

This may however change, if a buffer is scanned out directly, meaning it
should not be released until the page flip callback is invoked.

Prepare for this by making the buffer reference a heap allocated struct,
enabling us to keep a pointer to it longer than the buffer is attached.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-04-16 10:43:34 +02:00
Jonas Ådahl
3d47c7edc1 cursor-renderer-native: Take CRTC transform into account
The CRTC level transform (not necessarily the hw transform) must be
taken into account when calculating the position of the CRTC in the
stage coordinate space, when placing the hw cursor, otherwise we'll
place the cursor as if the monitor was not rotated.

This wasn't a problem in the past, as with rotation, we always used the
OpenGL cursor, so the issue newer showed.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
2020-04-15 15:29:55 +00:00
Jonas Ådahl
bc350f37f5 renderer-native: Use CRTC layout in stage view
The port to per CRTC views was incomplete; we still used the logical
monitor layout as the stage view layout, while still using one view per
CRTC.

This worked fine for most cases, e.g. regular monitors, tiled or
non-tiled, transformed or non-transformed. Where it broke, however, was
when a monitor consists of multiple CRTCs. We already have the layout a
CRTC corresponds to on the stage kept with the CRTC metadata, so use
this directly.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1170

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199`
2020-04-15 15:29:55 +00:00
Jonas Ådahl
b55e2e1df9 tests/monitor-unit-tests: Test non-hw-transform rotated tiled monitors
Should affect the assigned transform, but not the layout, as that is the
layout on the stage, not the coordinates in any buffer.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
2020-04-15 15:29:55 +00:00
Jonas Ådahl
43baf643d4 monitor-config-manager: Only use crtc transform for assignment
The CRTC level transform (i.e. not necessarily the one set on the
hardware) is what is relevant for calculating the layout the CRTC will
have on the stage, so only use the one that can be handled by the
hardware for the CRTC assignment.

This makes the CRTC layout valid for tiled monitors.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
2020-04-15 15:29:55 +00:00