When preparing the uri-list for a file list of copied files, only the
actual selected files and folders need to be included in the uri-list,
since files in subfolders are automatically handled.
To check for the selected files, gnome-remote-desktop only checks for
the backslash ('\\') operator, but not also for the slash operator
('/'), which could lead to errors during the pasting operation, even
though the use of the slash operator in file lists is discouraged.

Fix this situation by also accounting for the slash operator, when
preparing uri-lists.

See also: https://github.com/FreeRDP/FreeRDP/issues/8350

In the initial days the RDP backend in gnome-remote-desktop, the legacy
path (mostly the RemoteFX codec path) was an easy and fast way to
implement a way to submit frame updates to the client.
In addition to the RemoteFX codec path, a path for the NSCodec and for
raw bitmaps was added.
The reason for the latter two was a misconfiguration of popular
clients, namely Remmina and xfreerdp.

Remmina by default assumed, that the server side always supports AVC
and that the client side is able to choose the used codec.
The reality is that Remmina actually limited the supported codecs,
forcing the server side to use worse codecs, leading to a reduced
remote desktop experience.
xfreerdp also supported all codecs, but never advertised them, leading
to the same bad experience (high bandwidth usage, very low
performance).
Remminas issues were fixed two years ago in [0] by always advertising
all supported codecs by default.
xfreerdp does the same since version 2.7.0.
Distributions, like Ubuntu also backported the respective changes.

As times passed, the problems of the legacy path became visible:
Fastpath updates cannot be larger than a negotiated size, and therefore
PDUs using the fastpath must be split into multiple parts manually.
This is especially a problem for the NSCodec and the raw bitmaps path,
as their maximum output size is not predictable, resulting in bad
performance and dropped updates.
Both symptoms result in a horrible remote desktop experience.
The graphics pipeline and any other virtual channels are unaffected by
this, as virtual channels either run via the slowpath or via UDP.
Despite its name, the slowpath is not slow, but has additional overhead
on the network traffic.
PDUs of dynamic virtual channels (DVCs) are also split, but on a lower
level, basically not affecting any PDU usage in the channels
themselves.

Additionally, the raw bitmap path has certain alignment restrictions
(e.g. width and height MUST be a multiple of 4), making it unsuitable
for the usage of headless sessions, where arbitrary resolutions are
used.
Furthermore, users don't know any internals of the Remote Desktop
Protocol (RDP) and if they try to force the usage of the legacy path,
they will have a slow remote desktop experience and blame it on the
server.

Due to the amount of problems with the legacy path and the maintenance
cost, start deprecating the legacy path.
For this, only allow for now the legacy path to be used, when the
respective debug environment variable is set.
In the next development cycle, start removing the legacy path.
The graphics pipeline is already the default in Azure, where it is used
for the infamous RDP short path and with the aforementioned changes
both xfreerdp and Remmina also now always prefer the usage of the
graphics pipeline.

[0]: https://gitlab.com/Remmina/Remmina/-/merge_requests/2099

Buffers containing frame data received by mutter always contain buffers
of type MemFd or DmaBuf.
So, remove the path that ignores the buffer data, as it is supposed to
be never hit.

Buffers containing frame data received by mutter always contain buffers
of type MemFd or DmaBuf.
So, remove the path that ignores the buffer data, as it is supposed to
be never hit.

This only leads to an assertion hit. If it would not hit the assertion
in on_frame_ready, it would leak the frame.

Fixes: https://errors.ubuntu.com/problem/6f9ac35833672d86f0f7a13a9a68551f186a55f2

This is a preparatory step in making the buffer struct private.

The task is not directly done, but actually queued to the EGL thread.
Also invert the is-mapped-condition for more readability of the code.

This allows us later to hide the buffer struct internals, while keeping
its functionality.
The actual code was just copied from the rdp-pipewire-stream class.

This allows us later to hide the buffer struct internals, while keeping
its functionality.
The actual code was just copied from the rdp-pipewire-stream class.

This allows us later to hide the buffer struct internals, while keeping
its functionality.
The actual code was just copied from the rdp-pipewire-stream class.

