They are not statements and after macros are expandend leave stray ';'
in the syntax tree. Harmless unless one passes -pedantic, but lets be
slightly more correct anyway.

TEST was always used, and only if the password was set, lets make it a
bit more predictable.

Will be needed by EGL DMA buffer download functionality.

It does nothing more than up a thread with a main loop, but will be used
to download DMA buffers to CPU memory.

We don't need to use the PipeWire API to go via the pw_loop to invoke on
the main thread, it's managed by a GMainContext/GMainLoop.

This will make it easier to off-load asynchronously e.g. to another
thread.

It uses a dedicated thread used for downloading pixels from DMA buffer
using OpenGL. This will ensure we use the right driver dependent method
is used for transferring the GPU memory of the DMA buffer to CPU memory.

Adds a variable to the pending frame, that will be removed. Makes for
slightly shorter code, and will help with future changes.

Will help with cleaning up when things get more async. The _ref()
variant will be added later, when usage is introduced.

This function is meant to be able for users to "flush" any queued tasks,
meaning it can be sure no more tasks will be ready after the flush,
assuming no more are queued after. Will be used when stopping sessions.

This ensures we use the driver specific method for downloading DMA
buffers. This also allows us to explicitly ask for DMA buffers when
negotiating PipeWire stream parameters.

There are no places taking a reference yet, so add that later.

Get the frame via a callback instead of as a return value. Will simplify
future changes when the result may be more async.

Framebuffer fetching will soon potentially become asynchronous, lets
prepare for that.

It'll be used by the RDP backend too.

Will be used in more places, so avoid duplicating that code.

This, just as with the VNC backend, will ensure that we use the right
driver specific method for downloading DMA buffer contents into the
framebuffer used for RDP.

Was used for the removed mmap() approach.

Will be used for explicit DMA buffer PipeWire support.

This is needed for proper DMA buffer PipeWire support if the producer is
updated to require a modifier property for enabling DMA buffer
allocation. It does not break compatibility with old producers, and as a
bonus, explicit DMA buffer support will work once the producer supports
it.

This is needed for proper DMA buffer PipeWire support if the producer is
updated to require a modifier property for enabling DMA buffer
allocation. It does not break compatibility with old producers, and as a
bonus, explicit DMA buffer support will work once the producer supports
it.

FreeRDP 2.4.x includes an important fix for an fd leak, that happened
when copy-pasting files from the server side to the client side.
While the fd leak did not happen in most situations (due to usually
only having small file lists), it is still desirable to prevent this
behaviour.

To ensure, that gnome-remote-desktop cannot run into such fd leaks,
bump the FreeRDP version requirement.

When the VNC client is gone, the local rfb_client pointer is set to
NULL.
Since VNC sessions are not directly stopped, other GSources can run
before an idle GSource stops the session.
Such GSource can be the pipewire_source. If a VNC client closes the
connection after a stream is created, but before the framebuffer size
is known, gnome-remote-desktop crash, when resizing the framebuffer, as
rfb_client may already be NULL.

To fix this situation, check whether the client is gone, before
attempting to resize the framebuffer.

Fixes: https://errors.ubuntu.com/problem/ab880706e8a266568463cc4869ad9234e25a7d3b

https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/70

When refusing a VNC client, due to already having an active VNC
session, gnome-remote-desktop just prints a debug message.
This debug message is by default not visible on the journal.
When users run into situations, where gnome-remote-desktop refuses new
clients, they won't know why they cannot establish a connection
successfully.

To take care of this situation, make this deny-message more explicit by
using g_message(), since this will print the reason for the denial
visibly to the journal without the need of an environment variable.

Closes: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/80

mutter on current main has support for adding screencast sessions, when
the remote desktop session is already active.
This allows gnome-remote-desktop to perform monitor configuration
changes during an active remote desktop session.
Although the current remote desktop and screencast interface lacks some
features for multi monitor support, like having a way to rearrange the
monitors, it is still desired to have the new API, as it allows
gnome-remote-desktop to have similar paths for remote assistance and
headless sessions in the future.

The screencast API in mutter received support for creating virtual
monitors.

Synchronize the screencast API so that gnome-remote-desktop can make
use of the changes.

As the code style in the API in mutter was unified, synchronize the
changes.

Like the screencast and remote-desktop API, the code style in the
gsettings schema is mixed.
Fix this by replacing all tabulators with spaces.

