isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-25 09:30:45 -05:00
Code Issues Packages Projects Releases Wiki Activity
358c10de14
mutter/src/meson.build

1298 lines
39 KiB
Meson
Raw Normal View History

build: Use / operator instead of join_paths everywhere Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2985>
2023-05-04 07:49:59 -04:00
mutter_includesubdir = pkgname / 'meta'
mutter_includedir = includedir / mutter_includesubdir
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
mutter_includes = [
include_directories('.'),
top_includepath,
clutter_includepath,
cogl_includepath,
]
mutter_lib_deps = [
m_dep,
]
mutter_pkg_deps = [
cairo_dep,
gio_unix_dep,
glib_dep,
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
gsettings_desktop_schemas_dep,
pango_dep,
]
mutter_pkg_private_deps = [
color-manager: Take over color device management from gsd-color Previously, gsd-color handled adding color devices. It got information about those via the GnomeRR API, which is part of libgnome-desktop. libgnome-desktop itself got this information from the org.gnome.Mutter.DisplayConfig.GetResources() D-Bus method, implemented by mutter. Now, mutter itself will add all the monitor color devices itself, without having to go via gsd-color. We sometimes need to delete colord devices synchronously, in certain race conditions when we add and remove devices very quickly (e.g. in tests). However, we cannot use libcolord's 'sync' API variants, as it has a nested takes-all main loop as a way to invoke the sync call. This effectively means we end up sometimes not return from this function in a timely manner, causing wierd issues. Instead, create our own sync helper, that uses a separate context that we temporarly push as the thread-default one. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
2021-10-27 16:47:06 -04:00
colord_dep,
color-manager: Maintain a lcms context Will be used from other color related units later on. This also adds an explicit dependency on LCMS2. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
2022-07-27 07:30:15 -04:00
lcms2_dep,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
gmodule_no_export_dep,
gnome_settings_daemon_dep,
json_glib_dep,
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
xkbcommon_dep,
input-capture: Hook up capturing of events to active session This adds the actual input capturing rerouting that takes events and first hands them to the input capture session, would it be active. Events are right now not actually processed in any way, but will eventually be passed to a libei client using libeis. A key binding for allowing cancelling the capture session is added (defaults to <Super><Shift>Escape) to avoid getting stuck in case the client doesn't even terminate the session. The added test case makes sure that the pointer moves again after pressing the keybinding. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
2022-04-27 04:50:43 -04:00
libeis_dep,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
]
meson: Allow to build without gnome-desktop gnome-desktop is used to retrieve the monitor vendor name which in some use cases is not needed as it brings a bunch of gnome-desktop unwanted dependencies. The change makes mutter fallback to an "Undefined" vendor name if it is built without gnome-desktop Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2317>
2022-03-03 05:51:00 -05:00
if have_gnome_desktop
mutter_pkg_private_deps += [
gnome_desktop_dep,
]
endif
edid: Integrate libdisplay-info for edid parsing Hides libdisplay-info under a build time default-off flag, provides provision to parse essential edid parameters with APIs provided by libdisplay-info. This implementaion increases readibility, avoids code duplication and decreases complexity of edid parsing. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2642>
2023-03-07 00:21:19 -05:00
if have_libdisplay_info
mutter_pkg_private_deps += [
libdisplay_info_dep,
]
endif
core: Make sound player feature optional Mutter can play sounds in some contexts and also provides an API for libmutter users to do so using libcanberra internally. In some specific use cases of Mutter, we would like to not depend on libcanberra and not have any sound playing feature by default. The changes keeps the sound player API but make it no-op if the sound_player feature is disabled to not make it possible to break a gnome-shell build. See https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2270 for relevant discussion Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2375>
2022-04-26 09:00:46 -04:00
if have_sound_player
mutter_pkg_private_deps += [
libcanberra_dep,
]
endif
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
if have_gl
mutter_pkg_deps += [
gl_dep,
]
endif
if have_gles2
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
mutter_pkg_private_deps += [
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
gles2_dep,
]
endif
if have_egl
mutter_pkg_deps += [
egl_dep,
]
endif
if have_libgudev
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
mutter_pkg_private_deps += [
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
gudev_dep,
libudev_dep,
]
endif
if have_startup_notification
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
mutter_pkg_private_deps += [
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
libstartup_notification_dep,
]
endif
if have_libwacom
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
mutter_pkg_private_deps += [
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
libwacom_dep,
]
endif
if have_remote_desktop
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
mutter_pkg_private_deps += [
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
libpipewire_dep,
backends/eis: Add EIS client support This adds support for EIS clients in the form of MetaEis and MetaEisClient. The purpose is to allow clients to connect and send emulated input events using EIS. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
2021-08-16 19:09:59 -04:00
libeis_dep,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
]
endif
if have_introspection
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
mutter_pkg_private_deps += [
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
gobject_introspection_dep,
]
endif
if have_x11
mutter_pkg_deps += [
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
xfixes_dep,
xi_dep,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
x11_dep,
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
]
mutter_pkg_private_deps += [
xrandr_dep,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
xinerama_dep,
xext_dep,
ice_dep,
xcomposite_dep,
xcursor_dep,
xdamage_dep,
xkbfile_dep,
xkeyboard_config_dep,
xkbcommon_x11_dep,
xrender_dep,
x11_xcb_dep,
xcb_randr_dep,
xcb_res_dep,
xwayland: Generate a Xauth file and pass this to Xwayland when starting it Before this commit, sudo x11-app, e.g. sudo gvim /etc/some-file, fails when running a Wayland session. Where as doing this under a "GNOME on Xorg" session works fine. For a user switching from the Xorg session to the Wayland session, this is regression, which we want to avoid. This commit fixes this by creating and passing an xauth file to Xwayland when mutter starts it. Just like gdm or startx pass a xauth file to Xorg when they start Xorg. Fixes #643 https://gitlab.gnome.org/GNOME/mutter/issues/643
2019-06-18 10:12:46 -04:00
xau_dep,
clutter: Move X11 input to src/backends/x11 The end goal is to have all clutter backend code in src/backends. Input is the larger chunk of it, which is now part of our specific MutterClutterBackendX11, this extends to device manager, input devices, tools and keymap. This was supposed to be nice and incremental, but there's no sane way to cut this through. As a result of the refactor, a number of private Clutter functions are now exported for external backends to be possible. https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
2019-03-22 08:53:00 -04:00
xtst_dep,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
]
if have_sm
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
mutter_pkg_private_deps += [
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
sm_dep,
]
endif
endif
if have_wayland
mutter_pkg_deps += [
wayland_server_dep,
]
endif
meson: Add optional libsystemd dependency To utilize the API provided by libsystemd it would be better to create a separate HAVE_LIBSYSTEMD configuration option instead of having to rely on HAVE_NATIVE_BACKEND. For now this will be utilized for getting the control group of a MetaWindow. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1960>
2021-08-05 10:07:28 -04:00
if have_libsystemd
mutter_pkg_private_deps += [
libsystemd_dep,
]
endif
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
if have_native_backend
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
mutter_pkg_private_deps += [
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
libinput_dep,
gudev_dep,
libgbm_dep,
logind_provider_dep,
clutter: Move evdev input to src/backends/native The end goal is to have all clutter backend code in src/backends. Input is the larger chunk of it, which is now part of our specific MutterClutterBackendNative, this extends to device manager, input devices, tools and keymap. This was supposed to be nice and incremental, but there's no sane way to cut this through. As a result of the refactor, a number of private Clutter functions are now exported for external backends to be possible. https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
2019-03-29 17:03:27 -04:00
libudev_dep,
xkbcommon_dep,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
]
endif
backend/cogl-utils: Move, rename to cogl-drm-formats and clean up 1. Move into the new 'common' folder and build for Wayland as well so we will be able to share the code in follow-up commits. 2. Rename to cogl-drm-formats to make it more obvious that the format map is more than an utility these days. 3. Drop the unused CoglTextureComponents part (see also previous commit). 4. Move the map to the header, simplifying some future use-cases. 5. Sync formats with MetaWaylandBuffer and MetaWaylandDmaBufBuffer and also use newly introduced opaque formats where appropriate. This avoids duplicated code, ensures that new drm-formats added to the dmabuf protocol have an adequate representation in Cogl from which information like alpha support can be easily derived and finally ensures we don't crash if the mappings got out of sync. 6. Remove some likely untested formats. In case some of these are actually needed on certain hardware, we can test whether we got the correct mapping by also adding support for the corresponding wl_shm_format in MetaWaylandBuffer by extending the gradient test in https://gitlab.freedesktop.org/jadahl/wayland-test-clients Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
2023-06-09 02:03:53 -04:00
if have_wayland or have_native_backend
mutter_pkg_private_deps += [
libdrm_dep,
]
endif
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
if have_wayland_eglstream
mutter_lib_deps += [
dl_dep,
]
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
mutter_pkg_private_deps += [
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
wayland_eglstream_protocols_dep,
]
endif
mutter_deps = [
mutter_pkg_deps,
meson: Don't list libraries private dependencies in pc files pkg-config files for mutter are generated using *_pkg_deps as requires, but programs linked with libmutter doesn't need most of these private dependencies which are only needed for building and linking mutter and its subprojects. So list packages needed only by mutter itself inside *_pkg_private_deps and don't expose such packages to pkg-config, but only use them at build time. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-21 06:13:48 -05:00
mutter_pkg_private_deps,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
mutter_lib_deps,
]
mutter_c_args = [
'-DCLUTTER_ENABLE_COMPOSITOR_API',
'-DCOGL_ENABLE_EXPERIMENTAL_API',
'-DCOGL_ENABLE_EXPERIMENTAL_2_0_API',
'-DCOGL_ENABLE_MUTTER_API',
'-DCLUTTER_DISABLE_DEPRECATION_WARNINGS',
'-DCOGL_DISABLE_DEPRECATION_WARNINGS',
'-DSN_API_NOT_YET_FROZEN=1',
'-DGETTEXT_PACKAGE="@0@"'.format(meson.project_name()),
]
if get_option('verbose')
mutter_c_args += [
'-DWITH_VERBOSE_MODE'
]
endif
mutter_sources = [
'backends/edid.h',
'backends/edid-parse.c',
'backends/gsm-inhibitor-flag.h',
'backends/meta-backend.c',
'backends/meta-backend-private.h',
'backends/meta-barrier.c',
'backends/meta-barrier-private.h',
color-manager: Take over color device management from gsd-color Previously, gsd-color handled adding color devices. It got information about those via the GnomeRR API, which is part of libgnome-desktop. libgnome-desktop itself got this information from the org.gnome.Mutter.DisplayConfig.GetResources() D-Bus method, implemented by mutter. Now, mutter itself will add all the monitor color devices itself, without having to go via gsd-color. We sometimes need to delete colord devices synchronously, in certain race conditions when we add and remove devices very quickly (e.g. in tests). However, we cannot use libcolord's 'sync' API variants, as it has a nested takes-all main loop as a way to invoke the sync call. This effectively means we end up sometimes not return from this function in a timely manner, causing wierd issues. Instead, create our own sync helper, that uses a separate context that we temporarly push as the thread-default one. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
2021-10-27 16:47:06 -04:00
'backends/meta-color-device.c',
'backends/meta-color-device.h',
backend: Add color manager skeleton Create a color manager type that eventually will be the high level manager of color related behavior, such as ICC profiles and color "temperature" a.k.a. night light. For now, it's only an empty shell. It's also constructed by the actual backend, as at a later point, the X11 and native color management implementations will differ. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
2021-10-25 04:50:02 -04:00
'backends/meta-color-manager.c',
'backends/meta-color-manager.h',
'backends/meta-color-manager-private.h',
color: Generate and store ICC profiles from EDID or EFI Just as gsd-color does, generate color profiles. This can either be done from EFI, if available and the color device is associated with a built in panel, or from the EDID. If no source for a profile is found, none is created. The ICC profiles are also stored on disk so that they can be read by e.g. colord. The on disk stored profiles will only be used for storing, not reading the profiles, as the autogenerated ones will no matter what always be loaded to verify the on disk profiles are up to date. If a on disk profile is not, it will be replaced. This is so that fixes or improvements to the profile generation will be made available despite having run an older version earlier. After generating, add some metadata about the generated file itself needed by colord, i.e. file MD5 checksum and the file path. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
2021-11-29 14:44:56 -05:00
'backends/meta-color-profile.c',
'backends/meta-color-profile.h',
'backends/meta-color-store.c',
'backends/meta-color-store.h',
crtc: Move out MetaCrtcMode into its own file It's somewhat annoying to have two very closely named types in the same file. It's also about to grow some, so better move it to its own file. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 15:46:58 -05:00
'backends/meta-crtc-mode.c',
'backends/meta-crtc-mode.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-crtc.c',
'backends/meta-crtc.h',
'backends/meta-cursor.c',
'backends/meta-cursor.h',
'backends/meta-cursor-renderer.c',
'backends/meta-cursor-renderer.h',
'backends/meta-cursor-sprite-xcursor.c',
'backends/meta-cursor-sprite-xcursor.h',
'backends/meta-cursor-tracker.c',
'backends/meta-cursor-tracker-private.h',
backends: Add generic D-Bus session manager helper class This class is intended to be used as a base class for D-bus interface implementations that deal with "session" objects, i.e. a D-Bus object representing a certain session of some kind, e.g. a screen cast session. It handles things such as hooking up to the D-Bus client watcher, generates IDs, handles shutdown procedures. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
2022-03-10 18:20:27 -05:00
'backends/meta-dbus-session-manager.c',
'backends/meta-dbus-session-manager.h',
'backends/meta-dbus-session-watcher.c',
'backends/meta-dbus-session-watcher.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-display-config-shared.h',
'backends/meta-dnd-private.h',
seat/impl: Move out the GSource implementation to a helper object This will help adding similar sources that work practically the same. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
2022-04-13 05:40:53 -04:00
'backends/meta-fd-source.c',
'backends/meta-fd-source.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-gpu.c',
'backends/meta-gpu.h',
'backends/meta-idle-monitor.c',
backends: Introduce MetaIdleManager This object takes over the functionality of meta-idle-monitor-dbus.c, meta-idle-monitor.c and meta-backend.c, all related to higher level management of idle watches etc. The idle D-Bus API is changed to be initialized by the backend instead of MetaDisplay, as it's more of a backend functionality than what MetaDisplay usually deals with. It also takes over the work of implementing "core" idle monitors. The singleton API is replaced with thin wrapper functions on the backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1859>
2021-04-19 09:22:57 -04:00
'backends/meta-idle-manager.c',
'backends/meta-idle-manager.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-idle-monitor-private.h',
Add beginning of input capture API This API aims to provide a way for users to capture input devices under certain conditions, for example when a pointer crosses a specified barrier. So far only part of the API is implemented, specifially the session management as well as zone advertisement, where a zone refers to a region in the compositor which edges will eventually be made available for barrier placement. So far the remote access handle is created while the session is enable, despite the input capturing isn't actually active yet. This will change in the future once it can actually become active. v2: Remove absolute/relative pointer, keep only pointer (ofourdan) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
2022-03-30 11:27:51 -04:00
'backends/meta-input-capture.c',
'backends/meta-input-capture.h',
'backends/meta-input-capture-session.c',
'backends/meta-input-capture-session.h',
backends: Add MetaInputDevice derivable class This class sits between ClutterInputDevice and the backend implementations, it will be the despositary of features we need across both backends, but don't need to offer through Clutter's API. As a first thing to have there, add a getter for a WacomDevice. This is something scattered across and somewhat inconsistent (eg. different places of the code create wacom devices for different device types). Just make it here for all devices, so users can pick. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1109
2020-03-06 08:12:59 -05:00
'backends/meta-input-device.c',
backends: Add MetaInputMapper This object takes care of mapping absolute devices to monitors, to do so it uses 3 heuristics, in this order of preference: - If a device is known to be builtin, it's assigned to the builtin monitor. - If input device and monitor match sizes (with an error margin of 5%) - If input device name and monitor vendor/product in EDID match somehow (from "full", through "partial", to just "vendor") The most favorable outputs are then assigned to each device, making sure not to assign two devices of the same kind to the same output. This object replaces (and is mostly 1:1 with) GsdDeviceMapper in g-s-d. That object would perform these same heuristics, and let mutter indirectly know through settings changes. This object allows doing the same in-process.
2018-04-20 10:34:32 -04:00
'backends/meta-input-mapper.c',
'backends/meta-input-mapper-private.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-input-settings.c',
'backends/meta-input-settings-private.h',
backends/x11: Add dummy input-settings implementation The nested backend may need to have an input setting implementation, while we don't want to change the host settings (re-using an X11 input settings) we can add a dummy implementation, until something more complex is needed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1769>
2021-03-09 21:18:13 -05:00
'backends/meta-input-settings-dummy.c',
'backends/meta-input-settings-dummy.h',
compositor: use XDG_CONFIG_HOME as initial lookup path for xkb Using XDG_CONFIG_HOME allows users to place their keyboard configuration into their home directory and have them loaded automatically. libxkbcommon now defaults to XDG_CONFIG_HOME/xkb/ first, see https://github.com/xkbcommon/libxkbcommon/pull/117 However - libxkbcommon uses secure_getenv() to obtain XDG_CONFIG_HOME and thus fails to load this for the mutter context which has cap_sys_nice. We need to manually add that search path as lookup path. As we can only append paths to libxkbcommon's context, we need to start with an empty search path set, add our custom path, then append the default search paths. The net effect is nil where a user doesn't have XDG_CONFIG_HOME/xkb/. https://gitlab.gnome.org/GNOME/mutter/merge_requests/936
2019-11-13 21:59:25 -05:00
'backends/meta-keymap-utils.c',
'backends/meta-keymap-utils.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-logical-monitor.c',
'backends/meta-logical-monitor.h',
'backends/meta-monitor.c',
'backends/meta-monitor-config-manager.c',
'backends/meta-monitor-config-manager.h',
'backends/meta-monitor-config-migration.c',
'backends/meta-monitor-config-migration.h',
'backends/meta-monitor-config-store.c',
'backends/meta-monitor-config-store.h',
'backends/meta-monitor.h',
'backends/meta-monitor-manager.c',
'backends/meta-monitor-manager-dummy.c',
'backends/meta-monitor-manager-dummy.h',
'backends/meta-monitor-manager-private.h',
monitor-transform: Add helper function transform_invert() It returns the inverted transform, which is always the same as the input, besides for TRANSFORM_90 and TRANSFORM_270. https://gitlab.gnome.org/GNOME/mutter/merge_requests/366
2019-01-05 08:18:02 -05:00
'backends/meta-monitor-transform.c',
monitor-transform: Move helper functions into their own file The existing ones are statically inlined, so there is no .c file right now. https://gitlab.gnome.org/GNOME/mutter/merge_requests/366
2019-01-05 08:15:23 -05:00
'backends/meta-monitor-transform.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-orientation-manager.c',
'backends/meta-orientation-manager.h',
'backends/meta-output.c',
'backends/meta-output.h',
'backends/meta-pointer-constraint.c',
'backends/meta-pointer-constraint.h',
'backends/meta-remote-access-controller-private.h',
'backends/meta-remote-access-controller.c',
'backends/meta-renderer.c',
'backends/meta-renderer.h',
'backends/meta-renderer-view.c',
'backends/meta-renderer-view.h',
screen-cast: Add screen-cast-window interface Typically, to stream the content of a window, we need a way to copy the content of its window-actor into a buffer, transform relative input coordinates to relative position within the window-actor and a mean to get the window bounds within the buffer. For this purpose, add a new GType interface `MetaScreenCastWindow` with the methods needed for screen-cast window mode: * meta_screen_cast_window_get_buffer_bounds() * meta_screen_cast_window_get_frame_bounds() * meta_screen_cast_window_transform_relative_position() * meta_screen_cast_window_capture_into() This interface is meant to be implemented by `MetaWindowActor` which has access to all the necessary bits to implement them. https://gitlab.gnome.org/GNOME/mutter/merge_requests/306
2018-12-05 02:48:41 -05:00
'backends/meta-screen-cast-window.c',
'backends/meta-screen-cast-window.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-settings.c',
'backends/meta-settings-private.h',
'backends/meta-stage.c',
clutter: Move ClutterStageCogl[View] code to src/backends This is now MetaStageImpl in backend code. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1862>
2021-05-10 07:27:39 -04:00
'backends/meta-stage-impl.c',
'backends/meta-stage-impl-private.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-stage-private.h',
backends: Excise MetaStageView to its own file It was implemented together with MetaStageImpl, move it to a separate file. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1862>
2021-05-10 15:56:19 -04:00
'backends/meta-stage-view.c',
'backends/meta-stage-view-private.h',
backends: Add simple object to delegate logical monitor layout queries This object can be passed to random places, and be trusted to remain unchanged till replaced. Makes it an ideal replacement for MetaMonitorManager across threads. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-07-16 07:52:39 -04:00
'backends/meta-viewport-info.c',
'backends/meta-viewport-info.h',
Introduce virtual monitors Virtual monitors are monitors that isn't backed by any monitor like hardware. It would typically be backed by e.g. a remote desktop service, or a network display. It is currently only supported by the native backend, and whether the X11 backend will ever see virtual monitors is an open question. This rest of this commit message describes how it works under the native backend. Each virutal monitor consists of virtualized mode setting components: * A virtual CRTC mode (MetaCrtcModeVirtual) * A virtual CRTC (MetaCrtcVirtual) * A virtual connector (MetaOutputVirtual) In difference to the corresponding mode setting objects that represents KMS objects, the virtual ones isn't directly tied to a MetaGpu, other than the CoglFramebuffer being part of the GPU context of the primary GPU, which is the case for all monitors no matter what GPU they are connected to. Part of the reason for this is that a MetaGpu in practice represents a mode setting device, and its CRTCs and outputs, are all backed by real mode setting objects, while a virtual monitor is only backed by a framebuffer that is tied to the primary GPU. Maybe this will be reevaluated in the future, but since a virtual monitor is not tied to any GPU currently, so is the case for the virtual mode setting objects. The native rendering backend, including the cursor renderer, is adapted to handle the situation where a CRTC does not have a GPU associated with it; this in practice means that it e.g. will not try to upload HW cursor buffers when the cursor is only on a virtual monitor. The same applies to the native renderer, which is made to avoid creating MetaOnscreenNative for views that are backed by virtual CRTCs, as well as to avoid trying to mode set on such views. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-26 10:49:28 -05:00
'backends/meta-virtual-monitor.c',
'backends/meta-virtual-monitor.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'compositor/clutter-utils.c',
'compositor/clutter-utils.h',
'compositor/cogl-utils.c',
'compositor/cogl-utils.h',
'compositor/compositor.c',
'compositor/compositor-private.h',
core: Move edge-resistance handling to src/compositor This is now something that is mainly handled from the compositor side, so it makes sense to move it there. Following commits will cut all ties with src/core. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
2022-10-27 11:47:06 -04:00
'compositor/edge-resistance.c',
'compositor/edge-resistance.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'compositor/meta-background-actor.c',
'compositor/meta-background-actor-private.h',
Introduce MetaBackgroundContent MetaBackgroundContent is a ClutterContent implementation that can render a background to any attached actor. Right now, it preserves all the properties and the rendering model of MetaBackgroundActor. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
2020-06-08 20:49:55 -04:00
'compositor/meta-background-content.c',
'compositor/meta-background-content-private.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'compositor/meta-background.c',
'compositor/meta-background-group.c',
'compositor/meta-background-image.c',
'compositor/meta-background-private.h',
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
2019-09-12 16:07:20 -04:00
'compositor/meta-compositor-server.c',
'compositor/meta-compositor-server.h',
compositor: Introduce MetaCompositorView MetaCompositorView is a class which contains compositor logic specific to ClutterStageViews. Each MetaCompositorView is "attached" to a ClutterStageView as an opaque pointer using g_object_set_qdata_full (), and is freed when the ClutterStageView is destroyed. This ensures that the lifetime of the MetaCompositorView can't extend beyond the lifetime of its ClutterStageView. In a following commit, MetaCompositorView will be expanded to allow keeping track of the top MetaWindowActor located on each ClutterStageView. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
2022-07-10 07:44:34 -04:00
'compositor/meta-compositor-view.c',
'compositor/meta-compositor-view.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'compositor/meta-cullable.c',
'compositor/meta-cullable.h',
'compositor/meta-dnd-actor.c',
'compositor/meta-dnd-actor-private.h',
'compositor/meta-dnd.c',
'compositor/meta-feedback-actor.c',
'compositor/meta-feedback-actor-private.h',
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-03-03 02:46:11 -05:00
'compositor/meta-later.c',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'compositor/meta-module.c',
'compositor/meta-module.h',
'compositor/meta-plugin.c',
'compositor/meta-plugin-manager.c',
'compositor/meta-plugin-manager.h',
'compositor/meta-shadow-factory.c',
'compositor/meta-shaped-texture.c',
'compositor/meta-shaped-texture-private.h',
'compositor/meta-surface-actor.c',
'compositor/meta-surface-actor.h',
shaped-texture: Move texture mipmap implementation to 'meta-texture-mipmap' Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2506>
2022-06-10 19:13:57 -04:00
'compositor/meta-texture-mipmap.c',
'compositor/meta-texture-mipmap.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'compositor/meta-window-actor.c',
'compositor/meta-window-actor-private.h',
compositor: Add MetaWindowDrag helper object This compositor-side object will single-handedly drive a window drag operation. Currently, this largely copies meta_display_begin_grab_op and meta_display_end_grab_op, except grabbing is done through a ClutterGrab instead of direct meta_backend_grab_device() calls. This also means that the switch from passive to active keyboard grabs is handled differently. Currently, this object is dormant. It requires moving more code from other places to become a fully functional replacement. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
2022-10-20 09:57:47 -04:00
'compositor/meta-window-drag.c',
'compositor/meta-window-drag.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'compositor/meta-window-group.c',
'compositor/meta-window-group-private.h',
'compositor/meta-window-shape.c',
'compositor/region-utils.c',
'compositor/region-utils.h',
'core/bell.c',
'core/bell.h',
'core/boxes.c',
'core/boxes-private.h',
'core/constraints.c',
'core/constraints.h',
'core/delete.c',
'core/display.c',
'core/display-private.h',
'core/events.c',
'core/events.h',
'core/frame.c',
'core/frame.h',
'core/keybindings.c',
'core/keybindings-private.h',
'core/meta-accel-parse.c',
'core/meta-accel-parse.h',
Add read-only anonymous file abstraction MetaAnonymousFile Add MetaAnonymousFile, an abstraction around anonymous read-only files. Files can be created by calling meta_anonymous_file_new(), passing the data of the file. Subsequent calls to meta_anonymous_file_open_fd() return a fd that's ready to be sent over the socket. When mapmode is META_ANONYMOUS_FILE_MAPMODE_PRIVATE the fd is only guaranteed to be mmap-able readonly with MAP_PRIVATE but does not require duplicating the file for each resource when memfd_create is available. META_ANONYMOUS_FILE_MAPMODE_SHARED may be used when the client must be able to map the file with MAP_SHARED but it also means that the file has to be duplicated even when memfd_create is available. Pretty much all of this code was written for weston by Sebastian Wick, see https://gitlab.freedesktop.org/wayland/weston/merge_requests/240. Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net> https://gitlab.gnome.org/GNOME/mutter/merge_requests/1012
2020-01-17 17:43:24 -05:00
'core/meta-anonymous-file.c',
'core/meta-anonymous-file.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'core/meta-border.c',
'core/meta-border.h',
core: Add clipboard manager This is a simple clipboard manager implementation on top of MetaSelection. It will inspect the clipboard content for UTF-8 text and image data whenever any other selection source claims ownership, and claim it for itself whenever the clipboard goes unowned. The stored text has a maximum size of 4MB and images 200MB, to prevent the compositor from allocating indefinite amounts of memory. This is not quite a X11 clipboard manager, but also works there. https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
2018-11-19 13:57:15 -05:00
'core/meta-clipboard-manager.c',
'core/meta-clipboard-manager.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'core/meta-close-dialog.c',
Introduce MetaContextMain This object intends to replace the scattered functions that are used to make up what is effectively a "mutter context". It takes care of the command line arguments that is now done in main.c, persistant virtual monitors, and the like. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
2021-03-03 05:31:24 -05:00
'core/meta-context-main.c',
'core/meta-context-main.h',
Introduce mostly empty MetaContext type This type is intended to replace the scattered functions used to configure how the Mutter compositor is run. It currently doesn't do anything, and only has a human readable name, intended to be set to e.g. "GNOME Shell". It's an abstract type, and is intended to be used via either a future `MetaContextMain` for real display server use cases, and a `MetaContextTest` for test cases. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
2021-03-02 03:31:19 -05:00
'core/meta-context-private.h',
'core/meta-context.c',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'core/meta-fraction.c',
'core/meta-fraction.h',
'core/meta-gesture-tracker.c',
'core/meta-gesture-tracker-private.h',
'core/meta-inhibit-shortcuts-dialog.c',
'core/meta-inhibit-shortcuts-dialog-default.c',
'core/meta-inhibit-shortcuts-dialog-default-private.h',
core: Add MetaLaunchContext This is a GAppLaunchContext subclass meant to replace usage of GdkAppLaunchContext in gnome-shell. Launch contexts get created from the MetaStartupNotification as they are closely related. The messaging underneath depends on the availability of a X11 display, if there is one we go through it (and libsn). If there is none, we still create startup sequences manually for wayland clients.
2018-12-13 13:02:19 -05:00
'core/meta-launch-context.c',
backends: Split pad action mapping to a separate object This now lives in the core, and will get updated from events in the UI thread. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-07-15 16:38:00 -04:00
'core/meta-pad-action-mapper.c',
main: Move MetaX11DisplayPolicy to a new meta-private-enums.h As with the compositor type enum, also have the X11 display policy enum, as it's also effectively part of the context configuration. But as with the compositor type, move it to a header file for enums only, and since this is a private one, create a private variant meta-enums.h. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
2021-03-02 04:21:20 -05:00
'core/meta-private-enums.h',
core: Add MetaSelection and MetaSelectionSource MetaSelectionSource represents a primary/clipboard/dnd selection owner, it is an abstract type so wayland/x11/etc implementations can be provided. These 3 selections are managed by the MetaSelection object, the current selection owners will be set there, and signals will be emitted so the previous selection owner can clean itself up. The actual data transfer is done through the meta_selection_transfer_async() call, which will take a GOutputStream and create a corresponding GInputStream from the MetaSelectionSource in order to splice them. https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
2018-11-19 10:45:20 -05:00
'core/meta-selection.c',
'core/meta-selection-source.c',
core: Add memory-based selection source This is a simple implementation of a MetaSelectionSource, able to hold a single mimetype, provided as GBytes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
2018-11-19 13:50:21 -05:00
'core/meta-selection-source-memory.c',
core: Add MetaSoundPlayer abstraction This is a simple libcanberra abstraction object, so we are able to play file/theme sounds without poking into GTK+/X11. Play requests are delegated to a separate thread, so we don't block UI on cards that are slow to wake up from power saving.
2018-12-09 06:44:20 -05:00
'core/meta-sound-player.c',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'core/meta-workspace-manager.c',
'core/meta-workspace-manager-private.h',
'core/place.c',
'core/place.h',
prefs: Make init function private Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1833>
2021-03-01 15:49:10 -05:00
'core/prefs-private.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'core/prefs.c',
'core/restart.c',
'core/stack.c',
'core/stack.h',
'core/stack-tracker.c',
'core/stack-tracker.h',
'core/startup-notification.c',
'core/startup-notification-private.h',
'core/util.c',
'core/util-private.h',
'core/window.c',
'core/window-private.h',
'core/workspace.c',
'core/workspace-private.h',
]
meson: Split x11 option into backend/xwayland Allow disabling either the xwayland or backend implementation of x11. Meson options were not added as this is more of a groundwork than the actual implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2354>
2022-03-25 06:50:52 -04:00
if have_x11
mutter_sources += [
'backends/x11/cm/meta-backend-x11-cm.c',
'backends/x11/cm/meta-backend-x11-cm.h',
'backends/x11/cm/meta-cursor-sprite-xfixes.c',
'backends/x11/cm/meta-cursor-sprite-xfixes.h',
'backends/x11/cm/meta-renderer-x11-cm.c',
'backends/x11/cm/meta-renderer-x11-cm.h',
'backends/x11/meta-backend-x11.c',
'backends/x11/meta-backend-x11.h',
'backends/x11/meta-barrier-x11.c',
'backends/x11/meta-barrier-x11.h',
'backends/x11/meta-clutter-backend-x11.c',
'backends/x11/meta-clutter-backend-x11.h',
x11: Add X11 color manager subclass This is used as part of the X11 backend to updated X11 root window properties according to the ICC Profiles in X Specification. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2166>
2021-12-06 05:47:00 -05:00
'backends/x11/meta-color-manager-x11.c',
'backends/x11/meta-color-manager-x11.h',
meson: Split x11 option into backend/xwayland Allow disabling either the xwayland or backend implementation of x11. Meson options were not added as this is more of a groundwork than the actual implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2354>
2022-03-25 06:50:52 -04:00
'backends/x11/meta-crtc-xrandr.c',
'backends/x11/meta-crtc-xrandr.h',
'backends/x11/meta-cursor-renderer-x11.c',
'backends/x11/meta-cursor-renderer-x11.h',
'backends/x11/meta-cursor-tracker-x11.c',
'backends/x11/meta-cursor-tracker-x11.h',
'backends/x11/meta-event-x11.c',
'backends/x11/meta-event-x11.h',
'backends/x11/meta-gpu-xrandr.c',
'backends/x11/meta-gpu-xrandr.h',
'backends/x11/meta-input-device-x11.c',
'backends/x11/meta-input-device-x11.h',
'backends/x11/meta-input-device-tool-x11.c',
'backends/x11/meta-input-device-tool-x11.h',
'backends/x11/meta-input-settings-x11.c',
'backends/x11/meta-input-settings-x11.h',
'backends/x11/meta-seat-x11.c',
'backends/x11/meta-seat-x11.h',
'backends/x11/meta-keymap-x11.c',
'backends/x11/meta-keymap-x11.h',
'backends/x11/meta-monitor-manager-xrandr.c',
'backends/x11/meta-monitor-manager-xrandr.h',
'backends/x11/meta-output-xrandr.c',
'backends/x11/meta-output-xrandr.h',
'backends/x11/meta-renderer-x11.c',
'backends/x11/meta-renderer-x11.h',
'backends/x11/meta-stage-x11.c',
'backends/x11/meta-stage-x11.h',
'backends/x11/meta-virtual-input-device-x11.c',
'backends/x11/meta-virtual-input-device-x11.h',
'backends/x11/meta-xkb-a11y-x11.c',
'backends/x11/meta-xkb-a11y-x11.h',
'backends/x11/nested/meta-backend-x11-nested.c',
'backends/x11/nested/meta-backend-x11-nested.h',
'backends/x11/nested/meta-cursor-renderer-x11-nested.c',
'backends/x11/nested/meta-cursor-renderer-x11-nested.h',
'backends/x11/nested/meta-stage-x11-nested.c',
'backends/x11/nested/meta-stage-x11-nested.h',
'backends/x11/nested/meta-renderer-x11-nested.c',
'backends/x11/nested/meta-renderer-x11-nested.h',
]
endif
if have_x11_client
mutter_sources += [
'compositor/meta-compositor-x11.c',
'compositor/meta-compositor-x11.h',
'compositor/meta-surface-actor-x11.c',
'compositor/meta-surface-actor-x11.h',
'compositor/meta-sync-ring.c',
'compositor/meta-sync-ring.h',
'compositor/meta-window-actor-x11.c',
'compositor/meta-window-actor-x11.h',
'x11/atomnames.h',
'x11/events.c',
'x11/events.h',
'x11/group.c',
'x11/group-private.h',
'x11/group-props.c',
'x11/group-props.h',
'x11/iconcache.c',
'x11/iconcache.h',
'x11/meta-selection-source-x11.c',
'x11/meta-selection-source-x11-private.h',
'x11/meta-startup-notification-x11.c',
'x11/meta-startup-notification-x11.h',
x11: Add standalone MetaSyncCounter helper struct This helper struct takes care of the handling of requests and alarms in order to satisfy NET_WM_SYNC_REQUEST. It will be necessary to decouple rendering of windows and frames in future commits, so each window may need its own synchronization and accounting. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
2022-09-07 08:24:24 -04:00
'x11/meta-sync-counter.c',
'x11/meta-sync-counter.h',
meson: Split x11 option into backend/xwayland Allow disabling either the xwayland or backend implementation of x11. Meson options were not added as this is more of a groundwork than the actual implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2354>
2022-03-25 06:50:52 -04:00
'x11/meta-x11-display.c',
'x11/meta-x11-display-private.h',
'x11/meta-x11-errors.c',
x11: Open a X11 Display directly Do the few remaining things that GDK is doing for us: - Open and close the X11 Display - Set up a GSource on the Display FD to handle events - Allocate and free the content of XGenericEventCookie, to "unroll" the few XInput2 events that Mutter still does handle. And remove the GdkDisplay we've so long relied on. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
2023-02-16 07:43:02 -05:00
'x11/meta-x11-event-source.c',
meson: Split x11 option into backend/xwayland Allow disabling either the xwayland or backend implementation of x11. Meson options were not added as this is more of a groundwork than the actual implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2354>
2022-03-25 06:50:52 -04:00
'x11/meta-x11-selection.c',
'x11/meta-x11-selection-private.h',
'x11/meta-x11-selection-input-stream.c',
'x11/meta-x11-selection-input-stream-private.h',
'x11/meta-x11-selection-output-stream.c',
'x11/meta-x11-selection-output-stream-private.h',
'x11/meta-x11-stack.c',
'x11/meta-x11-stack-private.h',
'x11/mutter-Xatomtype.h',
'x11/session.c',
'x11/session.h',
'x11/window-props.c',
'x11/window-props.h',
'x11/window-x11.c',
'x11/window-x11.h',
'x11/window-x11-private.h',
'x11/xprops.c',
'x11/xprops.h',
]
endif
Introduce MetaRenderDevice{Gbm,EglStream,Surfaceless} The purpose of MetaRenderDevice is to contain the logics related to a render device; i.e. e.g. a gbm_device, or an EGLDevice. It's meant to help abstract away unrelated details from where it's eventually used, which will be by MetaRendererNative and the MetaOnscreenNative instances. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
2021-05-03 13:23:52 -04:00
if have_egl_device
mutter_sources += [
'backends/native/meta-render-device-egl-stream.c',
'backends/native/meta-render-device-egl-stream.h',
]
endif
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
if have_egl
mutter_sources += [
'backends/meta-egl.c',
'backends/meta-egl-ext.h',
'backends/meta-egl.h',
]
endif
if have_gles2
mutter_sources += [
'backends/meta-gles3.c',
'backends/meta-gles3.h',
'backends/meta-gles3-table.h',
]
endif
if have_remote_desktop
mutter_sources += [
backends/eis: Add EIS client support This adds support for EIS clients in the form of MetaEis and MetaEisClient. The purpose is to allow clients to connect and send emulated input events using EIS. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
2021-08-16 19:09:59 -04:00
'backends/meta-eis.c',
'backends/meta-eis.h',
'backends/meta-eis-client.c',
'backends/meta-eis-client.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-remote-desktop.c',
'backends/meta-remote-desktop.h',
'backends/meta-remote-desktop-session.c',
'backends/meta-remote-desktop-session.h',
'backends/meta-screen-cast.c',
'backends/meta-screen-cast.h',
screen-cast: Add RecordArea for screen cast arbitrary area It takes coordinates in stage coordinate space, and will result in a screen cast stream consisting of that area, but scaled up by the scale factor of the view that overlaps with the area and has the highest scale factor. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
2020-03-04 15:42:52 -05:00
'backends/meta-screen-cast-area-stream.c',
'backends/meta-screen-cast-area-stream.h',
'backends/meta-screen-cast-area-stream-src.c',
'backends/meta-screen-cast-area-stream-src.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-screen-cast-monitor-stream.c',
'backends/meta-screen-cast-monitor-stream.h',
'backends/meta-screen-cast-monitor-stream-src.c',
'backends/meta-screen-cast-monitor-stream-src.h',
screen-cast/session: Introduce RecordVirtual D-Bus API The new RecordVirtual API creates a virtual monitor, i.e. a region of the stage that isn't backed by real monitor hardware. It's intended to be used by e.g. network screens on active sessions, virtual remote desktop screens when running headless, and scenarios like that. A major difference between the current Record* API's is that RecordVirtual relies on PipeWire itself to negotiate the refresh rate and size, as it can't rely on any existing monitor, for those details. This also means that the virtual monitor is not created until the stream negotiation has finished and a virtual monitor resolution has been determined. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-02-01 04:57:35 -05:00
'backends/meta-screen-cast-virtual-stream-src.c',
'backends/meta-screen-cast-virtual-stream-src.h',
'backends/meta-screen-cast-virtual-stream.c',
'backends/meta-screen-cast-virtual-stream.h',
screen-cast-session: Add screen-cast window mode Window mode will cast the content of a single window using the `MetaScreenCastWindow` interface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/306
2018-10-09 09:35:14 -04:00
'backends/meta-screen-cast-window-stream-src.c',
'backends/meta-screen-cast-window-stream-src.h',
'backends/meta-screen-cast-window-stream.c',
'backends/meta-screen-cast-window-stream.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/meta-screen-cast-session.c',
'backends/meta-screen-cast-session.h',
'backends/meta-screen-cast-stream.c',
'backends/meta-screen-cast-stream.h',
'backends/meta-screen-cast-stream-src.c',
'backends/meta-screen-cast-stream-src.h',
remote-desktop: Add dummy remote selection source It doesn't yet fetch data from the remote desktop session, but hooks up correctly. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1552>
2020-11-04 04:23:52 -05:00
'core/meta-selection-source-remote.c',
'core/meta-selection-source-remote.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
]
endif
if have_wayland
mutter_sources += [
'compositor/meta-surface-actor-wayland.c',
'compositor/meta-surface-actor-wayland.h',
build: Fix build when wayland is disabled https://gitlab.gnome.org/GNOME/mutter/merge_requests/817
2019-09-28 04:26:21 -04:00
'compositor/meta-window-actor-wayland.c',
'compositor/meta-window-actor-wayland.h',
Introduce the 'service channel' D-Bus service The service channel D-Bus interface aims to be a "back door" for services that needs special casing in Mutter, e.g. have custom private protocols only meant to be used by that particular service. There are currently no special casing implemented; only the basic service channel infrastructure is added. There is a single method on the interface, that is meant to eventually be used by xdg-desktop-portal-gnome to open a Wayland connection with a private protocol needed for the portal backend's rather special window management needs. The service channel Wayland client works by allowing one instance of each "type", where each time needs to be defined to work in parallel. If a new service client connects, the old one will be disconnected. MetaWaylandClient's are used to manage the service clients, and are assigned the service client type. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-01-27 15:49:56 -05:00
'core/meta-service-channel.c',
'core/meta-service-channel.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-cursor-sprite-wayland.c',
'wayland/meta-cursor-sprite-wayland.h',
'wayland/meta-pointer-confinement-wayland.c',
'wayland/meta-pointer-confinement-wayland.h',
'wayland/meta-pointer-lock-wayland.c',
'wayland/meta-pointer-lock-wayland.h',
wayland: Add wayland MetaSelectionSource implementation This object represents a Wayland selection owner. In order to invert the FD direction (we hand an output fd, but want an inpu fd), create an intermediate pipe so we can then create a GInputStream on top of it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
2018-11-19 11:34:18 -05:00
'wayland/meta-selection-source-wayland.c',
'wayland/meta-selection-source-wayland-private.h',
wayland: Implement the xdg-activation protocol This protocol implements the IPC necessary to focus application windows across launcher/launchee. Add support for it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1845>
2020-10-09 10:23:32 -04:00
'wayland/meta-wayland-activation.c',
'wayland/meta-wayland-activation.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-actor-surface.c',
'wayland/meta-wayland-actor-surface.h',
'wayland/meta-wayland-buffer.c',
'wayland/meta-wayland-buffer.h',
'wayland/meta-wayland.c',
wayland: Add API to launch trusted clients Allowing code from inside mutter to create a child process and delegate on it some of its tasks is something very useful. This can be done easily with the g_subprocess and g_subprocess_launcher classes already available in GLib and GObject. Unfortunately, although the child process can be a graphical program, currently it is not possible for the inner code to identify the windows created by the child in a secure manner (this is: being able to ensure that a malicious program won't be able to trick the inner code into thinking it is a child process launched by it). Under X11 this is not a problem because any program has full control over their windows, but under Wayland it is a different story: a program can't neither force their window to be kept at the top (like a docker program does) or at the bottom (like a program for desktop icons does), nor hide it from the list of windows. This means that it is not possible for a "classic", non-priviledged program, to fulfill these tasks, and it can be done only from code inside mutter (like a gnome-shell extension). This is a non desirable situation, because an extension runs in the same main loop than the whole desktop itself, which means that a complex extension can need to do too much work inside the main loop, and freeze the whole desktop for too much time. Also, it is important to note that javascript doesn't have access to fork(), or threads, which means that, at most, all the parallel computing that can do is those available in the _async calls in GLib/GObject. Also, having to create an extension for any priviledged graphical element is an stopper for a lot of programmers who already know GTK+ but doesn't know Clutter. This patch wants to offer a solution to this problem, by offering a new class that allows to launch a trusted child process from inside mutter, and make it to use an specific UNIX socket to communicate with the compositor. It also allows to check whether an specific MetaWindow was created by one of this trusted child processes or not. This allows to create extensions that launch a child process, and when that process creates a window, the extension can confirm in a secure way that the window really belongs to that process launched by it, so it can give to that window "superpowers" like being kept at the bottom of the desktop, not being listed in the list of windows or shown in the Activities panel... Also, in future versions, it could easily implement protocol extensions that only could be used by these trusted child processes. Several examples of the usefulness of this are that, with it, it is possible to write programs that implements: - desktop icons - a dock - a top or bottom bar ... all in a secure manner, avoiding insecure programs to do the same. In fact, even if the same code is launched manually, it won't have those privileges, only the specific process launched from inside mutter. Since this is only needed under Wayland, it won't work under X11. Fixes https://gitlab.gnome.org/GNOME/mutter/issues/741
2020-08-04 04:42:29 -04:00
'wayland/meta-wayland-client.c',
wayland/client: Add way to create indirectly launched clients This API creates a "client" then later sets up a wl_client and returns a file descriptor some Wayland client can connect to. It's meant to be used as a method other than WAYLAND_SOCKET and process launching, e.g. passing a file descriptor via a D-Bus API. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-01-26 16:52:40 -05:00
'wayland/meta-wayland-client-private.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-cursor-surface.c',
'wayland/meta-wayland-cursor-surface.h',
'wayland/meta-wayland-data-device.c',
'wayland/meta-wayland-data-device.h',
wayland: Add support for wayland-protocols primary selection protocol This protocol was added some time ago. Supporting it fell through the cracks. Add new data device/source/offer implementations for it, interoperation between primary selection protocols (and X11 primary selection for that matter) comes for free. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/943 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1255
2020-05-13 12:07:27 -04:00
'wayland/meta-wayland-data-device-primary.c',
'wayland/meta-wayland-data-device-primary.h',
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-09 10:22:21 -04:00
'wayland/meta-wayland-data-offer.c',
'wayland/meta-wayland-data-offer.h',
wayland: Add support for wayland-protocols primary selection protocol This protocol was added some time ago. Supporting it fell through the cracks. Add new data device/source/offer implementations for it, interoperation between primary selection protocols (and X11 primary selection for that matter) comes for free. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/943 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1255
2020-05-13 12:07:27 -04:00
'wayland/meta-wayland-data-offer-primary.c',
'wayland/meta-wayland-data-offer-primary.h',
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-09 08:05:51 -04:00
'wayland/meta-wayland-data-source.c',
'wayland/meta-wayland-data-source.h',
wayland: Add support for wayland-protocols primary selection protocol This protocol was added some time ago. Supporting it fell through the cracks. Add new data device/source/offer implementations for it, interoperation between primary selection protocols (and X11 primary selection for that matter) comes for free. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/943 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1255
2020-05-13 12:07:27 -04:00
'wayland/meta-wayland-data-source-primary.c',
'wayland/meta-wayland-data-source-primary.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-dma-buf.c',
'wayland/meta-wayland-dma-buf.h',
wayland: Move DND surface role into its own file This avoids a -Wredundand-decls warning about the get_type() function.
2019-01-20 11:34:50 -05:00
'wayland/meta-wayland-dnd-surface.c',
'wayland/meta-wayland-dnd-surface.h',
wayland: Add wl_global filter manager One can add a wl_global filter to a wl_display instance, which can be used to decide what clients should see what globals. This has so far been used to limit a Xwayland specific protocol extension to only Xwayland. In order to expand the logic about what globals are filtered to what clients, introduce a filter manager and port the Xwayland specific protocol filter to this new manager. Tests are added, using a new dummy protocol, to ensure that filtering is working as expected. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-01-27 09:16:14 -05:00
'wayland/meta-wayland-filter-manager.c',
'wayland/meta-wayland-filter-manager.h',
wayland: Implement fractional_scale_v1 protocol 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>
2022-04-29 09:54:53 -04:00
'wayland/meta-wayland-fractional-scale.c',
'wayland/meta-wayland-fractional-scale.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-gtk-shell.c',
'wayland/meta-wayland-gtk-shell.h',
'wayland/meta-wayland.h',
'wayland/meta-wayland-inhibit-shortcuts.c',
'wayland/meta-wayland-inhibit-shortcuts-dialog.c',
'wayland/meta-wayland-inhibit-shortcuts-dialog.h',
'wayland/meta-wayland-inhibit-shortcuts.h',
'wayland/meta-wayland-input-device.c',
'wayland/meta-wayland-input-device.h',
'wayland/meta-wayland-keyboard.c',
'wayland/meta-wayland-keyboard.h',
wayland/xdg-foreign: Add support for xdg-foreign-v2 This replaces the v1 implementation, which is now renamed to legacy-xdg-foreign. Both implementations use the same data structures internally, so that protocol version mismatches between the importer client and exporter client don't fail. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2770>
2020-02-06 02:00:56 -05:00
'wayland/meta-wayland-legacy-xdg-foreign.c',
'wayland/meta-wayland-legacy-xdg-foreign.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-outputs.c',
'wayland/meta-wayland-outputs.h',
'wayland/meta-wayland-pointer.c',
'wayland/meta-wayland-pointer-constraints.c',
'wayland/meta-wayland-pointer-constraints.h',
wayland/pointer-gestures: Implement hold gesture Update the pointer gestures protocol to version 3 and implement the new hold gesture. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1830>
2021-04-18 14:24:52 -04:00
'wayland/meta-wayland-pointer-gesture-hold.c',
'wayland/meta-wayland-pointer-gesture-hold.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-pointer-gesture-pinch.c',
'wayland/meta-wayland-pointer-gesture-pinch.h',
'wayland/meta-wayland-pointer-gestures.c',
'wayland/meta-wayland-pointer-gestures.h',
'wayland/meta-wayland-pointer-gesture-swipe.c',
'wayland/meta-wayland-pointer-gesture-swipe.h',
'wayland/meta-wayland-pointer.h',
'wayland/meta-wayland-popup.c',
'wayland/meta-wayland-popup.h',
wayland: Implement stub presentation-time The presentation-time protocol allows surfaces to get accurate timestamps of when their contents were shown on screen. This commit implements a stub version of the protocol which correctly discards all presentation feedback objects (as if the surface contents are never shown on screen). Subsequent commits will implement sending the presented events to surfaces shown on screen. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2020-10-07 05:02:41 -04:00
'wayland/meta-wayland-presentation-time.c',
'wayland/meta-wayland-presentation-time-private.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-private.h',
'wayland/meta-wayland-region.c',
'wayland/meta-wayland-region.h',
'wayland/meta-wayland-seat.c',
'wayland/meta-wayland-seat.h',
'wayland/meta-wayland-shell-surface.c',
'wayland/meta-wayland-shell-surface.h',
wayland: Add single pixel buffer support The "single pixel buffer" Wayland protocol extension provides a way for clients to create 1x1 buffers with a single color, specified by providing the color channels (red, green and blue) as well as the alpha channel as a 32 bit unsigned integer. For now, this is turned into a 1x1 texture. Future potential improvements is to hook things up to the scanout candidate logic and turn it into a scanout capable DMA buffer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
2022-01-19 05:49:32 -05:00
'wayland/meta-wayland-single-pixel-buffer.c',
'wayland/meta-wayland-single-pixel-buffer.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-subsurface.c',
'wayland/meta-wayland-subsurface.h',
'wayland/meta-wayland-surface.c',
'wayland/meta-wayland-surface.h',
'wayland/meta-wayland-tablet.c',
'wayland/meta-wayland-tablet-cursor-surface.c',
'wayland/meta-wayland-tablet-cursor-surface.h',
'wayland/meta-wayland-tablet.h',
'wayland/meta-wayland-tablet-manager.c',
'wayland/meta-wayland-tablet-manager.h',
'wayland/meta-wayland-tablet-pad.c',
'wayland/meta-wayland-tablet-pad-group.c',
'wayland/meta-wayland-tablet-pad-group.h',
'wayland/meta-wayland-tablet-pad.h',
'wayland/meta-wayland-tablet-pad-ring.c',
'wayland/meta-wayland-tablet-pad-ring.h',
'wayland/meta-wayland-tablet-pad-strip.c',
'wayland/meta-wayland-tablet-pad-strip.h',
'wayland/meta-wayland-tablet-seat.c',
'wayland/meta-wayland-tablet-seat.h',
'wayland/meta-wayland-tablet-tool.c',
'wayland/meta-wayland-tablet-tool.h',
'wayland/meta-wayland-text-input.c',
'wayland/meta-wayland-text-input.h',
'wayland/meta-wayland-touch.c',
'wayland/meta-wayland-touch.h',
wayland: Add transaction skeleton v2: * Use single hash table with struct which will contain all kinds of state handled by a transaction. v3: * Add meta_wayland_transaction_destroy. v4 (Georges Basile Stavracas Neto) * Fix struct _MetaWaylandTransaction(Entry) formatting. * Explicitly test against NULL. * Use gpointer insteadof void * for meta_wayland_transaction_entry_destroy. v5: (Robert Mader) * Use for loop in is_ancestor. * Include meta-wayland-transaction.h first in meta-wayland-transaction.c. v6: * Use g_autofree & g_clear_object. v7: (Jonas Ådahl) * Rename meta_wayland_transaction_entry_destroy to meta_wayland_transaction_entry_free. * Drop g_autofree use from meta_wayland_transaction_entry_free again. * Make meta_wayland_transaction_entry_free take a MetaWaylandTransactionEntry pointer. * Rename meta_wayland_transaction_destroy to meta_wayland_transaction_free. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
2022-06-10 11:23:08 -04:00
'wayland/meta-wayland-transaction.c',
'wayland/meta-wayland-transaction.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-types.h',
'wayland/meta-wayland-versions.h',
wayland/surface: Add support for wp_viewporter This adds the required bits to wayland surfaces and ties them up to the compositor parts. It is based on and very similar in nature to buffer transforms. From the specification: > The global interface exposing surface cropping and scaling > capabilities is used to instantiate an interface extension for a > wl_surface object. This extended interface will then allow cropping > and scaling the surface contents, effectively disconnecting the > direct relationship between the buffer and the surface size. https://gitlab.gnome.org/GNOME/mutter/merge_requests/323
2018-11-24 14:25:38 -05:00
'wayland/meta-wayland-viewporter.c',
'wayland/meta-wayland-viewporter.h',
wayland: Rework asynchronous window configuration This changes how asynchronous window configuration works. Prior to this commit, it worked by MetaWindowWayland remembering the last configuration it sent, then when the Wayland client got back to it, it tried to figure out whether it was a acknowledgment of the configuration or not, and finish the move. This failed if the client had acknowledged a configuration older than the last one sent, and it had hacks to somewhat deal with wl_shell's lack of configuration serial numbers. This commits scraps that and makes the MetaWindowWayland take ownership of sent configurations, including generating serial numbers. The wl_shell implementation is changed to emulate serial numbers (assuming each commit acknowledges the last sent configure event). Each configuration sent to the client is kept around until the client one. At this point, the position used for that particular configuration is used when applying the acknowledged state, meaning cases where we have already sent a new configuration when the client acknowledges a previous one, we'll still use the correct position for the window. https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
2019-07-05 12:10:14 -04:00
'wayland/meta-wayland-window-configuration.c',
'wayland/meta-wayland-window-configuration.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-xdg-foreign.c',
'wayland/meta-wayland-xdg-foreign.h',
wayland/xdg-foreign: Add support for xdg-foreign-v2 This replaces the v1 implementation, which is now renamed to legacy-xdg-foreign. Both implementations use the same data structures internally, so that protocol version mismatches between the importer client and exporter client don't fail. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2770>
2020-02-06 02:00:56 -05:00
'wayland/meta-wayland-xdg-foreign-private.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'wayland/meta-wayland-xdg-shell.c',
'wayland/meta-wayland-xdg-shell.h',
'wayland/meta-window-wayland.c',
'wayland/meta-window-wayland.h',
]
meson: Split x11 option into backend/xwayland Allow disabling either the xwayland or backend implementation of x11. Meson options were not added as this is more of a groundwork than the actual implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2354>
2022-03-25 06:50:52 -04:00
if have_xwayland
mutter_sources += [
wayland: Add X11 interop service client protocol This protocol is intended to let special clients create transient-for relationships between X11 and Wayland windows. The client that needs this is xdg-desktop-portal-gnome, which will create e.g. file chooser Wayland dialogs that should be mapped on top of X11 windows. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-02-01 11:55:41 -05:00
'wayland/meta-wayland-x11-interop.c',
'wayland/meta-wayland-x11-interop.h',
meson: Split x11 option into backend/xwayland Allow disabling either the xwayland or backend implementation of x11. Meson options were not added as this is more of a groundwork than the actual implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2354>
2022-03-25 06:50:52 -04:00
'wayland/meta-window-xwayland.c',
'wayland/meta-window-xwayland.h',
'wayland/meta-xwayland.c',
'wayland/meta-xwayland-grab-keyboard.c',
'wayland/meta-xwayland-grab-keyboard.h',
'wayland/meta-xwayland.h',
'wayland/meta-xwayland-private.h',
'wayland/meta-xwayland-dnd.c',
'wayland/meta-xwayland-dnd-private.h',
'wayland/meta-xwayland-surface.c',
'wayland/meta-xwayland-surface.h',
]
endif
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
endif
if have_native_backend
mutter_sources += [
'backends/native/dbus-utils.c',
'backends/native/dbus-utils.h',
'backends/native/meta-backend-native.c',
'backends/native/meta-backend-native.h',
'backends/native/meta-backend-native-private.h',
udev: Add helpers to list DRM devices Will be used to move out some udev related logic when adding GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-10 12:07:12 -05:00
'backends/native/meta-backend-native-types.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/native/meta-barrier-native.c',
'backends/native/meta-barrier-native.h',
'backends/native/meta-clutter-backend-native.c',
'backends/native/meta-clutter-backend-native.h',
'backends/native/meta-crtc-kms.c',
'backends/native/meta-crtc-kms.h',
crtc/kms: Add an abstract MetaCrtcNative that sits under MetaCrtcKms There is going to me another non-abstract MetaCrtcNative type, just as there will be for MetaOutputNative. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-14 05:15:53 -05:00
'backends/native/meta-crtc-native.c',
'backends/native/meta-crtc-native.h',
crtc-kms: Make KMS CRTC mode a type inheriting MetaCrtcMode It carries the drmModeModeInfo copy in it's instance struct, instead of the `driver_private` it was using before. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287 This version of the commit includes fixes from: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1305
2020-02-27 17:19:38 -05:00
'backends/native/meta-crtc-mode-kms.c',
'backends/native/meta-crtc-mode-kms.h',
Introduce virtual monitors Virtual monitors are monitors that isn't backed by any monitor like hardware. It would typically be backed by e.g. a remote desktop service, or a network display. It is currently only supported by the native backend, and whether the X11 backend will ever see virtual monitors is an open question. This rest of this commit message describes how it works under the native backend. Each virutal monitor consists of virtualized mode setting components: * A virtual CRTC mode (MetaCrtcModeVirtual) * A virtual CRTC (MetaCrtcVirtual) * A virtual connector (MetaOutputVirtual) In difference to the corresponding mode setting objects that represents KMS objects, the virtual ones isn't directly tied to a MetaGpu, other than the CoglFramebuffer being part of the GPU context of the primary GPU, which is the case for all monitors no matter what GPU they are connected to. Part of the reason for this is that a MetaGpu in practice represents a mode setting device, and its CRTCs and outputs, are all backed by real mode setting objects, while a virtual monitor is only backed by a framebuffer that is tied to the primary GPU. Maybe this will be reevaluated in the future, but since a virtual monitor is not tied to any GPU currently, so is the case for the virtual mode setting objects. The native rendering backend, including the cursor renderer, is adapted to handle the situation where a CRTC does not have a GPU associated with it; this in practice means that it e.g. will not try to upload HW cursor buffers when the cursor is only on a virtual monitor. The same applies to the native renderer, which is made to avoid creating MetaOnscreenNative for views that are backed by virtual CRTCs, as well as to avoid trying to mode set on such views. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-26 10:49:28 -05:00
'backends/native/meta-crtc-mode-virtual.c',
'backends/native/meta-crtc-mode-virtual.h',
'backends/native/meta-crtc-virtual.c',
'backends/native/meta-crtc-virtual.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/native/meta-cursor-renderer-native.c',
'backends/native/meta-cursor-renderer-native.h',
native: Add device pool for tracking device file descriptors This practically does the same thing as part of MetaLauncher, except with added thread safety and caching. For example, opening the same file a second time will return the same MetaDeviceFile, and only once all acquired MetaDeviceFile's are released, will the file descriptor be closed and control of the device released. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-03-31 12:28:19 -04:00
'backends/native/meta-device-pool-private.h',
'backends/native/meta-device-pool.c',
'backends/native/meta-device-pool.h',
drm-buffer: Make the "types" actual types There is no reason why we should have an internal type enum when we have all the infrastructure to just use multiple GObject types. Also there was no code sharing between the old "types", the only common API was getting the framebuffer ID, so lets make that a vfunc. https://gitlab.gnome.org/GNOME/mutter/merge_requests/584
2019-05-20 16:08:35 -04:00
'backends/native/meta-drm-buffer-dumb.c',
'backends/native/meta-drm-buffer-dumb.h',
'backends/native/meta-drm-buffer-gbm.c',
'backends/native/meta-drm-buffer-gbm.h',
renderer/native: Import primary buffer to 2nd GPU Where possible, try to export the buffer rendered by the primary GPU as a dmabuf and import it to the secondary GPU and turn it into a DRM FB for scanout. If this works, we get a zero-copy path to secondary GPU outputs. This is especially useful on virtual drivers like EVDI (used for DisplayLink devices) which are not picky at all about what kind of FBs they can handle. The zero-copy path is prioritised after the secondary GPU copy path, which should avoid regressions for existing working systems. Attempting zero-copy would have the risk of being less performant than doing the copy on the secondary GPU. This does not affect the DisplayLink use case, because there is no GPU in a DisplayLink device. The zero-copy path is prioritised before the primary GPU and CPU copy paths. It will be tried on the first frame of an output and the copy path is executed too. If zero-copy fails, the result from the copy path will take over on that frame. Furthermore, zero-copy will not be attemped again on that output. If zero-copy succeeds, the copy path is de-initialized. Zero-copy is assumed to be always preferable over the primary GPU and CPU copy paths. Whether this is universally true remains to be seen. This patch has one unhandled failure mode: if zero-copy path first succeeds and then fails later, there is no fallback and the output is left frozen or black. https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
2019-05-24 10:07:14 -04:00
'backends/native/meta-drm-buffer-import.c',
'backends/native/meta-drm-buffer-import.h',
native: Consolidate DRM buffer management to MetaDrmBuffer types This commit consolidates DRM buffer management to the MetaDrmBuffer types, where the base type handles the common functionality (such as managing the framebuffer id using drmModeAdd*/RMFb()), and the sub types their corresponding type specific behavior. This means that drmModeAdd*/RmFB() handling is moved from meta-gpu-kms.c to meta-drm-buffer.c; dumb buffer allocation/management from meta-renderer-native.c. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-29 03:40:53 -04:00
'backends/native/meta-drm-buffer-private.h',
kms-buffer: Rename to MetaDrmBuffer MetaKms* will be a dedicated namespace, which MetaKmsBuffer doesn't fit under. https://gitlab.gnome.org/GNOME/mutter/merge_requests/584
2019-05-20 15:20:17 -04:00
'backends/native/meta-drm-buffer.c',
'backends/native/meta-drm-buffer.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/native/meta-gpu-kms.c',
'backends/native/meta-gpu-kms.h',
renderer-view/native: Allocate backend specific ClutterFrame This will carry an on-demand created MetaKmsUpdate. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
2022-07-07 03:26:06 -04:00
'backends/native/meta-frame-native.c',
'backends/native/meta-frame-native.h',
clutter: Move evdev input to src/backends/native The end goal is to have all clutter backend code in src/backends. Input is the larger chunk of it, which is now part of our specific MutterClutterBackendNative, this extends to device manager, input devices, tools and keymap. This was supposed to be nice and incremental, but there's no sane way to cut this through. As a result of the refactor, a number of private Clutter functions are now exported for external backends to be possible. https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
2019-03-29 17:03:27 -04:00
'backends/native/meta-input-device-native.c',
'backends/native/meta-input-device-native.h',
'backends/native/meta-input-device-tool-native.c',
'backends/native/meta-input-device-tool-native.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/native/meta-input-settings-native.c',
'backends/native/meta-input-settings-native.h',
clutter: Move evdev input to src/backends/native The end goal is to have all clutter backend code in src/backends. Input is the larger chunk of it, which is now part of our specific MutterClutterBackendNative, this extends to device manager, input devices, tools and keymap. This was supposed to be nice and incremental, but there's no sane way to cut this through. As a result of the refactor, a number of private Clutter functions are now exported for external backends to be possible. https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
2019-03-29 17:03:27 -04:00
'backends/native/meta-keymap-native.c',
'backends/native/meta-keymap-native.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/native/meta-launcher.c',
'backends/native/meta-launcher.h',
native: Rename MetaMonitorManagerKms to MetaMonitorManagerNative We'll sooner or later start managing not only KMS backend monitors, but virtual / remote ones too. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2020-12-17 16:12:41 -05:00
'backends/native/meta-monitor-manager-native.c',
'backends/native/meta-monitor-manager-native.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/native/meta-output-kms.c',
'backends/native/meta-output-kms.h',
native: Add abstract MetaOutputNative object MetaOutputKms is made to inherit from this, but it doesn't do anything special yet. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2020-12-17 16:31:28 -05:00
'backends/native/meta-output-native.c',
'backends/native/meta-output-native.h',
Introduce virtual monitors Virtual monitors are monitors that isn't backed by any monitor like hardware. It would typically be backed by e.g. a remote desktop service, or a network display. It is currently only supported by the native backend, and whether the X11 backend will ever see virtual monitors is an open question. This rest of this commit message describes how it works under the native backend. Each virutal monitor consists of virtualized mode setting components: * A virtual CRTC mode (MetaCrtcModeVirtual) * A virtual CRTC (MetaCrtcVirtual) * A virtual connector (MetaOutputVirtual) In difference to the corresponding mode setting objects that represents KMS objects, the virtual ones isn't directly tied to a MetaGpu, other than the CoglFramebuffer being part of the GPU context of the primary GPU, which is the case for all monitors no matter what GPU they are connected to. Part of the reason for this is that a MetaGpu in practice represents a mode setting device, and its CRTCs and outputs, are all backed by real mode setting objects, while a virtual monitor is only backed by a framebuffer that is tied to the primary GPU. Maybe this will be reevaluated in the future, but since a virtual monitor is not tied to any GPU currently, so is the case for the virtual mode setting objects. The native rendering backend, including the cursor renderer, is adapted to handle the situation where a CRTC does not have a GPU associated with it; this in practice means that it e.g. will not try to upload HW cursor buffers when the cursor is only on a virtual monitor. The same applies to the native renderer, which is made to avoid creating MetaOnscreenNative for views that are backed by virtual CRTCs, as well as to avoid trying to mode set on such views. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-26 10:49:28 -05:00
'backends/native/meta-output-virtual.c',
'backends/native/meta-output-virtual.h',
kms: Add connector representation Represents drmModeConnector; both connected and disconnected. Currently only provides non-changing meta data. MetaOutputKms is changed to use MetaKmsConnector to get basic metadata, but variable metadata, those changing depending on what is connected (e.g. physical dimension, EDID, etc), are still manually retrieved by MetaOutputKms. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-03-08 10:23:15 -05:00
'backends/native/meta-kms-connector-private.h',
'backends/native/meta-kms-connector.c',
'backends/native/meta-kms-connector.h',
kms: Add CRTC representation Add MetaKmsCrtc to represent a CRTC on the associated device. Change MetaCrtcKms to use the ones discovered by the KMS abstraction. It still reads the resources handed over by MetaGpuKms, but eventually it will use only MetaKmsCrtc. MetaKmsCrtc is a type of object that is usable both from an impl task and from outside. All the API exposed via the non-private header is expected to be accessible from outside of the meta-kms namespace. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 12:33:00 -05:00
'backends/native/meta-kms-crtc-private.h',
'backends/native/meta-kms-crtc.c',
'backends/native/meta-kms-crtc.h',
Add KMS cursor manager This new manager object intends to take over management of the cursor plane from the native cursor renderer. It's API is intended to be used from the main thread, except for the _in_input() function, but mainly operates in the KMS context, i.e. the KMS thread. It makes use of an "update filter" that is called before each MetaKmsUpdate is turned into a atomic KMS commit or a set of legacy drmMode*() API calls. When the cursor position has been invalidated, it'll assign the cursor plane in the filter callback, using an as up to date as possible pointer position as the source for the cursor plane position. Cursor updates from the input thread schedules updates for the affected CRTCs which will cause the filter to be run, potentially for cursor-only commits. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-12-21 12:54:17 -05:00
'backends/native/meta-kms-cursor-manager.c',
'backends/native/meta-kms-cursor-manager.h',
crtc/kms: Outsource CRTC state fetching to MetaKmsCrtc Move reading state into a struct for MetaCrtcKms to use instead of querying KMS itself. The state is fetched in the impl context, but consists of only simple data types, so is made accessible publicly. As of this, MetaCrtcKms construction does not involve any manual KMS interaction outside of the MetaKms abstraction. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-03-08 13:19:18 -05:00
'backends/native/meta-kms-device-private.h',
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
'backends/native/meta-kms-device.c',
'backends/native/meta-kms-device.h',
kms: Add atomic MetaKmsImplDevice backend This adds a MetaKmsImplDevice backend using atomic drmMode* API in constrast to non-atomic legacy drmMode* API used in MetaKmsImplDeviceSimple. This has various behavioral differences worth noting, compared to the simple backend: * We can only commit once per CRTC per page flip. This means that we can only update the cursor plane once. If a primary plane composition missed a dead line, we cannot commit only a cursor update that would be presented earlier. * Partial success is not possible with the atomic backend. Cursor planes may fail with the simple backend. This is not the case with the atomic backend. This will instead later be handled using API specific to the atomic backend, that will effectively translate into TEST_ONLY commits. For testing and debugging purposes, the environment variable MUTTER_DEBUG_ENABLE_ATOMIC_KMS can be set to either 1 or 0 to force-enable or force-disable atomic mode setting. Setting it to some other value will cause mutter to abort(). Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/548 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-09 19:25:06 -04:00
'backends/native/meta-kms-impl-device-atomic.c',
'backends/native/meta-kms-impl-device-atomic.h',
kms: Add way to run without mode setting Currently our only entry point for DRM devices is MetaKms*, but in order to run without being DRM master, we cannot use /dev/dri/card*, nor can we be either of the existing MetaKmsImplDevice implementation (legacy KMS, and atomic KMS), as they both depend on being DRM master. Thus to handle running without being DRM master (i.e. headless), add a "dummy" MetaKmsImplDevice implementation, that doesn't do any mode setting at all, and that switches to operate on the render node, instead of the card node itself. This means we still use the same GBM code paths as the regular native backend paths, except we never make use of any CRTC backed onscreen framebuffers. Eventually, this "dummy" MetaKmsImplDevice will be replaced separating "KMS" device objects from "render" device objects, but that will require more significant changes. It will, however, be necessary for e.g. going from being headless, only having access to a render node, to turning into a real session, with a seat, being DRM master, and having access to a card node. This is currently not hooked up, but will be in a later commit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 08:54:45 -05:00
'backends/native/meta-kms-impl-device-dummy.c',
'backends/native/meta-kms-impl-device-dummy.h',
kms: Move impl backend inherit MetaKmsImplDevice instead of MetaKmsImpl This allows different types of backends to coexist, would e.g. one device support atomic but another not. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-17 03:38:11 -04:00
'backends/native/meta-kms-impl-device-simple.c',
'backends/native/meta-kms-impl-device-simple.h',
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
'backends/native/meta-kms-impl-device.c',
'backends/native/meta-kms-impl-device.h',
'backends/native/meta-kms-impl.c',
'backends/native/meta-kms-impl.h',
kms: Add MetaKmsMode abstraction This contains a copy of a drmModeModeInfo, describing a mode. It also has an unused pointer to the impl device it is associated with. It'll later be used to get a blob ID for the mode. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-06-04 11:12:34 -04:00
'backends/native/meta-kms-mode.c',
'backends/native/meta-kms-mode.h',
backend/native: Add and use transactional KMS API This commit introduces, and makes use of, a transactional API used for setting up KMS state, later to be applied, potentially atomically. From an API point of view, so is always the case, but in the current implementation, it still uses legacy drmMode* API to apply the state non-atomically. The API consists of various buliding blocks: * MetaKmsUpdate - a set of configuration changes, the higher level handle for handing over configuration to the impl backend. It's used to set mode, assign framebuffers to planes, queue page flips and set connector properties. * MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane. Currently used to map a framebuffer to the primary plane of a CRTC. In the legacy KMS implementation, the plane assignment is used to derive the framebuffer used for mode setting and page flipping. This also means various high level changes: State, excluding configuring the cursor plane and creating/destroying DRM framebuffer handles, are applied in the end of a clutter frame, in one go. From an API point of view, this is done atomically, but as mentioned, only the non-atomic implementation exists so far. From MetaRendererNative's point of view, a page flip now initially always succeeds; the handling of EBUSY errors are done asynchronously in the MetaKmsImpl backend (still by retrying at refresh rate, but postponing flip callbacks instead of manipulating the frame clock). Handling of falling back to mode setting instead of page flipping is notified after the fact by a more precise page flip feedback API. EGLStream based page flipping relies on the impl backend not being atomic, as the page flipping is done in the EGLStream backend (e.g. nvidia driver). It uses a 'custom' page flip queueing method, keeping the EGLStream logic inside meta-renderer-native.c. Page flip handling is moved to meta-kms-impl-device.c from meta-gpu-kms.c. It goes via an extra idle callback before reaching meta-renderer-native.c to make sure callbacks are invoked outside of the impl context. While dummy power save page flipping is kept in meta-renderer-native.c, the EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the frame clock, actual page flip callbacks are postponed until all EBUSY retries have either succeeded or failed due to some other error than EBUSY. This effectively inhibits new frames to be drawn, meaning we won't stall waiting on the file descriptor for pending page flips. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 16:36:41 -04:00
'backends/native/meta-kms-page-flip.c',
'backends/native/meta-kms-page-flip-private.h',
kms: Add plane representation A plane is one of three possible: primary, overlay and cursor. Each plane can have various properties, such as possible rotations, formats etc. Each plane can also be used with a set of CRTCs. A primary plane is the "backdrop" of a CRTC, i.e. the primary output for the composited frame that covers the whole CRTC. In general, mutter composites to a stage view frame onto a framebuffer that is then put on the primary plane. An overlay plane is a rectangular area that can be displayed on top of the primary plane. Eventually it will be used to place non-fullscreen surfaces, potentially avoiding stage redraws. A cursor plane is a plane placed on top of all the other planes, usually used to put the mouse cursor sprite. Initially, we only fetch the rotation properties, and we so far blacklist all rotations except ones that ends up with the same dimensions as with no rotations. This is because non-180° rotations doesn't work yet due to incorrect buffer modifiers. To make it possible to use non-180° rotations, changes necessary include among other things finding compatible modifiers using atomic modesetting. Until then, simply blacklist the ones we know doesn't work. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-31 12:48:19 -05:00
'backends/native/meta-kms-plane.c',
kms/plane: Move _new() function to private header Code outside of the MetaKms namespace is not expected to create plane objects, so move it to a private header. More things will be added to this header later. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-10-31 05:38:19 -04:00
'backends/native/meta-kms-plane-private.h',
kms: Add plane representation A plane is one of three possible: primary, overlay and cursor. Each plane can have various properties, such as possible rotations, formats etc. Each plane can also be used with a set of CRTCs. A primary plane is the "backdrop" of a CRTC, i.e. the primary output for the composited frame that covers the whole CRTC. In general, mutter composites to a stage view frame onto a framebuffer that is then put on the primary plane. An overlay plane is a rectangular area that can be displayed on top of the primary plane. Eventually it will be used to place non-fullscreen surfaces, potentially avoiding stage redraws. A cursor plane is a plane placed on top of all the other planes, usually used to put the mouse cursor sprite. Initially, we only fetch the rotation properties, and we so far blacklist all rotations except ones that ends up with the same dimensions as with no rotations. This is because non-180° rotations doesn't work yet due to incorrect buffer modifiers. To make it possible to use non-180° rotations, changes necessary include among other things finding compatible modifiers using atomic modesetting. Until then, simply blacklist the ones we know doesn't work. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-31 12:48:19 -05:00
'backends/native/meta-kms-plane.h',
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
'backends/native/meta-kms-private.h',
kms/result-listener: Let listeners own a feedback ref Dispatch results via a helper, and let each result hold a reference to the feedback. This allows for more asynchronous feedback management. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2023-02-14 14:15:51 -05:00
'backends/native/meta-kms-types-private.h',
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
'backends/native/meta-kms-types.h',
backend/native: Add and use transactional KMS API This commit introduces, and makes use of, a transactional API used for setting up KMS state, later to be applied, potentially atomically. From an API point of view, so is always the case, but in the current implementation, it still uses legacy drmMode* API to apply the state non-atomically. The API consists of various buliding blocks: * MetaKmsUpdate - a set of configuration changes, the higher level handle for handing over configuration to the impl backend. It's used to set mode, assign framebuffers to planes, queue page flips and set connector properties. * MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane. Currently used to map a framebuffer to the primary plane of a CRTC. In the legacy KMS implementation, the plane assignment is used to derive the framebuffer used for mode setting and page flipping. This also means various high level changes: State, excluding configuring the cursor plane and creating/destroying DRM framebuffer handles, are applied in the end of a clutter frame, in one go. From an API point of view, this is done atomically, but as mentioned, only the non-atomic implementation exists so far. From MetaRendererNative's point of view, a page flip now initially always succeeds; the handling of EBUSY errors are done asynchronously in the MetaKmsImpl backend (still by retrying at refresh rate, but postponing flip callbacks instead of manipulating the frame clock). Handling of falling back to mode setting instead of page flipping is notified after the fact by a more precise page flip feedback API. EGLStream based page flipping relies on the impl backend not being atomic, as the page flipping is done in the EGLStream backend (e.g. nvidia driver). It uses a 'custom' page flip queueing method, keeping the EGLStream logic inside meta-renderer-native.c. Page flip handling is moved to meta-kms-impl-device.c from meta-gpu-kms.c. It goes via an extra idle callback before reaching meta-renderer-native.c to make sure callbacks are invoked outside of the impl context. While dummy power save page flipping is kept in meta-renderer-native.c, the EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the frame clock, actual page flip callbacks are postponed until all EBUSY retries have either succeeded or failed due to some other error than EBUSY. This effectively inhibits new frames to be drawn, meaning we won't stall waiting on the file descriptor for pending page flips. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 16:36:41 -04:00
'backends/native/meta-kms-update-private.h',
'backends/native/meta-kms-update.c',
'backends/native/meta-kms-update.h',
backend/native: Move some KMS utilities to its own file They are not strictly related to any of the KMS objects, and should be reusable without adding a dependency on the non-meta-kms-* files in meta-kms-*. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-03-11 06:13:01 -04:00
'backends/native/meta-kms-utils.c',
'backends/native/meta-kms-utils.h',
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
'backends/native/meta-kms.c',
'backends/native/meta-kms.h',
renderer/native: Move out CoglOnscreen code to separate file To get meta-renderer-native.c down to a bit more managable size, and to isolate "onscreen" functionality from other (at least partly), move out the things related to CoglOnscreen to meta-onscreen-native.[ch]. A couple of structs are moved to a new shared header file, as abstracting those types (e.g. (primary, secondary) render devices) will be dealt with later. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
2020-10-17 17:08:28 -04:00
'backends/native/meta-onscreen-native.c',
'backends/native/meta-onscreen-native.h',
backends: Delegate pointer confinements to an impl object Split pointer confinements in 2 objects, one set from the upper layers containing its definition, and another managed by the backend that applies it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-07-08 12:17:13 -04:00
'backends/native/meta-pointer-constraint-native.c',
'backends/native/meta-pointer-constraint-native.h',
Introduce MetaRenderDevice{Gbm,EglStream,Surfaceless} The purpose of MetaRenderDevice is to contain the logics related to a render device; i.e. e.g. a gbm_device, or an EGLDevice. It's meant to help abstract away unrelated details from where it's eventually used, which will be by MetaRendererNative and the MetaOnscreenNative instances. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
2021-05-03 13:23:52 -04:00
'backends/native/meta-render-device-gbm.c',
'backends/native/meta-render-device-gbm.h',
'backends/native/meta-render-device-private.h',
'backends/native/meta-render-device-surfaceless.c',
'backends/native/meta-render-device-surfaceless.h',
'backends/native/meta-render-device.c',
'backends/native/meta-render-device.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/native/meta-renderer-native-gles3.c',
'backends/native/meta-renderer-native-gles3.h',
renderer/native: Move out CoglOnscreen code to separate file To get meta-renderer-native.c down to a bit more managable size, and to isolate "onscreen" functionality from other (at least partly), move out the things related to CoglOnscreen to meta-onscreen-native.[ch]. A couple of structs are moved to a new shared header file, as abstracting those types (e.g. (primary, secondary) render devices) will be dealt with later. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
2020-10-17 17:08:28 -04:00
'backends/native/meta-renderer-native-private.h',
'backends/native/meta-renderer-native.c',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/native/meta-renderer-native.h',
backends/native: Introduce MetaRendererViewNative MetaRendererViewNative is a MetaRendererView which contains logic specific to views of the native backend. It will be used by following commits. In the future, per-view logic from MetaRendererNative can be moved to MetaRendererViewNative where it makes more sense to have it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
2020-07-10 11:40:07 -04:00
'backends/native/meta-renderer-view-native.c',
'backends/native/meta-renderer-view-native.h',
backends/native: Spin MetaSeatImpl off MetaSeatNative Move most of the functional bits (those meant to run on a standalone thread) to a MetaSeatImpl object. This object is managed by the MetaSeatImpl and not exposed outside the friend MetaSeatNative/MetaInputDeviceNative/ MetaInputSettings classes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-07 09:13:51 -04:00
'backends/native/meta-seat-impl.c',
'backends/native/meta-seat-impl.h',
clutter: Move evdev input to src/backends/native The end goal is to have all clutter backend code in src/backends. Input is the larger chunk of it, which is now part of our specific MutterClutterBackendNative, this extends to device manager, input devices, tools and keymap. This was supposed to be nice and incremental, but there's no sane way to cut this through. As a result of the refactor, a number of private Clutter functions are now exported for external backends to be possible. https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
2019-03-29 17:03:27 -04:00
'backends/native/meta-seat-native.c',
'backends/native/meta-seat-native.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
'backends/native/meta-stage-native.c',
'backends/native/meta-stage-native.h',
kms: Split out impl/non-impl separation into MetaThread(Impl) It currently does exactly what MetaKms and MetaKmsImpl did regarding the context separation, which is to isolate what may eventually run on a KMS thread into a separate unit. It works somewhat like a "user thread", i.e. not a real thread, but will eventually learn how to spawn a "kernel thread", but provide the same API from the outside. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2020-11-22 11:56:04 -05:00
'backends/native/meta-thread-impl.c',
'backends/native/meta-thread-impl.h',
thread: Introduce kernel thread support This commit makes it possible to create a MetaThread where the MetaThreadImpl side runs in a real thread, instead of a artificially separated impl context. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2021-06-11 04:54:02 -04:00
'backends/native/meta-thread-private.h',
kms: Split out impl/non-impl separation into MetaThread(Impl) It currently does exactly what MetaKms and MetaKmsImpl did regarding the context separation, which is to isolate what may eventually run on a KMS thread into a separate unit. It works somewhat like a "user thread", i.e. not a real thread, but will eventually learn how to spawn a "kernel thread", but provide the same API from the outside. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2020-11-22 11:56:04 -05:00
'backends/native/meta-thread.c',
'backends/native/meta-thread.h',
'backends/native/meta-thread-private.h',
backends/native: Add udev abstraction layer To be used to signal devices added, hotplugs and other udev events. Currently the only event emitted is when a device is added. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-10 05:30:02 -05:00
'backends/native/meta-udev.c',
'backends/native/meta-udev.h',
clutter: Move evdev input to src/backends/native The end goal is to have all clutter backend code in src/backends. Input is the larger chunk of it, which is now part of our specific MutterClutterBackendNative, this extends to device manager, input devices, tools and keymap. This was supposed to be nice and incremental, but there's no sane way to cut this through. As a result of the refactor, a number of private Clutter functions are now exported for external backends to be possible. https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
2019-03-29 17:03:27 -04:00
'backends/native/meta-virtual-input-device-native.c',
'backends/native/meta-virtual-input-device-native.h',
Introduce virtual monitors Virtual monitors are monitors that isn't backed by any monitor like hardware. It would typically be backed by e.g. a remote desktop service, or a network display. It is currently only supported by the native backend, and whether the X11 backend will ever see virtual monitors is an open question. This rest of this commit message describes how it works under the native backend. Each virutal monitor consists of virtualized mode setting components: * A virtual CRTC mode (MetaCrtcModeVirtual) * A virtual CRTC (MetaCrtcVirtual) * A virtual connector (MetaOutputVirtual) In difference to the corresponding mode setting objects that represents KMS objects, the virtual ones isn't directly tied to a MetaGpu, other than the CoglFramebuffer being part of the GPU context of the primary GPU, which is the case for all monitors no matter what GPU they are connected to. Part of the reason for this is that a MetaGpu in practice represents a mode setting device, and its CRTCs and outputs, are all backed by real mode setting objects, while a virtual monitor is only backed by a framebuffer that is tied to the primary GPU. Maybe this will be reevaluated in the future, but since a virtual monitor is not tied to any GPU currently, so is the case for the virtual mode setting objects. The native rendering backend, including the cursor renderer, is adapted to handle the situation where a CRTC does not have a GPU associated with it; this in practice means that it e.g. will not try to upload HW cursor buffers when the cursor is only on a virtual monitor. The same applies to the native renderer, which is made to avoid creating MetaOnscreenNative for views that are backed by virtual CRTCs, as well as to avoid trying to mode set on such views. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-26 10:49:28 -05:00
'backends/native/meta-virtual-monitor-native.c',
'backends/native/meta-virtual-monitor-native.h',
clutter: Move evdev input to src/backends/native The end goal is to have all clutter backend code in src/backends. Input is the larger chunk of it, which is now part of our specific MutterClutterBackendNative, this extends to device manager, input devices, tools and keymap. This was supposed to be nice and incremental, but there's no sane way to cut this through. As a result of the refactor, a number of private Clutter functions are now exported for external backends to be possible. https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
2019-03-29 17:03:27 -04:00
'backends/native/meta-xkb-utils.c',
'backends/native/meta-xkb-utils.h',
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
2019-09-12 16:07:20 -04:00
'compositor/meta-compositor-native.c',
'compositor/meta-compositor-native.h',
compositor: Introduce MetaCompositorViewNative This class is meant to hold logic specific to the native backend in the context of a MetaCompositorView. Its addition requires making MetaCompositorView inheritable, and an addition of a virtual function which allows each compositor to create its own MetaCompositorView instance. In the case of the MetaCompositorNative, a MetaCompositorViewNative is created. In all other cases, a MetaCompositorView is created. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
2022-07-15 05:06:12 -04:00
'compositor/meta-compositor-view-native.c',
'compositor/meta-compositor-view-native.h',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
]
endif
backend/cogl-utils: Move, rename to cogl-drm-formats and clean up 1. Move into the new 'common' folder and build for Wayland as well so we will be able to share the code in follow-up commits. 2. Rename to cogl-drm-formats to make it more obvious that the format map is more than an utility these days. 3. Drop the unused CoglTextureComponents part (see also previous commit). 4. Move the map to the header, simplifying some future use-cases. 5. Sync formats with MetaWaylandBuffer and MetaWaylandDmaBufBuffer and also use newly introduced opaque formats where appropriate. This avoids duplicated code, ensures that new drm-formats added to the dmabuf protocol have an adequate representation in Cogl from which information like alpha support can be easily derived and finally ensures we don't crash if the mappings got out of sync. 6. Remove some likely untested formats. In case some of these are actually needed on certain hardware, we can test whether we got the correct mapping by also adding support for the corresponding wl_shm_format in MetaWaylandBuffer by extending the gradient test in https://gitlab.freedesktop.org/jadahl/wayland-test-clients Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
2023-06-09 02:03:53 -04:00
if have_wayland or have_native_backend
mutter_sources += [
'common/meta-cogl-drm-formats.c',
'common/meta-cogl-drm-formats.h',
]
endif
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
if have_wayland_eglstream
mutter_sources += [
'wayland/meta-wayland-egl-stream.c',
'wayland/meta-wayland-egl-stream.h',
]
endif
seat/impl: Make it possible to run without libinput Add a flag to MetaSeatNative and MetaSeatImpl that tells it not to attempt to create a libinput context. This is intended to be used when mutter is to run headless, as in without any input devices other than virtual ones. Currently not hooked up. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 05:47:59 -05:00
mutter_private_enum_sources = []
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
screen-cast: Add screen cast flag to streams Intended to be used to pass state from screen cast clients down the line. The first use case will be a boolean whether a screen cast is a plain recording or not, e.g. letting the Shell decide whether to use a red dot as the icon, or the generic "sharing" symbol. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1377
2020-04-21 10:54:54 -04:00
if have_remote_desktop
seat/impl: Make it possible to run without libinput Add a flag to MetaSeatNative and MetaSeatImpl that tells it not to attempt to create a libinput context. This is intended to be used when mutter is to run headless, as in without any input devices other than virtual ones. Currently not hooked up. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 05:47:59 -05:00
mutter_private_enum_sources += [
'backends/meta-screen-cast.h',
Port screen cast and remote desktop to MetaDbusSessionManager This eliminates some code duplication related to managing D-Bus session objects. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
2022-03-11 03:39:07 -05:00
'backends/meta-screen-cast-session.h',
seat/impl: Make it possible to run without libinput Add a flag to MetaSeatNative and MetaSeatImpl that tells it not to attempt to create a libinput context. This is intended to be used when mutter is to run headless, as in without any input devices other than virtual ones. Currently not hooked up. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 05:47:59 -05:00
]
endif
if have_native_backend
mutter_private_enum_sources += [
'backends/native/meta-backend-native-types.h',
drm-buffer: Replace 'use-modifier' boolean with flags This lets us add more customization to the buffer instance without adding more boolean arguments. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
2021-05-05 04:15:18 -04:00
'backends/native/meta-drm-buffer.h',
kms: Add way to run without mode setting Currently our only entry point for DRM devices is MetaKms*, but in order to run without being DRM master, we cannot use /dev/dri/card*, nor can we be either of the existing MetaKmsImplDevice implementation (legacy KMS, and atomic KMS), as they both depend on being DRM master. Thus to handle running without being DRM master (i.e. headless), add a "dummy" MetaKmsImplDevice implementation, that doesn't do any mode setting at all, and that switches to operate on the render node, instead of the card node itself. This means we still use the same GBM code paths as the regular native backend paths, except we never make use of any CRTC backed onscreen framebuffers. Eventually, this "dummy" MetaKmsImplDevice will be replaced separating "KMS" device objects from "render" device objects, but that will require more significant changes. It will, however, be necessary for e.g. going from being headless, only having access to a render node, to turning into a real session, with a seat, being DRM master, and having access to a card node. This is currently not hooked up, but will be in a later commit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 08:54:45 -05:00
'backends/native/meta-kms-types.h',
kms: Split out impl/non-impl separation into MetaThread(Impl) It currently does exactly what MetaKms and MetaKmsImpl did regarding the context separation, which is to isolate what may eventually run on a KMS thread into a separate unit. It works somewhat like a "user thread", i.e. not a real thread, but will eventually learn how to spawn a "kernel thread", but provide the same API from the outside. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2020-11-22 11:56:04 -05:00
'backends/native/meta-thread.h',
seat/impl: Make it possible to run without libinput Add a flag to MetaSeatNative and MetaSeatImpl that tells it not to attempt to create a libinput context. This is intended to be used when mutter is to run headless, as in without any input devices other than virtual ones. Currently not hooked up. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 05:47:59 -05:00
]
endif
mutter_built_sources = []
if mutter_private_enum_sources.length() > 0
screen-cast: Add screen cast flag to streams Intended to be used to pass state from screen cast clients down the line. The first use case will be a boolean whether a screen cast is a plain recording or not, e.g. letting the Shell decide whether to use a red dot as the icon, or the generic "sharing" symbol. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1377
2020-04-21 10:54:54 -04:00
mutter_private_enum_types = gnome.mkenums('meta-private-enum-types',
seat/impl: Make it possible to run without libinput Add a flag to MetaSeatNative and MetaSeatImpl that tells it not to attempt to create a libinput context. This is intended to be used when mutter is to run headless, as in without any input devices other than virtual ones. Currently not hooked up. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 05:47:59 -05:00
sources: mutter_private_enum_sources,
screen-cast: Add screen cast flag to streams Intended to be used to pass state from screen cast clients down the line. The first use case will be a boolean whether a screen cast is a plain recording or not, e.g. letting the Shell decide whether to use a red dot as the icon, or the generic "sharing" symbol. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1377
2020-04-21 10:54:54 -04:00
c_template: 'meta-private-enum-types.c.in',
h_template: 'meta-private-enum-types.h.in',
)
mutter_built_sources += mutter_private_enum_types
endif
build: Make D-Bus codegen declarative This makes it a bit less cumbersome to add more D-Bus codegen interfaces. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
2023-01-27 10:42:15 -05:00
dbus_interfaces = [
{
'name': 'meta-dbus-display-config',
'interface': 'org.gnome.Mutter.DisplayConfig.xml',
'prefix': 'org.gnome.Mutter.',
},
{
'name': 'meta-dbus-idle-monitor',
'interface': 'org.gnome.Mutter.IdleMonitor.xml',
'prefix': 'org.gnome.Mutter.',
'object_manager': true,
},
{
'name': 'meta-dbus-input-mapping',
'interface': 'org.gnome.Mutter.InputMapping.xml',
'prefix': 'org.gnome.Mutter.',
},
Introduce the 'service channel' D-Bus service The service channel D-Bus interface aims to be a "back door" for services that needs special casing in Mutter, e.g. have custom private protocols only meant to be used by that particular service. There are currently no special casing implemented; only the basic service channel infrastructure is added. There is a single method on the interface, that is meant to eventually be used by xdg-desktop-portal-gnome to open a Wayland connection with a private protocol needed for the portal backend's rather special window management needs. The service channel Wayland client works by allowing one instance of each "type", where each time needs to be defined to work in parallel. If a new service client connects, the old one will be disconnected. MetaWaylandClient's are used to manage the service clients, and are assigned the service client type. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-01-27 15:49:56 -05:00
{
'name': 'meta-dbus-service-channel',
'interface': 'org.gnome.Mutter.ServiceChannel.xml',
'prefix': 'org.gnome.Mutter.',
},
build: Make D-Bus codegen declarative This makes it a bit less cumbersome to add more D-Bus codegen interfaces. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
2023-01-27 10:42:15 -05:00
]
backends: Expose InputMapping D-Bus path to determine tablet mapping Currently, the peripheral "output" setting will be unset if Mutter is deciding automatically the mapped output of a tablet device. In that case, gnome-control-center will have a hard time figuring out itself the better output to show the tablet calibration UI, unless it's hand held by Mutter. Add this private D-Bus interface so that gnome-control-center can look up the output as determined by Mutter to bring the missing harmony between both. This interface consists of a simple method to get the mapped output for a input device node. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2605>
2022-09-01 07:51:40 -04:00
profile: Add a Sysprof-based profiler This exposes the /org/gnome/Sysprof3/Profiler object inside Mutter to allow initiating a Sysprof capture. https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
2018-08-10 16:42:12 -04:00
if have_profiler
mutter_sources += [
Move MetaProfiler from the backend to core It's not really a backend thing, and we'll want to profile e.g. loading the backend too, so create it very early and destroy it very late and let MetaContextMain own it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2678>
2022-10-12 16:30:07 -04:00
'core/meta-profiler.c',
'core/meta-profiler.h',
profile: Add a Sysprof-based profiler This exposes the /org/gnome/Sysprof3/Profiler object inside Mutter to allow initiating a Sysprof capture. https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
2018-08-10 16:42:12 -04:00
]
build: Make D-Bus codegen declarative This makes it a bit less cumbersome to add more D-Bus codegen interfaces. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
2023-01-27 10:42:15 -05:00
dbus_interfaces += [
{
'name': 'meta-dbus-sysprof3-profiler',
'interface': 'org.gnome.Sysprof3.Profiler.xml',
'prefix': 'org.gnome.',
'directory': sysprof_dbus_interfaces_dir,
},
]
profile: Add a Sysprof-based profiler This exposes the /org/gnome/Sysprof3/Profiler object inside Mutter to allow initiating a Sysprof capture. https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
2018-08-10 16:42:12 -04:00
endif
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
if have_native_backend
build: check for cvt only when building the native backend Also error out properly when cvt is not found on Autotools.
2018-11-10 03:25:57 -05:00
cvt = find_program('cvt')
gen_default_modes = find_program('backends/native/gen-default-modes.py')
default_modes_h = custom_target('meta-default-modes',
output: 'meta-default-modes.h',
command: [gen_default_modes, '@OUTPUT@']
)
mutter_built_sources += default_modes_h
build: Make D-Bus codegen declarative This makes it a bit less cumbersome to add more D-Bus codegen interfaces. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
2023-01-27 10:42:15 -05:00
dbus_interfaces += [
{
'name': 'meta-dbus-login1',
'interface': 'org.freedesktop.login1.xml',
'prefix': 'org.freedesktop.',
},
]
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
endif
if have_remote_desktop
build: Make D-Bus codegen declarative This makes it a bit less cumbersome to add more D-Bus codegen interfaces. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
2023-01-27 10:42:15 -05:00
dbus_interfaces += [
{
'name': 'meta-dbus-remote-desktop',
'interface': 'org.gnome.Mutter.RemoteDesktop.xml',
'prefix': 'org.gnome.Mutter.',
},
{
'name': 'meta-dbus-screen-cast',
'interface': 'org.gnome.Mutter.ScreenCast.xml',
'prefix': 'org.gnome.Mutter.',
},
]
endif
backends/native: Use rtkit to get realtime priority Instead of using sched_setscheduler directly (and relying that we somehow got CAP_SYS_NICE), use rtkit to do this for us. Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2284 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2060>
2021-10-21 07:40:55 -04:00
build: Make D-Bus codegen declarative This makes it a bit less cumbersome to add more D-Bus codegen interfaces. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
2023-01-27 10:42:15 -05:00
dbus_interfaces += [
{
'name': 'meta-dbus-rtkit1',
'interface': 'org.freedesktop.RealtimeKit1.xml',
'prefix': 'org.freedesktop.',
},
{
'name': 'meta-dbus-gsd-color',
'interface': 'org.gnome.SettingsDaemon.Color.xml',
'prefix': 'org.gnome.',
},
{
'name': 'meta-dbus-gsd-power-screen',
'interface': 'org.gnome.SettingsDaemon.Power.Screen.xml',
'prefix': 'org.gnome.',
},
]
built_dbus_sources = {}
foreach dbus_interface: dbus_interfaces
name = dbus_interface['name']
color-manager: Set up a D-Bus proxy to org.gnome.SettingsDaemon.Color gsd-color provides this API, which exposes details about the night light state. Currently, gsd-color also turns this state into CRTC gamma changes, but this will eventually change, and this is a preparation for this. The proxy isn't yet used for anything. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
2021-10-29 05:23:18 -04:00
build: Make D-Bus codegen declarative This makes it a bit less cumbersome to add more D-Bus codegen interfaces. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
2023-01-27 10:42:15 -05:00
interface = dbus_interface['interface']
if dbus_interface.has_key('directory')
directory = dbus_interface['directory']
else
directory = dbus_interfaces_dir
endif
build: Use / operator instead of join_paths everywhere Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2985>
2023-05-04 07:49:59 -04:00
interface_file = directory / interface
build: Make D-Bus codegen declarative This makes it a bit less cumbersome to add more D-Bus codegen interfaces. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
2023-01-27 10:42:15 -05:00
prefix = dbus_interface['prefix']
if dbus_interface.has_key('object_manager')
object_manager = dbus_interface['object_manager']
else
object_manager = false
endif
dbus_sources = gnome.gdbus_codegen(name, interface_file,
interface_prefix: prefix,
Use the same prefix for all generated D-Bus boiler plate A somewhat painful rename, but it'll open up for simplifying the build script a bit, while at the same time bringing consistency to chaos. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
2023-01-27 10:23:14 -05:00
namespace: 'MetaDBus',
build: Make D-Bus codegen declarative This makes it a bit less cumbersome to add more D-Bus codegen interfaces. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
2023-01-27 10:42:15 -05:00
object_manager: object_manager,
)
built_dbus_sources += {
name: dbus_sources,
}
mutter_built_sources += dbus_sources
endforeach
color-manager: Add API to set brightness It uses the org.gnome.SettingsDaemon.Power.Screen D-Bus API. Currently brightness set if the proxy is not ready are ignored; whether the brightness value should be cached and set once it appears or whether color profiles should be reapplied is yet to be decided. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
2021-12-03 18:26:01 -05:00
Add beginning of input capture API This API aims to provide a way for users to capture input devices under certain conditions, for example when a pointer crosses a specified barrier. So far only part of the API is implemented, specifially the session management as well as zone advertisement, where a zone refers to a region in the compositor which edges will eventually be made available for barrier placement. So far the remote access handle is created while the session is enable, despite the input capturing isn't actually active yet. This will change in the future once it can actually become active. v2: Remove absolute/relative pointer, keep only pointer (ofourdan) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
2022-03-30 11:27:51 -04:00
dbus_input_capture_built_sources = gnome.gdbus_codegen('meta-dbus-input-capture',
dbus_interfaces_dir / 'org.gnome.Mutter.InputCapture.xml',
interface_prefix: 'org.gnome.Mutter',
namespace: 'MetaDBus',
)
mutter_built_sources += dbus_input_capture_built_sources
tests/wayland: Test subsurface commits after parent was reset Without 'wayland/surface-actor: Reset and sync subsurface state when resetting' this test would fail. This also adds a simple framework for testing lower level Wayland semantics. In contrast to the test-client and test-driver framework, which uses gtk and tests mostly window management related things, this framework is aimed to run Wayland clients made to test a particular protocol flow, thus will likely consist of manual lower level Wayland mechanics. A private protocol is added in order to help out clients do things they cannot do by themself. The protocol currently only consists of a request meant to be used for getting a callback when the actor of a given surface is eventually destroyed. This is different from the wl_surface being destroyed due to window destroy animations taking an arbitrary amount of time. It'll be used by the first test added in the next commit. https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
2019-12-06 13:05:32 -05:00
wayland_protocol_server_headers = []
wayland_protocol_client_headers = []
wayland_protocol_sources = []
build: Store generated Wayland protocol files in table This makes it possible for e.g. test cases to pick protocol extensions to include. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-02-01 11:49:08 -05:00
wayland_protocol_files = {}
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
if have_wayland
# Format:
# - protocol name
# - protocol stability ('private', 'stable' or 'unstable')
# - protocol version (if stability is 'unstable')
wayland_protocols = [
wayland: Implement fractional_scale_v1 protocol 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>
2022-04-29 09:54:53 -04:00
['fractional-scale', 'staging', 'v1', ],
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
['gtk-shell', 'private', ],
['keyboard-shortcuts-inhibit', 'unstable', 'v1', ],
['linux-dmabuf', 'unstable', 'v1', ],
['pointer-constraints', 'unstable', 'v1', ],
['pointer-gestures', 'unstable', 'v1', ],
Generate presentation-time files Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
2020-10-06 13:30:13 -04:00
['presentation-time', 'stable', ],
build: Build scaffolding for primary-selection wayland protocol https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1255
2020-05-13 12:06:10 -04:00
['primary-selection', 'unstable', 'v1', ],
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
['relative-pointer', 'unstable', 'v1', ],
wayland: Add single pixel buffer support The "single pixel buffer" Wayland protocol extension provides a way for clients to create 1x1 buffers with a single color, specified by providing the color channels (red, green and blue) as well as the alpha channel as a 32 bit unsigned integer. For now, this is turned into a 1x1 texture. Future potential improvements is to hook things up to the scanout candidate logic and turn it into a scanout capable DMA buffer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
2022-01-19 05:49:32 -05:00
['single-pixel-buffer', 'staging', 'v1', ],
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
['tablet', 'unstable', 'v2', ],
['text-input', 'unstable', 'v3', ],
wayland/surface: Add support for wp_viewporter This adds the required bits to wayland surfaces and ties them up to the compositor parts. It is based on and very similar in nature to buffer transforms. From the specification: > The global interface exposing surface cropping and scaling > capabilities is used to instantiate an interface extension for a > wl_surface object. This extended interface will then allow cropping > and scaling the surface contents, effectively disconnecting the > direct relationship between the buffer and the surface size. https://gitlab.gnome.org/GNOME/mutter/merge_requests/323
2018-11-24 14:25:38 -05:00
['viewporter', 'stable', ],
build: Add xdg-activation to build Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1845>
2021-04-23 17:22:47 -04:00
['xdg-activation', 'staging', 'v1', ],
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
['xdg-foreign', 'unstable', 'v1', ],
wayland/xdg-foreign: Add support for xdg-foreign-v2 This replaces the v1 implementation, which is now renamed to legacy-xdg-foreign. Both implementations use the same data structures internally, so that protocol version mismatches between the importer client and exporter client don't fail. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2770>
2020-02-06 02:00:56 -05:00
['xdg-foreign', 'unstable', 'v2', ],
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
['xdg-output', 'unstable', 'v1', ],
['xdg-shell', 'stable', ],
['xwayland-keyboard-grab', 'unstable', 'v1', ],
]
if have_wayland_eglstream
build: Replace deprecated meson functions The `dep.get_<type>_variable()` methods have been deprecated in favor of the generic `dep.get_variable()` method. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2702>
2022-11-18 20:16:04 -05:00
wayland_eglstream_protocols_dir = wayland_eglstream_protocols_dep.get_variable('pkgdatadir')
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
wayland_protocols += [
['wayland-eglstream-controller', 'third-party', wayland_eglstream_protocols_dir],
]
endif
wayland: Add X11 interop service client protocol This protocol is intended to let special clients create transient-for relationships between X11 and Wayland windows. The client that needs this is xdg-desktop-portal-gnome, which will create e.g. file chooser Wayland dialogs that should be mapped on top of X11 windows. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-02-01 11:55:41 -05:00
if have_xwayland
wayland_protocols += [
['mutter-x11-interop', 'private', ],
]
endif
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
wayland_scanner = find_program('wayland-scanner')
build: Replace deprecated meson functions The `dep.get_<type>_variable()` methods have been deprecated in favor of the generic `dep.get_variable()` method. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2702>
2022-11-18 20:16:04 -05:00
protocols_dir = wayland_protocols_dep.get_variable('pkgdatadir')
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
assert(protocols_dir != '', 'Could not get pkgdatadir from wayland-protocols.pc')
foreach p: wayland_protocols
protocol_name = p.get(0)
protocol_type = p.get(1)
if protocol_type == 'stable'
output_base = protocol_name
build: Use / operator instead of format for Wayland protocol paths Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2985>
2023-05-04 07:55:11 -04:00
input = protocols_dir / protocol_type / protocol_name / '@0@.xml'.format(output_base)
build: Add support for "staging" wayland protocols These come in a different folder, with no stable/unstable nomenclature. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1845>
2021-04-23 17:22:05 -04:00
elif protocol_type == 'staging'
protocol_version = p.get(2)
output_base = '@0@-@1@'.format(protocol_name, protocol_version)
build: Use / operator instead of format for Wayland protocol paths Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2985>
2023-05-04 07:55:11 -04:00
input = protocols_dir / protocol_type / protocol_name / '@0@.xml'.format(output_base)
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
elif protocol_type == 'private'
output_base = protocol_name
input = 'wayland/protocol/@0@.xml'.format(protocol_name)
elif protocol_type == 'third-party'
output_base = protocol_name
protocol_dir = p.get(2)
build: Use / operator instead of join_paths everywhere Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2985>
2023-05-04 07:49:59 -04:00
input = protocol_dir / '@0@.xml'.format(protocol_name)
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
else
protocol_version = p.get(2)
output_base = '@0@-@1@-@2@'.format(protocol_name,
protocol_type,
protocol_version)
build: Use / operator instead of format for Wayland protocol paths Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2985>
2023-05-04 07:55:11 -04:00
input = protocols_dir / protocol_type / protocol_name / '@0@.xml'.format(output_base)
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
endif
build: Store generated Wayland protocol files in table This makes it possible for e.g. test cases to pick protocol extensions to include. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-02-01 11:49:08 -05:00
server_header = custom_target('@0@ server header'.format(output_base),
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
input: input,
output: '@0@-server-protocol.h'.format(output_base),
command: [
wayland_scanner,
'server-header',
'@INPUT@', '@OUTPUT@',
]
)
build: Store generated Wayland protocol files in table This makes it possible for e.g. test cases to pick protocol extensions to include. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-02-01 11:49:08 -05:00
client_header = custom_target('@0@ client header'.format(output_base),
tests/wayland: Test subsurface commits after parent was reset Without 'wayland/surface-actor: Reset and sync subsurface state when resetting' this test would fail. This also adds a simple framework for testing lower level Wayland semantics. In contrast to the test-client and test-driver framework, which uses gtk and tests mostly window management related things, this framework is aimed to run Wayland clients made to test a particular protocol flow, thus will likely consist of manual lower level Wayland mechanics. A private protocol is added in order to help out clients do things they cannot do by themself. The protocol currently only consists of a request meant to be used for getting a callback when the actor of a given surface is eventually destroyed. This is different from the wl_surface being destroyed due to window destroy animations taking an arbitrary amount of time. It'll be used by the first test added in the next commit. https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
2019-12-06 13:05:32 -05:00
input: input,
output: '@0@-client-protocol.h'.format(output_base),
command: [
wayland_scanner,
'client-header',
'@INPUT@', '@OUTPUT@',
]
)
build: Store generated Wayland protocol files in table This makes it possible for e.g. test cases to pick protocol extensions to include. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-02-01 11:49:08 -05:00
protocol_code = custom_target('@0@ source'.format(output_base),
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
input: input,
output: '@0@-protocol.c'.format(output_base),
command: [
wayland_scanner,
'private-code',
'@INPUT@', '@OUTPUT@',
]
)
build: Store generated Wayland protocol files in table This makes it possible for e.g. test cases to pick protocol extensions to include. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
2023-02-01 11:49:08 -05:00
wayland_protocol_files += {
protocol_name: {
'server-header': server_header,
'client-header': client_header,
'protocol-code': protocol_code,
},
}
wayland_protocol_server_headers += server_header
wayland_protocol_client_headers += client_header
wayland_protocol_sources += protocol_code
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
endforeach
endif
tests/wayland: Test subsurface commits after parent was reset Without 'wayland/surface-actor: Reset and sync subsurface state when resetting' this test would fail. This also adds a simple framework for testing lower level Wayland semantics. In contrast to the test-client and test-driver framework, which uses gtk and tests mostly window management related things, this framework is aimed to run Wayland clients made to test a particular protocol flow, thus will likely consist of manual lower level Wayland mechanics. A private protocol is added in order to help out clients do things they cannot do by themself. The protocol currently only consists of a request meant to be used for getting a callback when the actor of a given surface is eventually destroyed. This is different from the wl_surface being destroyed due to window destroy animations taking an arbitrary amount of time. It'll be used by the first test added in the next commit. https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
2019-12-06 13:05:32 -05:00
mutter_built_sources += wayland_protocol_server_headers
mutter_built_sources += wayland_protocol_sources
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
subdir('meta')
mutter_built_sources += mutter_enum_types
build: Set built headers as libmutter_dep sources This should help avoiding compiling objects depending on built headers to fail if they happen to be built before the sources are built. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3000>
2023-05-11 14:23:18 -04:00
mutter_built_headers = []
foreach built_source : mutter_built_sources
if built_source.full_path().endswith('.h')
build: Use correct variable for gathering built headers We added things unused variable, which is a bit useless. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3131>
2023-07-20 05:35:00 -04:00
mutter_built_headers += [built_source]
build: Set built headers as libmutter_dep sources This should help avoiding compiling objects depending on built headers to fail if they happen to be built before the sources are built. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3000>
2023-05-11 14:23:18 -04:00
endif
endforeach
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
libmutter = shared_library(libmutter_name,
build: Build libmutter using sources as positional arguments The "sources" keyword argument does not seem documented at https://mesonbuild.com/Reference-manual.html#shared_library or the related objects. It may work, but let's use meson as intended. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1458
2020-09-29 19:19:11 -04:00
mutter_sources,
mutter_built_sources,
meson: Set proper soversion and version to libraries Soname of the libraries should be the major version number, while the version triplet is currently used: objdump -p libmutter-4.so.0.0.0 | grep SONAME SONAME libmutter-4.so.0.0.0 While is expected to be only libmutter-4.so.0 Fix all shared libraries by setting valid version and soversion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
2019-01-17 17:21:37 -05:00
version: '0.0.0',
soversion: 0,
meta: Hide libmutter symbols by default and selectively export them Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT and META_EXPORT_TEST defines to mark a symbols as visible. The TEST version is meant to be used to flag symbols that are only used internally by mutter tests, but that should not be considered public API. This allows us to be more precise in selecting what is exported and what is not, without the need of a version-script file that would be more complicated to maintain. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-22 21:25:35 -05:00
gnu_symbol_visibility: 'hidden',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
include_directories: mutter_includes,
build: Make each executable/library have their own log domain 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>
2022-04-28 10:09:11 -04:00
c_args: [
mutter_c_args,
'-DG_LOG_DOMAIN="libmutter"',
],
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
dependencies: [
libmutter_cogl_dep,
libmutter_clutter_dep,
mutter_deps,
],
install_rpath: pkglibdir,
install_dir: libdir,
install: true,
)
libmutter_dep = declare_dependency(
link_with: libmutter,
include_directories: mutter_includes,
build: Set built headers as libmutter_dep sources This should help avoiding compiling objects depending on built headers to fail if they happen to be built before the sources are built. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3000>
2023-05-11 14:23:18 -04:00
sources: mutter_built_headers,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
dependencies: [
libmutter_cogl_dep,
libmutter_clutter_dep,
mutter_deps,
],
)
tests: Add basic X11 WM test This launches Xvfb, using xvfb-run, and inside tests the following: 1. Launching 'mutter --x11' works 2. Launching a couple of X11 clients works (doesn't crash or result in warnings) 3. Launching 'mutter --x11 --replace' works 4. Terminating works It does this using a simple shell script. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2434>
2022-05-27 11:12:46 -04:00
mutter = executable('mutter',
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
sources: [
files('core/mutter.c'),
],
include_directories: mutter_includes,
build: Make each executable/library have their own log domain 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>
2022-04-28 10:09:11 -04:00
c_args: [
mutter_c_args,
'-DG_LOG_DOMAIN="mutter"',
],
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
dependencies: [libmutter_dep],
install_dir: bindir,
install: true,
)
meson: Split x11 option into backend/xwayland Allow disabling either the xwayland or backend implementation of x11. Meson options were not added as this is more of a groundwork than the actual implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2354>
2022-03-25 06:50:52 -04:00
if have_x11
executable('mutter-restart-helper',
sources: [
files('core/restart-helper.c'),
],
include_directories: [
top_includepath,
],
c_args: [
mutter_c_args,
'-DG_LOG_DOMAIN="mutter-restart-helper"',
],
dependencies: [
x11_dep,
xcomposite_dep,
],
install_dir: libexecdir,
install: true,
)
endif
build: Also build mutter-restart-helper executable Was left out by mistake. Lets add it.
2018-11-07 06:28:57 -05:00
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
if have_introspection
mutter_introspected_sources = []
foreach source : mutter_sources
if source.endswith('.c')
mutter_introspected_sources += source
endif
endforeach
libmutter_gir = gnome.generate_gir(libmutter,
sources: [
mutter_enum_types[1],
mutter_introspected_sources,
mutter_public_header_files
],
nsversion: libmutter_api_version,
namespace: 'Meta',
symbol_prefix: 'meta',
includes: [
'GObject-2.0',
'GDesktopEnums-3.0',
'xlib-2.0',
'xfixes-4.0',
libmutter_cogl_gir[0],
libmutter_cogl_pango_gir[0],
libmutter_clutter_gir[0],
],
build: Prefer dependencies instead of link_with Meson uses the 'dependencies' field to determine and parallelize build steps, but that isn't entirely true with 'link_with'; this might cause a race condition when generating header files while trying to build them. Fix that by only using 'dependencies' instead of 'link_with'.
2018-11-06 14:50:24 -05:00
dependencies: [
libmutter_dep,
build: Make dependency order consistent when generating introspection Add first the internal/local dependencies, then the external dependencies. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2826>
2023-02-05 04:53:14 -05:00
mutter_deps,
build: Prefer dependencies instead of link_with Meson uses the 'dependencies' field to determine and parallelize build steps, but that isn't entirely true with 'link_with'; this might cause a race condition when generating header files while trying to build them. Fix that by only using 'dependencies' instead of 'link_with'.
2018-11-06 14:50:24 -05:00
],
build: Always pass --quiet to g-ir-scanner This makes the build less verbose, as all .gir generation except for clutters didn't pass --quiet to g-ir-scanner, making it output long linking commands. Do this by adding a common introspection_args variable. While at it, put -U_GNU_SOURCE in there too, as it was always passed everywhere as without it the scanner would log warnings.
2018-12-22 05:28:46 -05:00
extra_args: mutter_c_args + introspection_args,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
install_dir_gir: pkglibdir,
install_dir_typelib: pkglibdir,
install: true
)
endif
build: Pass library as first argument to pkg.generate() Dependencies are added automatically, and we no longer get warnings like: clutter/clutter/meson.build:628: DEPRECATION: Library mutter-clutter-4 was passed to the "libraries" keyword argument of a previous call to generate() method instead of first positional argument. Adding mutter-clutter-4 to "Requires" field, but this is a deprecated behaviour that will change in a future version of Meson. Please report the issue if this warning cannot be avoided in your case.
2019-01-08 03:05:08 -05:00
pkg.generate(libmutter,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
name: 'Meta',
filebase: 'libmutter-' + libmutter_api_version,
description: 'Mutter compositor and window manager library',
subdirs: pkgname,
requires: [mutter_pkg_deps, libmutter_clutter_name],
version: meson.project_version(),
variables: [
'apiversion=' + libmutter_api_version,
'girdir=${libdir}/mutter-' + libmutter_api_version,
'typelibdir=${libdir}/mutter-' + libmutter_api_version,
],
build: Install .pc files in correct location If a library is provided in the positional arguments, then meson defaults to installing the .pc file in a 'pkgconfig' subdirectory in the library's install location. We want the files in the regular $libdir/pkgconfig rather than $libdir/mutter-$api/pkgconfig, so specify the location explicitly in the parameters. https://gitlab.gnome.org/GNOME/mutter/merge_requests/382
2019-01-08 16:28:18 -05:00
install_dir: pcdir,
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
)
subdir('compositor/plugins')
build: Make GTK dependency specific to X11 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
2022-05-26 09:05:02 -04:00
if have_x11_client
subdir('frames')
endif
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
meson: Add option flags to control test suites building Now the `tests` meson option controls weather we should build all the test suites while `core_tests` controls mutter tests. https://gitlab.gnome.org/GNOME/mutter/merge_requests/442
2019-02-13 12:51:21 -05:00
if have_core_tests
Add meson build support This commit adds meson build support to mutter. It takes a step away from the three separate code bases with three different autotools setups into a single meson build system. There are still places that can be unified better, for example by removing various "config.h" style files from cogl and clutter, centralizing debug C flags and other configurable macros, and similar artifacts that are there only because they were once separate code bases. There are some differences between the autotools setup and the new meson. Here are a few: The meson setup doesn't generate wrapper scripts for various cogl and clutter test cases. What these tests did was more or less generate a tiny script that called an executable with a test name as the argument. To run particular tests, just run the test executable with the name of the test as the argument. The meson setup doesn't install test files anymore. The autotools test suite was designed towards working with installed tests, but it didn't really still, and now with meson, it doesn't install anything at all, but instead makes sure that everything runs with the uninstalled input files, binaries and libraries when running the test suite. Installable tests may come later. Tests from cogl, clutter and mutter are run on 'meson test'. In autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 09:55:35 -04:00
subdir('tests')
endif
Reference in New Issue Copy Permalink