With the previously added APIs to access some of the buffer internals,
avoid now the direct usage of any buffer attributes by using the buffer
API methods instead.

Now that the buffer attributes are no longer used directly, make the
buffer struct private.

(cherry picked from commit 09849926)

Since the mapping operation failed, the frame data is invalid.
So, ignore it by using FALSE as success value for on_frame_ready.

When handling PipeWire buffer contents, it is possible that a frame
contains both frame data and pointer data.
In such case, the frame data might need to be processed on the EGL
thread.
In this particular situation, the pointer data is handled first in the
PipeWire data thread and then a task is pushed into the queue of the
EGL thread.

While the frame data is processed on the EGL thread, a new pointer
update can occur and be directly handled.
If the frame data of the previous PipeWire buffer was now finished
processing, both frame data and pointer data of that PipeWire buffer
are now pushed to the actual frame handling of the respective backend.
The frame data is now new, but the pointer data is not and should be
dropped.

This currently results into old pointer updates replacing newer
updates.
To handle this situation, simply decouple pointer updates from frame
updates.
For that, add a separate GSource for the pointer data, where it is
handled alone.

When handling PipeWire buffer contents, it is possible that a frame
contains both frame data and pointer data.
In such case, the frame data might need to be processed on the EGL
thread.
In this particular situation, the pointer data is handled first in the
PipeWire data thread and then a task is pushed into the queue of the
EGL thread.

While the frame data is processed on the EGL thread, a new pointer
update can occur and be directly handled.
If the frame data of the previous PipeWire buffer was now finished
processing, both frame data and pointer data of that PipeWire buffer
are now pushed to the actual frame handling of the respective backend.
The frame data is now new, but the pointer data is not and should be
dropped.

This currently results into old pointer updates replacing newer
updates.
To handle this situation, simply decouple pointer updates from frame
updates.
For that, add a separate GSource for the pointer data, where it is
handled alone.

The usage of the CUDA function cuDeviceComputeCapability is deprecated.
The CUDA documentation mentions, that this function was superceded by
cuDeviceGetAttribute, so use that one instead to retrieve the compute
capability of CUDA devices.

When destroying a PipeWire stream, gnome-remote-desktop needs to handle
two cases:

1. Ensure, that all PipeWire buffers have been processed by the EGL
   thread.
2. Ensure, that while waiting on the EGL thread, no new buffers are
   queued onto the EGL thread.

This was initially done with a helper variable and a call to
pw_stream_flush, which mostly solved the situation, but not always.
When audio output forwarding was implemented, it was discovered, that
setting a PipeWire stream inactive seems to wait for the PipeWire data
thread, as the PipeWire data thread in audio streams was waiting for a
mutex to be released, and the inactive call did only return, when that
mutex was unlocked.
As a result, the old mechanic during the stream destruction was
replaced by setting the PipeWire stream inactive.
However, regardless of this, there are still crash reports in both
Fedora retrace and Ubuntu errors.

It appears, with some help in reproduction using GConds and g_usleep(),
that setting a PipeWire stream inactive, does not wait for the data
thread to end its iteration.
This is at least true for any screencast stream.

So, to finally fix this situation, do not rely on any PipeWire methods
any more.
Instead, introduce, like initially done, a helper variable, that tells
the PipeWire data thread to not dequeue any buffers any more.
However, instead of flushing the stream, pair the helper variable with
a mutex.
The PipeWire data thread will lock the mutex during its whole
operation, while the main thread only locks it to set the helper
variable.

This partly reverts 4303a4f5.

There is no need to invoke the frame source here, as there is no new
frame in this situation.

Since frame updates and pointer updates were decoupled, each frame
always has a buffer, when success is TRUE, so remove the
steal-buffer-operation.

Since frame- and pointer-update-operations were decoupled, this
condition is not necessary any more.

When destroying a PipeWire stream, gnome-remote-desktop needs to handle
two cases:

1. Ensure, that all PipeWire buffers have been processed by the EGL
   thread.
2. Ensure, that while waiting on the EGL thread, no new buffers are
   queued onto the EGL thread.

