summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* kms/impl-device: Fix result listener list leakSebastian Keller2023-03-191-1/+1
| | | | | | | queue_result_feedback() takes ownership of the result listeners list via meta_kms_update_take_result_listeners(), but does not free it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2922>
* Bump version to 44.044.0Florian Müllner2023-03-192-1/+15
| | | | Update NEWS.
* Revert "core: Avoid setting up frames on fullscreen windows"Jonas Ådahl2023-03-183-17/+7
| | | | | | | | | | | This caused feedback loops with old statically compiled SDL applications. The bug is fixed in upstream SDL, but that doesn't help when the executables have old SDL's built into them. This reverts commit beeeea546b2145e138a247334d81cfa984da3308. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2678 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2921>
* backends/native: Report correct Gamma support on the KMS properties pathSebastian Wick2023-03-181-6/+7
| | | | | | | | The gamma property blob can be zero to indicate passthrough but Gamma is still supported in that case. Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2686 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2916>
* monitor-manager: Apply switch-config in idle callbackJonas Ådahl2023-03-183-12/+172
| | | | | | | | | | Just as with restoring the previous monitor configuration in case the user clicked "revert" in GNOME Shell's monitor configuration confirmation dialog, we need to do switch configs in an idle callback as well. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2694 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2912>
* core: Retrieve DESKTOP_AUTOSTART_ID early on startupCarlos Garnacho2023-03-182-10/+11
| | | | | | | | | | | | | | | | | | | | With the move away from GTK3, and the indirect dependency on GTK4 grown in the GNOME Shell side, we've indirectly gotten a small sneaky behavioral change: The GTK4 library will, right on dlopen, get DESKTOP_AUTOSTART_ID for itself and delete it from the environment. This happens before our own X11 session management code is initialized, which confuses the hell out of it, into thinking initialization is actually shutdown, gnome-session does not follow along with this request, which leaves GNOME Shell into a confused startup state where it never calls SmcSaveYourselfDone() and grinds startup to a halt until gnome-session decides to move things forward. In order to fix this, get the DESKTOP_AUTOSTART_ID before we lend control to GNOME Shell bits and GTK4 is possibly initialized, and feed it directly to our X11 session manager bits. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2906>
* monitor-manager: Restore old config in idle callback when unconfirmedJonas Ådahl2023-03-182-24/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We might get told to restore the old monitor configuration by the monitor configuration prompt, in case the user pressed "revert" or equivalent. This might be in response to a button press, and those happen during frame clock dispatch. If we would restore an old configuration during dispatch, it means we would reconfigure the monitors including their stage views while dispatching, which means we'd destroy the frame clock while it's dispatching. Doing that causes problems, as the frame clock isn't expecting to be destroyed mid-function. Specifically, We'd enter clutter_frame_clock_dispatch (clutter-frame-clock.c:811) frame_clock_source_dispatch (clutter-frame-clock.c:839) g_main_dispatch (gmain.c:3454) g_main_context_dispatch (gmain.c:4172) g_main_context_iterate.constprop.0 (gmain.c:4248) g_main_loop_run (gmain.c:4448) meta_context_run_main_loop (meta-context.c:482) main (main.c:663) which would first call _clutter_process_event (clutter-main.c:920) _clutter_stage_process_queued_events (clutter-stage.c:757) handle_frame_clock_before_frame (clutter-stage-view.c:1150) which would emit e.g. a button event all the way to a button press handler, which would e.g. deny the new configuration: restore_previous_config (meta-monitor-manager.c:1931) confirm_configuration (meta-monitor-manager.c:2866) meta_monitor_manager_confirm_configuration (meta-monitor-manager.c:2880) meta_plugin_complete_display_change (meta-plugin.c:172) That would then regenerate the monitor configuration and stage view layout, which would destroy the old stage view and frame clock. meta_stage_native_rebuild_views (meta-stage-native.c:68) meta_backend_native_update_screen_size (meta-backend-native.c:457) meta_backend_sync_screen_size (meta-backend.c:266) meta_backend_monitors_changed (meta-backend.c:337) meta_monitor_manager_notify_monitors_changed (meta-monitor-manager.c:3595) meta_monitor_manager_rebuild (meta-monitor-manager.c:3683) meta_monitor_manager_native_apply_monitors_config (meta-monitor-manager-native.c:343) meta_monitor_manager_apply_monitors_config (meta-monitor-manager.c:704) After returning back to the original clutter_frame_clock_dispatch() frame, various state in the frame clock will be gone and we'd crash. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2901>
* monitor-manager: Use g_clear_handle() to clean up D-Bus name owningJonas Ådahl2023-03-181-5/+1
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2901>
* monitor-manager: Use guint for handle IDsJonas Ådahl2023-03-181-3/+2
| | | | | | To follow convention. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2901>
* clutter/frame-clock: Warn if frame clock is disposed while dispatchingJonas Ådahl2023-03-181-0/+2
| | | | | | | This shouldn't happen, but warn anyway to be a bit more helpful if things go bad. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2901>
* Update Korean translationGwan-gyeong Mun2023-03-161-116/+133
|
* Update Czech translationMarek Černocký2023-03-141-16/+12
|
* Update Polish translationPiotr Drąg2023-03-111-92/+93
|
* Updated Danish translationAsk Hjorth Larsen2023-03-101-80/+92
|
* Bump version to 44.rc44.rcFlorian Müllner2023-03-062-1/+42
| | | | Update NEWS.
* prefs: Add get_keybinding_label() methodFlorian Müllner2023-03-062-0/+19
| | | | | | | | | | | | | Commit 7e9d9c7eb91 added new API to replace GTK for accelerator parsing. Unfortunately there is another case in gnome-shell, where we have to get the label from the logical binding name rather than the modifier+keysym combination. Add another small method to cover that use case. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2899>
* core: Avoid focusing windows on map during grabsCarlos Garnacho2023-03-051-0/+9
| | | | | | | | | Normally, mutter implicitly allows a window being shown to take focus. This is normally desired, except it steals input from GNOME Shell self. Avoid focusing the just shown window in those situations. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
* x11: Ignore _NET_ACTIVE_WINDOW client messages while grabbedCarlos Garnacho2023-03-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | When a X11 application is started, typically what happens is: - A startup notification token is created, with a _TIME%d suffix - The application being spawned receives it through the environment - (dbus piping, maybe) - The application replies the startup notification token, and fetches the timestamp from it - The application makes a _NET_ACTIVE_WINDOW client message request with this timestamp - Mutter handles this client request and activates/focuses the window Prevent this last step if windows are not interactable (e.g. there is a compositor grab) and ignore the focus request. This specifically applies to X11 clients requesting focus themselves, and unlike previous approaches, doesn't try to prevent focus changes that do come through interaction with Mutter/GNOME Shell. This should only break if applications do not observe _NET_ACTIVE_WINDOW and perform XSetInputFocus on themselves, but in that case the X11 keyboard focus is stolen from our hands already. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
* Revert "x11/events: Do not update focus XWindow during grabs"Carlos Garnacho2023-03-051-5/+1
| | | | | | This reverts commit 0e6395d93284422848ca3a5ffb88d48fbce7d471. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
* Revert "x11: Do not move X11 input focus during grabs"Carlos Garnacho2023-03-053-26/+0
| | | | | | This reverts commit a68b8e95954772cd6f5d676a803e01c13e48c83f. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
* tests/wayland: Add missing dependenciesRobert Mader2023-03-052-0/+2
| | | | | | They're needed for `ceilf()`. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2895>
* frames: Select SubstructureNotifyMask tooJonas Ådahl2023-03-041-1/+2
| | | | | | | | | | | | | | | This is the mask that lets us receive among other events the rather important CreateNotify, that tells us about new winows. This has went by rather unnoticed except for cases where multiple windows show up very quickly directly after the frames client spawned, because the drag icon surface cache eventually already did select that particular mask. Make things more reliably by explicitly setting the mask for the events we rely on to function. This fixes flaky stacking tests that map multiple X11 windows in a row. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2894>
* tests/wayland: Add test for fractional-scale protocolRobert Mader2023-03-048-2/+411
| | | | | | | For now test that a simple fullscreen client on a FullHD screen selects the expected values. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394>
* tests/build: Order Wayland tests alphabeticallyRobert Mader2023-03-041-6/+13
| | | | | | And ensure they all start with "wayland-" for consistency. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394>
* tests/wayland-client-utils: Use interface names instead of static stringsRobert Mader2023-03-041-6/+6
| | | | | | Let's be a good example here. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394>
* wayland/surface: Export get_buffer_[width|height] to testsRobert Mader2023-03-042-44/+55
| | | | | | It will be used in fractional scale tests. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394>
* wayland: Implement fractional_scale_v1 protocolRobert Mader2023-03-046-0/+243
| | | | | | | | | | Giving clients hints about optimal fractional scaling ratios, to be used together with the `wp_viewport` protocol. See https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/1.31/staging/fractional-scale/fractional-scale-v1.xml Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394>
* meson: Bump wayland-protocols requirement to 1.31Robert Mader2023-03-041-1/+1
| | | | | | Which includes the fractional scaling protocol. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394>
* wayland/surface: Fix can_scanout_untransformed() for transform+viewportRobert Mader2023-03-041-7/+23
| | | | | | | | | The buffer needs to match the untransformed layout size. While on it simplify the check from floats to ints where possible - and improve logging a bit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394>
* tests/build: Move 'service-channel' test to a 'misc' sectionJonas Ådahl2023-03-041-8/+12
| | | | | | | It only has a Wayland test, but might get Wayland unrelated things in the future, so move it away into a "misc" section. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2892>
* constraints: Don't apply titlebar constraint on non-drag user-op moveJonas Ådahl2023-03-041-3/+3
| | | | | | | | | | | | | | 2d8fa26c8e ("core: Pass "frame action" grab operations as an "unconstrained" grab op") changed the behaviour to treat non-grab related window moving that has the "user action" flag set to still apply the "constrain_titlebar_visible" constraint. The fact that it wasn't applied before was relied upon by some extensions. While it should arguably exist a better API that for such extensions to use that have a bit more predictable behavior, until that is so, restore the old semantics. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2891>
* backends/native: Convert MetaOutputColorspace to DRM ColorspaceSebastian Wick2023-03-043-1/+18
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2890>
* cally: Use g_string_free() return valueFlorian Müllner2023-03-041-2/+1
| | | | | | | | glib now warns if the return value is not used, so use the API as intended instead of assigning the character data separately before freeing the GString. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2889>
* shaped-texture: Account for linear sampling when calculating actor damagemsizanoen12023-03-041-4/+15
| | | | | | | | | | | | | | Linear sampling can influence the value of surrounding pixels beyond the scaled framebuffer extents calculated during stage view rendering, resulting in flickering graphical artifacts due to unaccounted pixel changes. This is exhibited in xfreerdp and wlfreerdp at 150% display scaling. Fix this by ensuring that all pixels that may be affected by linear scaling is included in the framebuffer redraw clip by padding the actor redraw clip. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2771>
* Update Bulgarian translationAlexander Shopov2023-03-041-80/+80
|
* tests: Add tests for HDR Static Metadata encoding/decoding and equalitySebastian Wick2023-03-046-2/+147
| | | | | | | | | We have the drm/InfoFrame encoding and our MetaOutputHdrMetadata encoding. Check that we can correctly convert between each other by doing a encode/decode and decode/encode roundtrip and then checking for equality. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* output: Check the EDID for HDR Static Metadata supportSebastian Wick2023-03-044-5/+38
| | | | | | | | The existence of the KMS property just means that we can send an InfoFrame but we also have to make sure the sink actually supports the metadata type 1 and the selected transfer function. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* edid: Fix MetaEdidStaticMetadataType bitmaskSebastian Wick2023-03-041-1/+1
| | | | | | Support for HDR Static Metadata Type 1 is announced in bit 0. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* backends/native: Wire up color space and HDR metadataSebastian Wick2023-03-042-0/+110
| | | | | | | Announce support for color spaces and HDR metadata in OutputKms and prepare KMS update in OnscreenNative. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* backends/native: Process color space and HDR md updatesSebastian Wick2023-03-043-29/+181
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* backends/native: Add color space and HDR metadata updatesSebastian Wick2023-03-043-0/+65
| | | | | | | | | | | | | Allows to prepare KMS updates to set the color space and HDR Static Metadata on the output. For some reason we need ALLOW_MODESET on commits which change the HDR Static Metadata InfoFrame on AMDGPU. There is no technical reason why one needs to mode set to send an InfoFrame and the driver should just manage without ALLOW_MODESET. Until this is resolved in the kernel we just prepare KMS updates which might mode set. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* backends/native: Let updates require ALLOW_MODESETSebastian Wick2023-03-043-1/+11
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* backends/native: Read color space and HDR metadata connector stateSebastian Wick2023-03-042-2/+282
| | | | | | | | The HDR Static Metadata InfoFrame contents are described in CTA-861.3 and the kernel maintains a representation of that in `struct hdr_metadata_infoframe` in `include/uapi/drm/drm_mode.h`. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* backends/native: Add color space and HDR metadata KMS propertiesSebastian Wick2023-03-042-1/+105
| | | | | | | | | | | | | | The Colorspace property informs the display about the colorimetry of the content. Only variants supported by the sink are exposed in the property. The strings representing the color spaces are undocumented but can be found in the `hdmi_colorspaces` list in `drivers/gpu/drm/drm_connector.c` in the Linux kernel (v 6.2). The HDR_OUTPUT_METADATA property is a blob with the InfoFrame content. We have to query support for the different values in the struct from the EDID/DisplayID ourselfs. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* monitor-manager: Make color space and HDR metadata accessible from lgSebastian Wick2023-03-043-0/+157
| | | | | | | | | | | | This adds a new 'experimental-hdr' string property to the MonitorManager which can be changed from looking glass. Currently when the string equals 'on', HDR (PQ, Rec2020) will be enabled on all monitors which support it. In the future support for more transfer functions and color spaces as well as HDR metadata can be added. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* output: Add color space and HDR metadataSebastian Wick2023-03-042-0/+142
| | | | | | | | | | | | | | | | | | The color space and HDR metadata are eventually sent as metadata to the display. The color space informs the display of the colorimetry of the frames we produce, the HDR metadata informs the display of the transfer function and additional mastering display colorimetry and luminance to guide tone and gamut mapping. The only color spaces we support right now are the default color space and Rec bt.2020 which is typically used for HDR content. Other supported color spaces can be added when needed. The default color space corresponds to whatever colorimetry the display has when no further changes are made to the calibration of the display. The colorimetry is communicated to sources via EDID/DisplayID. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* backend/native: Make is-privacy-screen-enabled not CONSTRUCT_ONLYSebastian Wick2023-03-041-1/+0
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
* test: Add a test for "activate" hammeringOlivier Fourdan2023-03-041-0/+35
| | | | | | | | | | | This is what "terminator" (the terminal emulator) does, it basically calls gdk_window_focus() in a loop thousands of times at startup. This in turn fills up the Wayland connection between Xwayland and mutter, and eventually the session dies. See-also: https://github.com/gnome-terminator/terminator/issues/714 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2849>
* tests: Update READMEOlivier Fourdan2023-03-041-2/+1
| | | | | | | | "activate" is no longer a no-op on Wayland, it uses xdg-activation. Update the README accordingly. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2849>
* startup-notification: Delay cursor feedback updatesOlivier Fourdan2023-03-041-3/+38
| | | | | | | | | | | A Wayland client repeatedly requesting activation of its surface using the xdg-activation protocol would make mutter constantly update the cursor. To avoid needlessly updating the cursor back and forth between busy and default, add a timeout to delay the update. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2849>
View Lorry Controller Status