Calling _teardownPipeline() before _tryNextPipeline() was actually not a
good idea, it sets the pipelineState to STOPPED, which means we can't try
any of the following pipelines anymore.
Instead what we want to do is set the pipeline state of the old pipeline to
NULL when trying a new one, without calling _teardownPipeline() for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2754>
(cherry picked from commit 846bb84ff6)
This pipeline imports dmabufs and does format conversion using GL.
The `video/x-raw(memory:DMABuf)` filter ensures format negotiation
between `pipewiresrc` and Mutter will only succeed if Mutter advertises
dmabuf support as well, falling back to the next pipeline otherwise.
Using this pipeline frees Mutter from downloading buffer content on the
main thread which can have a big impact on compositor performance.
Doing format conversion on the GPU should further improve the overall
performance on most hardware.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2597>
(cherry picked from commit b916ced2e6)
When the screencast dbus service crashes due to gstreamer, we should also
handle that and not pretend to continue recording.
Let's listen to g-name-owner changes for that and then also send a
notification about it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2752>
(cherry picked from commit fd730a4db7)
Make sure gnome-shell gets notified of errors that happen during screen
recording using the screencastService, so that it can properly notify the
user about the error and tear down its state, too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2752>
(cherry picked from commit c494597a91)
Pipewire versions < 0.3.67 may not fail immediatly on negotiation
errors, thus use the last/fallback pipeline directly.
Technically, a similar recent version of Wireplumber is required
as well, but we can't check that easily and the combination of old
Wireplumber and new Pipewire is quite unlikely.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
(cherry picked from commit 80d72cfd32)
Introduce a fallback mechanism for gstreamer pipelines that allows to
define multiple pipelines and prefer them over each other.
The way this works is that we introduce a new STARTING PipelineState.
While the Recorder is in that state, it is allowed to tear down the
current pipeline and start another one whenever an error happens, this is
used to try multiple pipelines in a fixed order until a working one is
found.
Right now there's just a single pipeline using the existing vp8 encoder, the
actual new encoders and pipelines will be added in a separate commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
(cherry picked from commit 9cb40c4814)
The check for the Pipewire version was originally introduced in
d32c0348 which states:
> Since it is not clear yet when a proper solution will arrive,
> this makes use of `always-copy` as a workaround for now and
> should be reverted once it is no longer needed.
The check for a stable Gstreamer version with the mention proper fix was
introduced in d7b44319 and carried for the 43 cycle.
By the time Gnome 44 will be released all distros should have had enough
time to update their Gstreamer version - or backport the patches, in
case of not ustream-supported versions.
Thus lets drop it now.
Note: `always-copy` is not suitable for dmabuf buffers as it copies via
mmap.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
(cherry picked from commit 46517e02dd)
Right now when we tell gstreamer to move the pipeline to the state
PLAYING, we pretend that happens immediately and set our PipelineState
to PLAYING right afterwards.
In reality though it's more complicated than that: Gstreamer changes
states asynchronously and set_state() returns a Gst.StateChangeReturn.ASYNC.
In that case we should wait until the according STATE_CHANGED event happens
on the bus, and only then set our PipelineState to PLAYING.
Since the STATE_CHANGED event will also happen when set_state() returns
SUCCESS, we can use the same async logic for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
(cherry picked from commit cad01d154c)
Gstreamer can produce various errors, we shouldn't pretend those don't
exist and go on as usual when one happens. Instead, when an error
happens, tear down the pipeline, set our PipelineState to the new ERROR
state and bail out with a proper error message.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
(cherry picked from commit 42af7e53a2)
We're tracking three different state-machines in the Recorder object:
The state of the gstreamer pipeline, the state of the screencast
session, and the sender of our dbus invocation that might vanish.
Properly handling errors that might appear in any of those three "black
boxes" is not easy, especially tearing down the other two when one of
them breaks.
So refactor the error handling here: Add a single error path for each of
those three states we're tracking, and make them all subsequently call
the _bailOutOnError() method. From there we tear down the other states and
call the error callbacks.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
(cherry picked from commit cbfbdc4be5)
The handler dates back to commit 50f248ec5b in 2011, and is
part of the original hack of making the activities button a
PanelMenu.Button while suppressing its menu.
By now, panel buttons without a menu have been properly supported
for years, but somehow that bit of the hack stuck around, even though
it is no longer actually needed (probably since the introduction of
DummyMenu.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2741>
When we can't detect a headphone by form factor, we do a string
match on the port name. A match on 'Headphone' isn't less likely
to be valid than a match on 'headphone', so make sure we ignore
capitalization.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2691>
Provided we use the correct version of the SpiderMonkey shell, we
can perform checks using the same engine that is used by gjs.
However some engine features are opt-in, so the set of features enabled
by gjs and js102 may differ. The obvious option for avoiding this is
replacing js102 with gjs for tests.
For that reason the check-potfiles.js script has been ported to gjs
and a second (simpler) script to replace `js102 --compileonly` was
added. This work happened in a separate repository to make sharing
between different JS-based projects easier.
Update the CI image to pull in those scripts and include gjs.
This will also address the issue that `js102 --compileonly` does not
handle modules.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2193>
Both the subdir and prepare arguments are very specific to
building the extensions-tool subproject stand-alone. In order
to make the script more generic, turn those required arguments
into optional --subdir and --prepare ones.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712>
We currently remove the directory at the end of the script, but
that code is only reached when all previous operations were
successful.
Address this by first using an absolute directory path in /tmp
instead of a "random" location based on the CWD, then set a trap
to remove it on exit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712>
The script has four mandatory arguments, and also accepts optional
build options that are passed on to meson. Checking for the number
of arguments *before* filtering out the optional ones means that
`./install-meson-project.sh -Done=1 -Dtwo=2 -Dthree=3 -Dfour=4`
is considered valid, even though not a single required argument
is passed.
Fix this by filtering out the arguments before doing the usage
check. As it is a nice touch to have usage information at the
top of the script, move the message into a usage() function at
the top.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712>
If we have multiple desktop ID's that share the same startup-wm class
and none of them is actually matching the desktop-id, then we should
exclude the ones that should not be shown in the current desktop.
This will help preventing cases such as the previous one in case no
desktop file ID would match the startup-wm-class exactly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721>
When fetching the desktop ids into a map of startup-wm classes we meant
to give the ones that match the desktop ID more priority, however
this did not happen because we were always comparing a desktop
file id, including the `.desktop` suffix, with a wm-class that generally
does not include that.
This is the case of gnome-system-monitor, that provides two desktop
files, one of which is OnlyShowIn=KDE but both have the same
StartupWMClass and thus the first parsed is preferred, even though its
desktop-id is gnome-system-monitor-kde.
As per this, remove the .desktop suffix when comparing it with the
startup-wm-class, keeping the old check just in case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721>
After the introduction of implicit grabs in Clutter, a release
event will now always be delivered to the actor that received
the corresponding press event.
This results in surprising behavior when moving the pointer
while pressed, as a button release will always activate the
original item, even when the pointer moved to a different item
or outside the menu altogether.
Address this by checking the hover state (that is, whether
the item contains the pointer actor) before activating it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6606
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2740>
