Compare revisions

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.

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

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.

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.

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

WTSOpenServerA() returns INVALID_HANDLE_VALUE, which is not NULL, when
the creation of the virtual channel manager fails.
Since NULL is an invalid value here too, check against that value too.
This is what the sample server implementations in FreeRDP also do.

Fixes: https://errors.ubuntu.com/problem/4b04e96f4f5f92ed74e814927dadeab1fba5fbdd


(cherry picked from commit dbfc75af)

Commit 51e94ba8 fixed an issue, where
the ping source was attempted to be created, when it already existed,
as gnome-remote-desktop previously assumed, that every update of the
RTT consumers and RTT consumer necessities will always change the ping
source.
Commit 351893fa accidentally broke that
behaviour by always assuming again, that updating the ping source will
always change the ping source itself.
However, this time, the situation is different. Since the former commit
added an assertion to not create a ping source again, when it already
exists, gnome-remote-desktop crashes, due to invalid behaviour (which
also made this issue discoverable).

Fix this situation again by checking again, whether an update of the
ping source is needed.
Due to the latter commit, the initial ping source should be created, as
that commit introduced another state for the ping interval recognizing
it to be non-existent.

Fixes: https://errors.ubuntu.com/problem/4d8b5efdf8ade96d4019c6b7cb92649f660e9fe9


(cherry picked from commit 3c692112)

FreeRDP 3.x checks the handle against NULL and the invalid handle value
before clearing it.
FreeRDP 2.x only checks against NULL, so add an additional check to
only attempt to clear the VCM, when the handle is valid.

This should give some insight on why the respective NVENC call failed.

This should give some insight on why the respective CUDA call failed.

When mutter becomes the new shared clipboard owner, it can still
request for client content data, even if the remote desktop client is
not the shared clipboard owner anymore.
This can currently result in a crash, when using the VNC backend, e.g.
when mutter emits the selection-owner-changed signal, the VNC backend
asks for the mime type content, due to having a text mime type in the
new mime type list, but before getting that text, mutter asks for the
text mime type of the VNC client.

To fix this crash, always clear all mime type tables for mime types
advertised by the remote desktop client, when updating the clipboard of
the remote desktop client.

https://errors.ubuntu.com/problem/777e9e3b662530a64c542b79243c1d20ad428689

When destroying a PipeWire stream, gnome-remote-desktop needs to
ensure, that all dequeued buffers are queued again.
And while doing that, no new buffers should be dequeued.
In this situation, gnome-remote-desktop currently sets a helper
variable and flushes the PipeWire stream.
Flushing a PipeWire stream appears to ensure, that the PipeWire data
thread completes its current call, if there is one.

However, it has a downside: All dequeued buffers are queued again.
This also includes buffers, which are currently processed by the EGL
thread.
When trying to queue these buffers again and the flush call ended
already, gnome-remote-desktop can crash.

To fix this situation, simply set the PipeWire stream inactive.
This will result into the PipeWire data thread to be stopped, while it
first completes its current call, if there is one, but also in a state,
where all current dequeued buffers can still be queued.

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

When destroying a PipeWire stream, gnome-remote-desktop needs to
ensure, that all dequeued buffers are queued again.
And while doing that, no new buffers should be dequeued.
In this situation, gnome-remote-desktop currently sets a helper
variable and flushes the PipeWire stream.
Flushing a PipeWire stream appears to ensure, that the PipeWire data
thread completes its current call, if there is one.

However, it has a downside: All dequeued buffers are queued again.
This also includes buffers, which are currently processed by the EGL
thread.
When trying to queue these buffers again and the flush call ended
already, gnome-remote-desktop can crash.

To fix this situation, simply set the PipeWire stream inactive.
This will result into the PipeWire data thread to be stopped, while it
first completes its current call, if there is one, but also in a state,
where all current dequeued buffers can still be queued.

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

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

Update to upstream version '42.7'
with Debian dir c09aed242ef63920bc1ff2dccc6598837a2ce5d7