This was initially done with a helper variable and a call to
pw_stream_flush, which mostly solved the situation, but not always.
When audio output forwarding was implemented, it was discovered, that
setting a PipeWire stream inactive seems to wait for the PipeWire data
thread, as the PipeWire data thread in audio streams was waiting for a
mutex to be released, and the inactive call did only return, when that
mutex was unlocked.
As a result, the old mechanic during the stream destruction was
replaced by setting the PipeWire stream inactive.
However, regardless of this, there are still crash reports in both
Fedora retrace and Ubuntu errors.

It appears, with some help in reproduction using GConds and g_usleep(),
that setting a PipeWire stream inactive, does not wait for the data
thread to end its iteration.
This is at least true for any screencast stream.

So, to finally fix this situation, do not rely on any PipeWire methods
any more.
Instead, introduce, like initially done, a helper variable, that tells
the PipeWire data thread to not dequeue any buffers any more.
However, instead of flushing the stream, pair the helper variable with
a mutex.
The PipeWire data thread will lock the mutex during its whole
operation, while the main thread only locks it to set the helper
variable.

This partly reverts ce68ee97.

There is no need to invoke the frame source here, as there is no new
frame in this situation.

Since frame updates and pointer updates were decoupled, each frame
always has a buffer, when success is TRUE, so remove the
steal-buffer-operation.

Since frame- and pointer-update-operations were decoupled, this
condition is not necessary any more.

Like with screencast streams, do not assume, that setting the stream
inactive will also always stop the PipeWire data thread.
Directly destroying the PipeWire stream also clears the stream
listener, so don't try to remove it manually, as clearing it before the
stream could potentially lead to unwanted side effects and trying to
clear the hook after the stream itself is an invalid operation.

Clients can send invalid monitor layouts and that is a problem on the
client side.
Such clients should be disconnected, so extend the possibilities for the
error info PDU to be able to also notify such errors before
disconnecting such client.

Currently, when a remote desktop client sends an invalid monitor layout,
gnome-remote-desktop either assesses it as valid or it ignores it.
This is not ideal, because if the layout is invalid, it is a bug in the
remote desktop client.
If the layout really changed, then users may perceive such situation,
where gnome-remote-desktop just ignores such layout, as server issue.
Especially, for future situations, where gnome-remote-desktop will have
to handle multi monitor configuration, an invalid layout can lead to
undefined behaviour, when attempting to sanitize the layout data, such
as gaps between monitors in the layout, or overlapping monitors.

To handle these situations better, always output warnings for invalid
monitor layouts and disconnect the client.

The display virtual channel extension is very simple: The server side
first sends the capabilities PDU and only then, the client is allowed to
send new monitor layouts.
If the client sends a layout, before the server sent the capabilities,
the client violated the protocol message order.
In such case, the client was also not able to constrain the layout to
the given capabilities.

To handle this situation, disconnect the faulty client.

While unexpected, theoretically, the include dir in the pkgconfig could
change between updates.
So, don't use the full path for the include path of the related header
files.

Plain RemoteFX exists not only in the graphics pipeline, but also in
the legacy path.
RemoteFX in the legacy path has two modes: image mode and video mode.
While gnome-remote-desktop already advertises RemoteFX in video mode,
the image mode is currently not advertised.

To avoid any potential problems with clients, also advertise RemoteFX
in image mode.
Since only the server side produces RemoteFX encoded content, this
won't lead to problems.
RemoteFX in image mode is an inferior method to transfer encoded image
content, compared to the video mode.
However, it might be accepted by more clients.

Recent glib versions have an additional check in the handling of
GTasks, where it is checked, whether a GTask returned anything before
it is destroyed.
When no GTask-return call has been made, glib will print an annoying
warning about a potential bug, regardless of whether it is a bug to not
call g_task_return_*() or doing it.

For the clipboard handling in gnome-remote-desktop,
gnome-remote-desktop must be able to retrieve the clipboard content in
an async way, while also be able to answer clipboard content requests
before advertising new mime type lists.
As a result, gnome-remote-desktop cannot handle the read result in the
GTask callback, because in that case, the new mime type list was
already announced and the read request must have been already handled.
To be able to handle that situation, gnome-remote-desktop cannot use
any g_task_return_*() calls to return actual results.

