The TPM2 tools work, but only if a TPM2 device is found. If no TPM2
device is found, they don't just fail, unless the daemon for the TPM2
device discovery is not installed.
Instead, they lead to a freeze in the thread of the program, where they
are called.
While this is an error in the TPM2 tools, people will run into this
issue.

So, prevent this issue by manually checking for a TPM2 device first.
If no TPM2 is found, just error out.

The telemetry channel is a channel with just one PDU. It is sent by
remote desktop clients supporting the channel, after the first graphics
update is received via the graphics pipeline.
It is useful, when trying to minimize the time until a remote desktop
session is established.
Upon receiving the telemetry PDU, log the received client metrics.

With the actual channel handling of the telemetry channel now been
implemented, hook it up now.

When the Open() call of a DVC fails, it was not due to a client issue,
but an issue on the server side, where the allocation of resources
failed.

So, fix this warning accordingly.

It is a client issue to not send the capability sets. While this
situation is unlikely to happen, add handling for this situation
nevertheless.

It is a client issue to advertise support for the graphics pipeline,
but not actually supporting it.
With the recently added API for DVC creation status subscriptions, add
now handling for situations, when the DVC of the graphics pipeline
cannot be opened.
When such situation happens, terminate the session.

RDPGFX_CAPVERSION_107 is similar to RDPGFX_CAPVERSION_106, except that
the client can announce with RDPGFX_CAPVERSION_107, that it does not
support any map-PDUs, that do perform scaling.
Since gnome-remote-desktop does not use these PDUs currently, adding
support for RDPGFX_CAPVERSION_107 is trivial. So, add it.

This value will be used in the next commit, when determining some
session metrics.

This is necessary to be able to identify the areas, where most time is
spent during the session creation.

Currently, the graphics pipeline is created in the socket thread after
the capability exchange, while other virtual channels are currently
created when the actual remote desktop session is ready, as these
channels cannot be created before or need to be created in the main
thread.
For consistency reasons do the same for the graphics pipeline.
This also has the advantage, that the graphics pipeline does not need
to be shut down immediately after creation, when starting the remote
desktop session fails.

Since the telemetry channel depends on the graphics pipeline, apply
this change also for that virtual channel.

This allows tearing down the display control channel, when e.g. the DVC
creation failed.

With the tear down handling now been hooked up, tear down the display
control channel, when the client does not support it.
There is no reason to keep the class instance, when the DVC creation
failed. It is just a waste of resources.

This is useful for debugging purposes.

Microsoft Windows imposes strict filename restrictions on its platform.
As RDP is developed by Microsoft and the RDS in MS Windows is typically
used as remote desktop server for the RDP protocol, these filename
restrictions are also enforced in WinPR, when copy-pasting files over
the clipboard.
However, in some connections no peer on MS Windows is involved and in
these situations, these filename restrictions are just an annoyance.

With a recent API addition in WinPR, it is now possible to override the
callback, where the filename is checked, whether it is valid.
So, use this new API to relieve the filename restriction, when the
connected remote desktop client is not on MS Windows.

With [0] mutter now also sends additional header data for each SPA
buffer.
This header contains a flag field, where mutter can specify, that a SPA
buffer is corrupted.
This flag is necessary, as queued PipeWire buffers, which wrap around
SPA buffers, MUST be queued again, after dequeuing them.
So, if setting the data in the SPA buffer fails, the buffer MUST be
ignored.

So, look for the header data in each SPA buffer. If available, and the
SPA_META_HEADER_FLAG_CORRUPTED flag is set, skip the buffer, instead of
trying to process it.

[0]: https://gitlab.gnome.org/GNOME/mutter/-/commit/30b5229e0eeb5117fe3061cfcc1d1e59c199f4d9

With [0] mutter now also sends additional header data for each SPA
buffer.
This header contains a flag field, where mutter can specify, that a SPA
buffer is corrupted.
This flag is necessary, as queued PipeWire buffers, which wrap around
SPA buffers, MUST be queued again, after dequeuing them.
So, if setting the data in the SPA buffer fails, the buffer MUST be
ignored.

So, look for the header data in each SPA buffer. If available, and the
SPA_META_HEADER_FLAG_CORRUPTED flag is set, skip the buffer, instead of
trying to process it.

[0]: https://gitlab.gnome.org/GNOME/mutter/-/commit/30b5229e0eeb5117fe3061cfcc1d1e59c199f4d9

It messes with the frame controller, so get rid of the clamp behaviour.

Otherwise, the associated data is leaked.

This unclutters the session-rdp class a bit.