Currently, the serial of a GFX surface is not set, making the serial
for each GFX surface effectively 0.
This is currently not a problem. But with virtual monitors and dynamic
resolution, this can lead to crashes in surface_serial_unref() in the
graphics pipeline, when not all frame acks are received, but the
virtual monitor has been recreated.
In that case the surface context is replaced and the old reference
count is lost, leading to an assert hit, when a frame ack is received
and the reference of the old surface serial is decremented.

Fix this issue by setting the surface serial, when creating a new GFX
surface.

Compute operations on the GPU run in blocks. Each block consists of a
certain amount of threads.
Since these blocks are always a multiples of the warp size, additional
out-of-bounds checks are required when reading or writing memory on the
GPU.
For the NV12 buffer this is done in all cases. For the source data too,
except in one case, when reading the pixel x = 0, y = 1, in a 2x2
rectangle.
In that case, an invalid memory access can happen and all subsequent
CUDA operations will fail.

Fix this by adding the missing out-of-bounds check.

Add a member function for grd-session, which will be called, when the
remote desktop session is started.
This allows subclass implementations to call necessary initialization
methods, that depend on the remote desktop session being started.

This will be used for monitor configuration changes during a session
and to unify both remote assistance and headless session paths.

The on_pipewire_stream_closed() function relates to the stream_ready()
function and not to the remote_desktop_session_ready() function.

Make this clear by moving this function accordingly.

When dealing with multi-monitor setups in the future, and
gnome-remote-desktop gets an absolute pointer motion event, it needs to
somehow identify the stream.
The session class won't be able to choose the correct stream in
multi-monitor setups, the respective backend (RDP or VNC), however,
can.

So, require the stream instance to be submitted for each absolute
pointer motion event.

With the new method in the screencast API to start streams on-the-fly
being implemented, gnome-remote-desktop can now adopt to this API.
This unifies the path for remote assistance and headless sessions, as
headless sessions have the ability to let the client change the monitor
configuration during a session without having the client side to
reconnect and that configuration change requires this new API.

Hardware acceleration for NVIDIA GPU based systems will later not just
be used for NVENC, but for plain CUDA too.
Also, this class is itself not dependent on the RDP backend.

So, change the name accordingly.

When initializing the EGL thread with the platform
EGL_PLATFORM_SURFACELESS_MESA, it won't be hardware accelerated, when
using the NVIDIA drivers.
The result is that EGL Thread will be torn down, although it could
actually be used with the NVIDIA drivers, even when dma-buf are not
used:

With CUDA, it is possible to map pixel buffer objects for the use in
CUDA.
These mapped CUDA buffers can then be used for e.g. the damage region
creation on the GPU, which is much faster than the creation on the CPU,
or be used in NVENC later.
The EGL thread can then, when dma-bufs are used, directly map the frame
data.
When dma-bufs are not available, the frame data can be uploaded, which
is done in future commits.
With this operation in the EGL thread, it won't block the graphics
thread in the RDP backend, which allows the RDP backend to maximize the
maximum possible framerate, due to shorter encoding times, as there
won't be a blocking upload operation be any more.

It would also make the implementation with the support of dma-bufs
easier in the future.
With dma-bufs, the frame data can then directly mapped, while being
implementation-wise close to the non-dma-buf path.

So, add a fallback path using the platform EGL_PLATFORM_DEVICE_EXT to
enable the ability to directly map pixel buffer objects, when using the
NVIDIA driver.

This allows e.g. fetching the compute devices from the current GL
context for CUDA.

There are several situations in gnome-remote-desktop, where one thread
has to wait on another thread to finish a certain task.
For these situations, a combination of a GCond, a GMutex, and a boolean
value is used.
This signal-wait mechanism has always the same pattern.
In order to avoid implementing it over and over again, create a helper
struct with helper functions, which take over the mechanism.

As the EGL thread will later upload data to the GPU or bind EGL images
from dma-bufs for the use in CUDA, the CUDA device should be the same
one as in the EGL thread.
To ensure this, CUDA provides an API to retrieve the current CUDA
devices associated to the current GL thread.

So, use this API to retrieve the CUDA devices from the EGL thread and
use them for CUDA and NVENC.
Also use the helper struct and functions from the last commit for the
signal-wait mechanism, as the class for hardware acceleration for
NVIDIA devices is created in the main thread.

FreeRDP 2.5.0 contains a fix for a protocol violation in the display
control channel.

To ensure, that gnome-remote-desktop does not trigger the protocol
violation, bump the version requirement of FreeRDP.

Otherwise, the VNC backend leaks hundreds of Mebibytes within seconds.