While the events when processing keybindings are quite obviously
key events, the individual structs are all opaque and all public
API is provided by the generic ClutterEvent type. That means that
any handler that uses the passed in event must cast it to
ClutterEvent anyway, so drop the cast to ClutterKeyEvent when
processing key events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4080>
As that is where the whole text rendering integration happens
And would allow us to get rid of some over-abstraction in cogl-pango,
simplify
ClutterSnapshot integration as well
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4004>
Quoting Ebassi https://www.bassi.io/articles/2023/02/20/bindable-api-2023/:
Whenever you’re describing a function that takes a callback, you
should always annotate the callback argument with the argument that
contains the user data using the (closure argument) annotation
You should not annotate the data argument with a unary (closure).
The unary (closure) is meant to be used when annotating the callback
type
Recently gobject-introspection became a bit more strict with this and
that generated some warnings:
Warning: Cogl: invalid "closure" annotation: only valid on callback
parameters
This commit fix all the closure annotations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4058>
These properties now are tagged unions:
- ClutterColorimetry:
Can be from colorspace or primaries;
- ClutterEOTF:
Can be from known tf or custom gamma exp (next commit);
- ClutterLuminance:
Can be defined explicitly or derived;
Make the color management protocol use them too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4020>
Add a test that:
- Creates 2 clients
- Leases a connector using the first client
- Tries to lease the same connector using the second client
- Checks that the first lease succeeded
- Checks that the second lease failed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4031>
Add a test that:
- Creates 2 clients
- Leases a connector using the first client
- Checks that the first client receives a lease_fd event
- Checks that both clients receive a connector withdrawn event
- Finishes the lease
- Check that both clients have access to the connector
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4031>
Add a test that:
- Creates 2 clients
- Releases a device for each client
- Checks that releasing a device for one client doesn't affect the other
- Checks that an error is raised if a released client is used
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4031>
Add an event queue to the DRM lease client that allows to check that the
compositor sent the expected events in the expected order.
For the moment, the event queue is used to check that the initial
connection to the compositor works as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4031>
Add the most basic possible test that checks that:
- The DRM lease protocol is available
- At least one device is advertised
- At least one connector is available for lease
Organize the code in a way that it is possible to created multiple DRM
lease clients at the same time as future tests will need this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4031>
Add the required files to run DRM lease using the KVM/tty backends.
DRM lease tests need at least one connector available for lease. Instead
of adding the test to "wayland-unit-tests.c", add it to its own file and
set the environment variable MUTTER_DEBUG_LEASE_CONNECTORS=Virtual-1 to
make the only connector created by VKMS by default available for lease.
This commit doesn't add any tests, just the required files to start
adding them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4031>
Now that we copy this into a temporary XDG_DATA_HOME, we don't need
to have it duplicated in the source tree as well.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4012>
Previously these tests tried to write to /usr when run as an
installed-test, which happens to work on Gitlab-CI because we're running
as root inside a container, but will not work when running in a more
realistic scenario as an unprivileged user (which is how Debian's
autopkgtest framework runs this test suite).
This also avoids leaving non-package-manager-managed detritus in /usr.
In color-management-tests, we can just delete the code that sets
XDG_DATA_HOME.
In color-management-profile-conflict-test, we also need to copy
the conflicting vx239-calibrated.icc into the temporary XDG_DATA_HOME
to get onto the code path that this test is intended to exercise.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/3658
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4012>
It is intended to replace using GetResources() and ChangeBacklight().
It moves from a normalized 1-100 numbers, to directly exposing the
hardware. This more closely maps to how gsd-backlight.c in
gnome-settings-daemon normally works, and simplifies the API a bit to
not have to deal with rounding issues.
There is still no KMS uAPI for this, so it still only hooks up to
XRANDR. Being private API, it doesn't try very hard to predict how the
KMS uAPI will look. When that day comes, it will likely need some
adaptations.
Part of the motivation here is to get something for gsd-backlight.c to
use where it can work more similarly to how the current common case
(sysefs) works, while attempting to migrate away from libgnome-rr.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3861>
We know let Xwayland set the RANDR names from the connectors. To stop
relying on layouts and coordinates to match the primary logical monitor,
instead use the connector name of the first monitor.
Also make the X11 client sanity checking check that the right X11 output
is primary as part of the monitor tests.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
Launching pipewire and wireplumber is racy, as there is an arbitrary
amount of time between pipewire is launched, and that the socket is
bound.
In order to eliminate this race, bind the pipewire sockets ourselves,
and launch pipewire (and wireplumber) when there is activity on the
socket. This is using the systemd method of doing socket activation,
which consists of passing the number of passed file descriptors via
$LISTEN_FDS, and the pid of the launchee via $LISTEN_PID.
The former is easy, just pass the file descriptors, but the former is
more tricky when using python, as executing code before exec() is poorly
supported and likely to be deprecated. To address this, socket
activation services are wrapped in a socket-launch.sh helper which sets
the $LISTEN_PID to itself before calling exec().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3973>
list = ['one']
list.append('two,three'.split(','))
results in ['one', ['two', 'three']]
while
list += 'two,three'.split(',')
results in ['one', 'two', 'three']
which is what is expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3973>