Recently, it was discovered, that WinPR events are handled in
unexpected manners on a few systems.
To avoid unexpected behaviour, reduce their usage, wherever it is
possible.

Recently, it was discovered, that WinPR events are handled in
unexpected manners on a few systems.
To avoid unexpected behaviour, reduce their usage, wherever it is
possible.

The clipboard implementation in the RDP backend requires a function in
FreeRDP to parse received file lists from clients.
This function was previously only available in the client side library
in FreeRDP.
With the FreeRDP 2.8.0 release, the function definition is now
available in libfreerdp2 too, so remove the libfreerdp-client2
requirement.

Lock Clipboard Data PDUs can be sent at any point in time after the
clipboard capabilities and temporary directory have been exchanged in
the clipboard initialization sequence ([MS-RDPECLIP] 2.2.4.1).
With mstsc as RDP client, the PDU is sent before the
FormatListResponse.
So, in the locking stage, it is not yet known, that File Content
Requests are successful.
To avoid blocking in the main and CLIPRDR thread, a simple boolean
value, indicating whether requests are allowed or not, is used to
determine that state.

While extremely unlikely, but still possible, it may happen, that a
debug message is printed to the output, while the associated File
Contents Request is successful.

Fix this annoyance by retrieving the state first and then use the local
copied state to determine, whether that debug message should be shown
or not.

Recently, it was discovered, that WinPR events are handled in
unexpected manners on a few systems.
To avoid unexpected behaviour, reduce their usage, wherever it is
possible.

In order to get rid of the stop event during initialization of DVCs,
introduce a boolean value, which indicates, whether the session should
stop.
This boolean is only set once to TRUE in a session and is used in the
socket thread to determine, whether a DVC should be initialized or not.
This behaviour is still necessary, as the graphics pipeline is
essential for the session.
If support for the graphics pipeline is advertised, but actually not
supported by the client, it is an error in the client and the session
must be stopped.

When stopping all remote desktop sessions via the gnome-shell submenu,
the RDP backend needs to set the error info to prevent clients from
doing an autoreconnect.
Previously, the stop_event was used here too to determine, whether a
session was stopped via the gnome-shell submenu or not.
Replace this behaviour by checking now, whether an idle session close
source was created.

Getting rid of the WaitForSingleObject() call on the
completed_format_list_event is here trivial, as it is basically the
equivalent action as checking for the source id of the server format
list update.

To get rid of the other WaitForSingleObject() calls, which all check
here the stop_event, introduce a simple boolean value, which is set to
TRUE, when the clipboard instance is torn down.

Replacing WaitForMultipleObjects() calls is not necessarily trivial and
cannot be done with a general scheme.
It depends on how, where, and in which context these calls are used.
In clipboard-rdp, they are all used in the CLIPRDR thread, waiting for
actions to complete on the main thread.

So, in order to replace all WaitForMultipleObjects() calls here, use
for each action its own boolean value.
In addition to that, use the existing protocol_stopped boolean value to
check, whether the clipboard instance is torn down.
Use both variables (protocol_stopped, action) in a typical GCond-GMutex
code fragment to replace each WaitForMultipleObjects() call here.

The public grd_vnc_pipewire_stream_resize() function definition should
be in the upper part of the file, not at the bottom.
Also align the declaration in the header file to make it consistent
with the existing definitions and make the "PipeWire" string consistent
across all backends.

This makes the code shorter, while using effectively the same code.

The respective name of the screen share mode getter for the VNC backend
contains 'vnc', so align the getter for the RDP backend accordingly.

For consistency reason only use one variant here.

Move the code into a helper method, which is called both in the stop()
and dispose() callback.
This reduces the amount of code lines in the error paths, making the
overall code more readable.

The graphics pipeline is an integral part of the modern remote desktop
in the RDP protocol.
When adding new features, Microsoft adds new capability sets as part of
the capability negotiation.
These new capability sets may not be documented instantly or only on
request, and so it is beneficial to print unknown capability versions
to the output to get notified of them.

So, print any unknown capability set versions to the output in order to
become attentive about new functionality.

When overriding the render surface of a GFX surface, the render surface
is managed by its GFX surface.
This includes the destruction of the GFX surface, which is performed,
when its parental surface is destroyed.

When destroying all surfaces, e.g. because the monitor configuration
changed or due to a protocol reset of the graphics pipeline, then
currently all auxiliary surfaces (this includes the separate render
surfaces) are manually destroyed too.
Since they are already managed by their parental surface, a
segmentation fault can occur, when destroying an auxiliary surface.
In practice, this segfault, for some reason, did not happen yet, but
the error is there.
So, on some systems or situations, the segfault is expected to happen.

