Commits on Source (35)
-
Zurab Kargareteli authoredc5cf87c2
-
Pascal Nowack authored
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
3bdff0e0 -
Pascal Nowack authored
This condition should here always be true.
44d90699 -
Pascal Nowack authored
It messes with the frame controller, so get rid of the clamp behaviour.
171cf32b -
Pascal Nowack authored
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.
e11571d7 -
Pascal Nowack authored
This makes tracking the lifetime of a GFX surface easier.
ce712f02 -
Pascal Nowack authored
The NVENC session was just created here and is not any more in the process of creation. So, fix that message accordingly.
38ccd563 -
Pascal Nowack authored
Don't assume that the client sent a proper file list. Always sanitize the data.
0c375ea7 -
Pascal Nowack authored
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.
a42ece38 -
Pascal Nowack authored
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.
6b6f5652 -
Pascal Nowack authored
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
4774bb1d -
Sveinn í Felli authoredae648d73
-
Pascal Nowack authored
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)
9dd1b05c -
Pascal Nowack authored
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)
e12065ae -
Jonas Ådahl authored5a68e20e
-
Pascal Nowack authored959e7e8c
-
Pascal Nowack authored
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.
50889286 -
Pascal Nowack authoredee661291
-
Pascal Nowack authoredf0f69029
-
Pascal Nowack authored
This should give some insight on why the respective NVENC call failed.
a0f88c99 -
Pascal Nowack authored
This should give some insight on why the respective CUDA call failed.
94af8aa7 -
Pascal Nowack authored
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
ac891f1b -
Pascal Nowack authored
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
aec172f0 -
Pascal Nowack authored
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
feacf837 -
Jonas Ådahl authoredeb680b64
-
Pascal Nowack authored4b702ee0
-
Pascal Nowack authored
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.
5fe6cf01 -
Pascal Nowack authored
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.
013e03da -
Pascal Nowack authored
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
8dfbac22 -
Jonas Ådahl authoreda69242c5
-
Jeremy Bicha authoreddb139e91
-
Jeremy Bicha authored67fb97f7
-
Jeremy Bicha authored
Update to upstream version '42.7' with Debian dir c09aed242ef63920bc1ff2dccc6598837a2ce5d7
746b60fa -
Jeremy Bicha authorede6fd3cd9
-
Jeremy Bicha authoreddf775ea5