src/grd-session-vnc.c | 5 3 + 2 - 0 !
src/grd-session-vnc.h | 3 2 + 1 - 0 !
src/grd-vnc-pipewire-stream.c | 5 3 + 2 - 0 !
3 files changed, 8 insertions(+), 5 deletions(-)

 vnc: copy pixels using the right destination stride

We're copying the pixels in a separate thread managed by PipeWire, and
in this thread, accessing the VNC framebuffer dimension and stride is
racy. Instead of fetching the dimension directly, pass the expected
width and get the stride it will eventually have.

Already before this patch, when the copied pixel end up on the main
thread and the dimension still doesn't match up, the frame will be
dropped.

tests/vnc-test-runner.sh | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 tests: use a more interoperable path to bash

On non-merged-/usr systems, bash is traditionally in /bin.
On merged-/usr systems, /bin and /usr/bin are synonymous so it doesn't
matter which one we use.

src/grd-session-vnc.c | 7 7 + 0 - 0 !
src/grd-session-vnc.h | 2 2 + 0 - 0 !
src/grd-vnc-pipewire-stream.c | 8 8 + 0 - 0 !
3 files changed, 17 insertions(+)

 vnc: drop frames if client is gone

Frames from PipeWire are posted asynchronously from a I/O thread to the
main thread where they are turned into VNC frame updates and cursor
movements. On the other hand, sessions are closed asynchronously when
the VNC client disappears. If a frame ended up on the main thread after
a client disappeared but before the session and stream was closed, we'd
try to turn the new frames into VNC updates without a client being
available, causing use after free.

Fix this by dropping frames that happens during this time frame.

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