Fix this issue by marking all separate render surfaces as auxiliary
surfaces.
When clearing all surfaces, only clear the surfaces directly, that are
not marked as auxiliary surface, i.e. surfaces that are main surfaces.
Any auxiliary surface is destroyed, when its parental surface is
destroyed.

This makes tracking the lifetime of a GFX surface easier.

The NVENC session was just created here and is not any more in the
process of creation.
So, fix that message accordingly.

In case of Microsoft silently adds new flags to any existing capability
sets, always list the flags field of any known capability set, when
they are advertised by the client.
This way, new capabilities can be discovered more easily.
This is also helpful for debugging purposes.

Don't assume that the client sent a proper file list. Always sanitize
the data.

The filename in a FILEDESCRIPTORW structure is supposed to be a 260
long null terminated Unicode string.
These 260 characters also include the null terminator.
To prevent a potential out-of-bounds read due to malicious clients,
check these constraints.

It is unlikely that preparing the FormatDataRequest fails. But in case
the preparation of sending that PDU fails, don't leak the mime type
table.
Free the mime type table manually without the usage of an autopointer
to preserve the existing tail call optimization, when performing the
next mime type content request.

For performance reasons, the events to wait for are supposed to be
sorted in a way, that the least likely signalled events are sorted
before the events, that are signalled a lot.
When WaitForMultipleObjects() returns and an event was signalled, it
returns the index of the signalled event with the lowest index.
Currently, the returned index is unused, since the cause of spurious
event signals with WinPR events is not known yet.
However, regardless of this, do the first preparation step and already
sort the WinPR events to wait for accordingly.

When enabling the clipboard, the clipboard instance uses the return
value to determine, whether requests from mutter are possible or not.
When enabling the clipboard failed, the return value is recognized, but
the clipboard pointer in the session class is still set, leading to an
assertion hit, when a request from mutter is received, but the
clipboard was actually never successfully enabled.

To fix this issue, simply only set the clipboard pointer, when enabling
the clipboard was successful.

https://errors.ubuntu.com/problem/e118a2a1b7e6650ee263f50f52fdab8a5dcd18ee

This condition should here always be true.

In RDP, all codecs and the graphics pipeline require the peer to
support the colour depth 32 bits per pixel.
While advertising the support for codecs and the graphics pipeline, the
client can still prefer a specific colour depth, although it is
nonsense doing it.
This preferred colour depth setting exists for ancient servers (Win XP
era), but mstsc in recent MS Windows versions still allows a user to
set this setting.
The supported colour depths and support for the graphics pipeline are
submitted by the client in the Client Core Data, which is read before
the Capabilities() callback is called.
The colour depth used in the session is written by the server side in
the Bitmap Capability Set, which is sent after the Capabilities()
callback is called.

When reading the Client Core Data of a client, FreeRDP overrides the
ColorDepth setting, when the preferred colour depth of the client is
lower than the one on the server side.
While FreeRDP clients always automatically set the preferred colour
depth to 32, when any codec or the graphics pipeline is advertised,
mstsc does not.
This results into mstsc dropping the connection, if the user overrides
the preferred colour depth setting.

To fix this issue, check in the Capabilities() callback, whether any
codec or the graphics pipeline was advertised.
In such case, set the colour depth back to 32. This will result into
writing the correct colour depth value in the Bitmap Capability Set and
mstsc not dropping the connection, when the user selected a different
preferred colour depth in mstsc.
MS Windows RDS does the same, when the client supports the graphics
pipeline.

Fixes: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/118

meson.build_root() is deprecated, and we should use
meson.project_build_root() or meson.global_build_root(). The latter is
only relevant if we're built as a sub-project, which is unlikely, so use
the suggested replacement.

The former was deprecated.

This uses GKeyFile to store credentials; this will be used on headless
session where libsecret and TPM 2.0 are not available.

Using g_warning() is meant for the system log, not terminal
applications.

An audio output stream can already submit audio samples to the audio
playback instance, while its volume values might not be received yet.
In such case, gnome-remote-desktop currently hits an assertion, that
assumes that the amount of volume values is equal to 1, when the amount
of volume values is lower than 2.

To fix this assertion hit, assume that the volume of the stream is
muted, when the amount of volume values is 0.
As soon as the volume data is available, the audio output stream can
submit the audio samples to the pending frames queue.

Fixes: https://errors.ubuntu.com/problem/060bb232251f482381750964fdc92094bed5fe42

(cherry picked from commit ae648d73)