To just get rid of this new glib warning, just call
g_task_return_pointer() with a NULL pointer in the GTask thread.
The overall behaviour stays the same and will continue to function,
however without that new annoying warning.

Otherwise, resources associated to the context are leaked.

The EGL thread handles transfer tasks, like uploading frame data to the
GPU or downloading dma-buf images to the host.
These tasks are all queued up into a queue, so before a task is
handled, all its previous tasks must be handled.
Some GPU drivers, like the Intel driver are extremely slow, and during
screencast sessions it is not rare, that multiple frames for one stream
are queued up, while the previous ones could and should be dropped, as
having a low frame latency is important in remote desktop sessions.

To be able to drop older operations, add the ability to acquire EGL
slots.
When submitting tasks to these slots, the pending frame operation is
dropped, while its callback is still called to be able to queue the
related PipeWire buffer again.
The overall order in the queue is still preserved across slots, so sync
operations are still possible to do.

Since the EGL thread can now replace transfer tasks using EGL slots,
create one for each stream.
This eliminates the frame latency, that was caused due to lots of
pending tasks, when using slow drivers, like the Intel driver, where
previously it was not unusual to have up to 7 pending download tasks.
Do, however, not create an EGL slot for streams, when CUDA is
available, as currently gnome-remote-desktop still relies on CUDA-map
and -unmap operations for hardware acceleration with NVIDIA GPUs and
these tasks are not considered in this design.
In the future, these CUDA-map and CUDA-unmap operations will be replaced
by a different mechanism.

Since the EGL thread can now replace transfer tasks using EGL slots,
create one for each stream.
This eliminates the frame latency, that was caused due to lots of
pending tasks, when using slow drivers, like the Intel driver, where
previously it was not unusual to have up to 7 pending download tasks.

FreeRDP 2.10.0 contains a very important fix ([0]) in the DRDYNVC
handling, which prevents data PDUs in DVCs (DYNVC_DATA_FIRST and
DYNVC_DATA) to be processed and forwarded to channel handlers, when the
respective channel has not been opened successfully.
This fix is a requirement for the [MS-RDPEA] SVC fallback handling, as
otherwise a security issue would be introduced, where a malicious client
could respond with a negative creation status for the DVC creation, but
continue sending PDUs of that not successfully opened DVC, leading to
undefined behaviour.
This undefined behaviour cannot be reliably prevented without the fix in
[0].
So bump the FreeRDP version accordingly.

[0]: https://github.com/FreeRDP/FreeRDP/commit/559dcf214a2a1203e43d57d2b7b048c5612b4f05

In the early days of RDP, only static virtual channels (SVCs) existed.
As a result, there was only the RDPSND SVC for audio output
redirection.
Later, Microsoft added the DRDYNVC SVC, which tunnels dynamic virtual
channels (DVCs).
Dynamic virtual channels have some advantages: They can be opened and
closed on-the-fly during the session without problems, are not limited
by the maximum of 31 SVCs, and, if available, can use UDP as transport
method.

The audio output redirection protocol is quite unique in RDP, as it can
be used over multiple types of channels.
While in the past only the RDPSND SVC was used, today, MS Windows RDS
first tries to open the DVC for audio output redirection and then falls
back to the SVC, if the DVC is unavailable.

gnome-remote-desktop currently only supports the DVC. The main reason
was: It works with the major clients mstsc and FreeRDP-based clients.
Mobile clients, like the Microsofts iOS and Android client did cause
problems, because it appeared, that audio and remote desktop
interaction stuttered heavily, when both audio and graphics updates
were sent at the same time.
These mobile clients only support the SVC and as a result, an SVC
fallback, when the client does not support the DVC was not added.

However, Microsofts Mac client also does not support the DVC and
therefore requires the SVC in order to have audio output redirection.

So, implement the SVC fallback for [MS-RDPEA] and in the next commit,
exclude mobile clients based on their reported OS type.

Now that the SVC fallback has been implemented, mobile client (iOS and
Android) need to be excluded with a different method.
Use for this their reported osMajorType versions.

In the future, when their heavy audio stutter issue during simultaneous
audio and graphics updates is resolved, remove this exclusion.

This might help, when debugging issues.