summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* kms/crtc: Determine gamma support given the gamma lengthJonas Ådahl2022-05-281-1/+1
| | | | | | | | | | | | | | The property doesn't necessarily exist when using drivers that doesn't support atomic mode setting, and the way it worked will break night light and other gamma related features. This makes things use the gamma length; if it is higher than 0, it definitely supports it one way or the other, i.e. GAMMA_LUT with the atomic backend, and drmModeCrtcSetGamma() with the legacy/simple backend. Fixes: 364572b95c8354ac66674064a8058aa98bc0bbef Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2287 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435> (cherry picked from commit a2ebd10f049d888e451938e23a035ed97e0c8eff)
* kms/crtc: Always read the gamma stateJonas Ådahl2022-05-281-16/+10
| | | | | | | | | It doesn't depend on whether the CRTC is active or not, so always read it. This is also useful to know whether a CRTC supports gamma, before it is being turned on, without relying on the existance of properties. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435> (cherry picked from commit 9001fa9717c88f8d429fbfafb236f8b8cf92dba2)
* x11/events: Do not handle enter/leave during grabsFlorian Müllner2022-05-281-0/+8
| | | | | | | | | | The COMPOSITOR_GRAB event route has effectively been replaced by ClutterGrabs, which are no longer covered by the existing check. So check for grabs as well to restore the old behavior. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436> (cherry picked from commit d04a1977234e15ef3c5563b94297ba23292360e5)
* display: Bypass focus window during grabsFlorian Müllner2022-05-281-1/+3
| | | | | | | | | This is what the old COMPOSITOR_GRAB check effectively did (by returning the grab_window, which is only set during window grab operations). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436> (cherry picked from commit 75856043d4a61d310ef471cc81bc53a9af37fbc4)
* core: Avoid focusing window in presence of Clutter grabsCarlos Garnacho2022-05-281-6/+8
| | | | | | | | | | | | This is the same circumstance than the event_route not being NORMAL, since events may or may not eventually reach the window. It should not attempt to get focus out of the stage in that situation. This used to be covered by META_EVENT_ROUTE_COMPOSITOR_GRAB, but this is no longer set when ClutterGrab came in to replace it. Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4858 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2433> (cherry picked from commit 50e89e37600509676fb4e284316e275864505460)
* display: Properly store later ID when adding window to queueSebastian Keller2022-05-281-4/+5
| | | | | | | | | | | | | | | The code is already trying to avoid creating new laters when there already is one for the queue type, but this wasn't working because the ID of the later was never stored after creating a new one. This would then result in as many laters as meta_display_queue_window() was called and all of them would run the handler function, even if only the first one had a non-empty window queue. Similarly this was causing the later to not be removed if the window queue got empty after meta_display_unqueue_window(). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414> (cherry picked from commit bc9762eebb1ab0b812118dd126b9a9b5c031bec8)
* window: Ensure window-visibility-updated is emitted when flushing queueSebastian Keller2022-05-281-5/+7
| | | | | | | | | | | | | | | Currently the signal is getting emitted accidentally, because even when removing a window from the queue, the later handler of that queue will still get run due to a bug. This bug is going to get fixed in the next commit, but some things might depend on the signal getting emitted when the visibility of a window has changed. This change affects the behavior in two ways. First the signal is now emitted immediately rather than from an idle. And second it now correctly includes the window in the should_show or should_hide list. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414> (cherry picked from commit b289c8f01e97e65dffaf512844f3a769cc4e8ea0)
* display: Add method to flush a single window from the queuesSebastian Keller2022-05-282-28/+68
| | | | | | | | This can be used when a state change needs to be applied immediately for a specific window and will be used in the next commit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414> (cherry picked from commit 2a3c964e64dbcc9d097abbe98cf83809aeefe831)
* compositor: Update topmost window actor after visibility changesSebastian Keller2022-05-281-0/+18
| | | | | | | | | | | | | | | | | The compositor currently only updates the topmost window actor that is visible to it after stacking changes. The visibility of a window actor to the compositor however might only change via the display idle queue after the stacking changes. This could then lead to the topmost window actor being assumed to be NULL on Wayland after switching from an empty workspace or when opening the first window on an empty workspace. The result of this is direct scanout being disabled in these cases. To fix this also trigger the update when the visibility of windows changes. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2269 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2413> (cherry picked from commit bb76d6fcc3ea0e2a7ce98350b6b5200884c729f6)
* compositor: Split out a function to update the topmost window actorSebastian Keller2022-05-281-20/+23
| | | | | | | | This allows this to be used from outside the restacking code in the follow-up commit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2413> (cherry picked from commit 0bc142ec1b0753416c6dca40103ebcc09b2bbafa)
* x11-display: Init event mask after taking manager selectionJonas Ådahl2022-05-281-2/+2
| | | | | | | | | | | | Initializing the event mask, SubstructureRedirectMask in particular, before taking the manager selection fails with BadAccess. Fix this by initializing said mask after taking the manager selection. This fixes `--replace`. Fixes: eb4307c3501f347a701d376a591adaab17ba3986 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2432> (cherry picked from commit 1e95710c5240f834d3ba643ec2c4091e576c8edb)
* x11-display: Make some init calls more compactJonas Ådahl2022-05-281-4/+0
| | | | | | | | Makes more of the function fit on the screen, without making readability any subjectively worse. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2432> (cherry picked from commit a24b14e30203d2fb9871d54bd57595498133fef9)
* util: Fix compilation when !WITH_VERBOSE_MODEKazuki Hashimoto2022-05-281-0/+2
| | | | | | | | | | Fixes the following linker error: `meta_add_verbose_topic': <artificial>:(.text+0x372f): undefined reference to `ensure_logfile' Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2405> (cherry picked from commit 38314fe5fd56fef53968352447101571e7535e46)
* Update Nepali translationPawan Chitrakar2022-05-201-161/+146
|
* monitor-manager: Ensure monitors settings after backend has been updatedMarco Trevisan (Treviño)2022-05-172-11/+27
| | | | | | | | | | | | | | | | | | | The monitors settings such as the privacy screen property is propagated to the monitors via kms updates, however during initialization and on monitors changes, we end up clearing the pending KMS updates because such settings are added to the queue before the backend has fully initialized the monitors, and this may lead to discarding all the pending updates, including the one we've just planned. To avoid this, move settings applications after we've both initialized the backend and notified it about changes. Also avoid to try set the settings during actual initialization, but delay that after post-init. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2372> (cherry picked from commit c93e402a898d2e45b4b15e176d5d428a54797d4a)
* display: Unmanage windows before compositorJonas Ådahl2022-05-171-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to 'compositor: Destroy actors when unmanaging', window actors were destroyed when the compositor object was destroyed, long after the windows were unmanaged, however, when this instead changed to happen when unmanaging, with the original goal to avoid having these actors try to interact with the disposed MetaCompositor instance, it caused an issue where window actors would be indirectly destroyed as a side effect of their parents being destroyed, which caused some fallout in the logic handling window-close animation tracking, which relies on meta_window_actor_queue_destroy() being called before a window actor is actually destroyed. Fix this by unmanaging windows before unmanaging the compositor. From an X11 point of view, this should be harmless, since all it really do is call XCompositeUnredirectSubwindows(). For the native backend and the common behavior, all unmanaging the compositor instance does is destroy clutter actors, so doing so after window actors were already cleaned up should not be a problem, as this was the case before too. Fixes: 35ac3a096d84de97c1da9a54d99aebf7640c1c07 Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5330 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2403> (cherry picked from commit 8ec8a26717909b729b57539c5d16cf23c417ad90)
* window-actor/wayland: Only use scanout for opaque non-fullscreen windowsSebastian Keller2022-05-171-0/+6
| | | | | | | | | | | | | | This could for example happen with the client window created by the desktop-icons-ng extension which spans the entire desktop, but is not a fullscreen window and uses transparency On Wayland only opaque surfaces or transparent surfaces of fullscreen windows can be used for direct scanout. Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2263 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409> (cherry picked from commit 54ba64b9f22f02893bc8c593358d6ace842be40c)
* window-actor/x11: Don't use direct scanout if the window is not opaqueSebastian Keller2022-05-171-0/+3
| | | | | | | | | | | | | | | | Some windows span the entire screen but still use transparency, such as the desktop window of Nemo. When these windows were used for direct scanout, the transparent areas would turn black and nothing else would be rendered. In addition to checking the surface for opaqueness, for X11 windows also the window actor itself has to be checked, because its opacity might have been changed via _NET_WM_WINDOW_OPACITY. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2263 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409> (cherry picked from commit dc43bb9f6874224b5cbae988aa8ffc3673213a6f)
* window-actor: Add API to get the surface actor candidate for scanoutSebastian Keller2022-05-175-23/+38
| | | | | | | | | | | This replaces the API to get the topmost surface actor with an API to get the surface actor that could be a candidate for direct scanout. The advantage of this is that it allows X11 and Wayland specific restrictions for these actors. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409> (cherry picked from commit 9c8948fc047b8b99908a548a390f2acd1ccf8a55)
* wayland/buffer: Only query Wayland EGL buffer if display boundJonas Ådahl2022-05-177-22/+63
| | | | | | | | | | | | | It's not allowed to call eglQueryWaylandBuffer() if the call to eglBindWaylandDisplay() failed, and will result in an assert being hit in mesa if called. Avoid that by keeping track whether we succeeded to bind, and only attempt to realize a legacy EGL wl_buffer if binding succeeded. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2415> (cherry picked from commit 75ec27966d11cdbd83a64128aba032d386633b11)
* Bump version to 42.142.1Florian Müllner2022-05-052-1/+38
| | | | Update NEWS.
* Revert "workspace: Use existing focus_window when asked to focus default window"Sebastian Keller2022-05-041-12/+0
| | | | | | | | | | This reverts commit d0de671c1d23a4869f35bd7b832871bacdfeb212. The change introduced a regression when focusing java/swing windows. Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5395 Reopens: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5162 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2402>
* clutter: Don't log filenames in debugging modeJonas Dreßler2022-05-041-2/+2
| | | | | | | | | | | | A slightly annoying "feature" of Clutters debug messages is that it also logs the filename and line of the current debug message. If you don't have an ultrawide monitor, this can be very annoying and cause lots of linebreaks in the debug logs. So remove that debugging feature and no longer log the filename and line number with debugging messages. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2378>
* kms/impl/simple: Make sure cursor buffers have fb idsJonas Ådahl2022-05-031-2/+9
| | | | | | | | | | | | | | 'kms/impl-device/simple: Get the buffer handle from MetaDrmBuffer' changed how fb ids are generated, but it only made it fully work with atomic mode setting. For legacy/simple mode setting, it only handled the primary plane buffer, not the hardware cursor. Fix this by making sure the fb id is generated also in the legacy mode setting case. Fixes: ea39142da2c7e3dc7dbe17f7f2e0d7ef66fab1f8 Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2250 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2397>
* build: Fix building without WaylandBilal Elmoussaoui2022-05-031-0/+5
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2400>
* x11/window: Update _NET_WM_DESKTOP when a window becomes all-workspaceSebastian Keller2022-05-021-5/+2
| | | | | | | | | | | | | | | When an X11 window becomes an all-workspace window its `workspace` is set to NULL before `meta_window_x11_current_workspace_changed()` is called. The latter then checks for `workspace` being NULL (which also happens when unmanaging) and then returns early. So this does not update `_NET_WM_DESKTOP` to 0xFFFFFFFF. Instead it remains at the workspace the window was on before. This was causing programs like `wmctrl` to switch to this old workspace when activating such a window. Fix this by checking if the window is unmanaging instead. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2242 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2387>
* wayland: Avoid repeated NULL preedit string updatesCarlos Garnacho2022-04-301-4/+11
| | | | | | | | | Simply signal preedit string changes from/to NULL once, in order to avoid unwanted activity in the client side. We do still need to send the preedit once each .done event, if there is one, in order to behave according to the protocol when it matters the most. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2395>
* screen-cast: Always wait for an update before sending cursor-only framesJonas Ådahl2022-04-294-6/+85
| | | | | | | | | | | | | | | With the unthrottled input emission, we ended up often getting the cursor updates long before any damage had been posted, meaning that if you moved around the mouse pointer where the mouse had a high enough refresh rate, we'd effectively stall the screen cast stream by only sending cursor updates and nothing else. Fix this by scheduling an update when we get a cursor update, then sending a cursor-only frame after any damage and relayout has been processed, but only if there is no queued damage that will cause an actual repaint. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
* screen-cast/window/src: Fix signal handler typesJonas Ådahl2022-04-291-4/+4
| | | | | | Should be gulong, not unsigned long. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
* stage: Add 'prepare-frame' signalJonas Ådahl2022-04-293-0/+27
| | | | | | | | | This is a signal that will be emitted between the 'before-update' and 'before-paint'. It can be used to handle things when you know whether there is an update, and you know whether a paint or not will happen, by looking at the current damage. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
* wayland/dma-buf: Remove redundant error checkRobert Mader2022-04-291-1/+1
| | | | | | `meta_egl_*` functions are assumed to set an error on failure. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2386>
* wayland/dma-buf: Only advertise supported formatsRobert Mader2022-04-291-20/+70
| | | | | | | | | | | | | | Analogous to how we use `eglQueryDmaBufModifiersEXT()` to query supported modifiers, use `eglQueryDmaBufFormatsEXT()` to ensure we only advertise formats supported by both the compositor and the driver. If there is no overlap, don't advertise `zwp_linux_dmabuf_v1` at all. Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2238 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2386>
* cursor-renderer/native: Support allocating dumb buffersJonas Ådahl2022-04-291-23/+68
| | | | | | | | This makes it possible to allocate HW cursor without a gbm_device, e.g. when using EGLStream/EGLDevice. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1980 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2275>
* cursor-renderer/native: Move buffer creation to helperJonas Ådahl2022-04-291-61/+107
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2275>
* kms/impl-device/simple: Get the buffer handle from MetaDrmBufferJonas Ådahl2022-04-291-13/+2
| | | | | | | This avoids buffer implementation specific code where it shouldn't matter. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2275>
* drm-buffer: Keep track of handle as wellJonas Ådahl2022-04-296-0/+17
| | | | | | | | This handle is used by the legacy KMS API; lets avoid having to have GBM specific code where this is done by letting the MetaDrmBuffer API, that already has this information, expose it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2275>
* compositor/dnd: Fix indentationJonas Ådahl2022-04-291-1/+1
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
* screen-cast: Remove stray newlineJonas Ådahl2022-04-291-1/+0
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
* barrier: Remove _ prefix in various placesJonas Ådahl2022-04-294-24/+24
| | | | | | | It's not a convention used anywhere else anymore, lets remove the prefixes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
* barrier: Some coding style cleanupJonas Ådahl2022-04-291-6/+18
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
* display: Get the backend from the contextJonas Ådahl2022-04-295-14/+28
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
* util: Avoid overriding 'message' in meta_topic()Jonas Ådahl2022-04-291-3/+4
| | | | | | | | | We'd put the message in a variable called `message`. If something passed to meta_topic() was called `message`, it'd end up being `NULL` in the log entry. Avoid this by making the local message variable a bit more "on topic". Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
* build: Make each executable/library have their own log domainJonas Ådahl2022-04-297-31/+57
| | | | | | | This helps reading log output during, as it's otherwise often unclear whether a log entry came from a test client or mutter itself. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
* clutter/stage: Remove unused nullable annotationCorentin Noël2022-04-291-1/+1
| | | | | | | This annotation wasn't taken into account because of the colon, but shouldn't be applied as there is no way a NULL ClutterGrab can be returned. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2382>
* clutter/actor-meta: Notify actor property on changesJonas Dreßler2022-04-241-1/+4
| | | | | | | Seems like this was forgotten when writing the class. While at it, add EXPLICIT_NOTIFY to the property flags. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2377>
* clutter: Remove device/sequence entry when TOUCH_END get filtered outJonas Dreßler2022-04-231-25/+31
| | | | | | | | | | | | | | | | | | | | Mutters event filter can prevent events from getting processed by Clutter, this can also happen for TOUCH_END/CANCEL events. Processing these events in Clutter is crucial for proper tracking of touch sequences though, that's because Clutter adds a PointerDeviceEntry to the stage on a TOUCH_BEGIN *before* going through the event filter, but removes that entry on a TOUCH_END *after* going through the filter. So Clutter really needs to see those TOUCH_END events, or else there will be a stale PointerDeviceEntry on the ClutterStage. Make sure those TOUCH_END/CANCEL events always get seen by Clutter by removing the device entry immediately when those get filtered out. Because there might still be events belonging to this sequence in the event queue of the stage, we need to flush the queue before removing the entry, too. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2350>
* clutter: Shuffle handling of IM reset on button pressesCarlos Garnacho2022-04-233-9/+24
| | | | | | | | | | | | | | | | | | | Unfortunately we cannot do this generically since the target of the button/touch press does matter, e.g. tapping on the OSK, or clicking the IBus candidates window. These situations should not trigger a reset. So be more selective about the situations where button/touch presses trigger an IM reset, in the case of ClutterText these are still clicks inside the actor, for Wayland's text-input it is when clicking the surface that has text_input focus. For all other situations where clicking anywhere else might make sense to trigger an IM reset are covered by the focus changing paths, that also ensure a reset before changing focus between surfaces/actors. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1961 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
* wayland: Reset ClutterInputFocus on focus changesCarlos Garnacho2022-04-231-0/+2
| | | | | | | | | | | | | | Focus changes should trigger an IM reset, as some engines do want to maybe commit the preedit string before changing focus. In addition, we do not want the preedit string to be able to move between windows/applications. Ensure that the commit string is committed when the IM deems so, and ensure we send a .done event disntinct to the .leave event, so that the client doesn't miss the commit. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2030 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
* clutter: Reset ClutterInputFocus on focus_outCarlos Garnacho2022-04-231-1/+1
| | | | | | | | | Focus changes should trigger an IM reset, as some engines do want to maybe commit the preedit buffer before changing focus. Since the preedit string is also cleared on reset(), we can do without that explicit call. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
* clutter: Actively update ClutterText surrounding text on changesCarlos Garnacho2022-04-231-0/+4
| | | | | | | | | | | | Right now we have a bit of a mixed bag between an active model where input foci set the surrounding text without being asked for (e.g. wayland's text_input), and a passive model where the IM engines ask for content. Make ClutterText take the same side than text_input, so that dealing with those is at least consistent. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
View Lorry Controller Status