Hello community, here is the log from the commit of package vncmanager for openSUSE:Factory checked in at 2020-05-26 17:19:47 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/vncmanager (Old) and /work/SRC/openSUSE:Factory/.vncmanager.new.2738 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "vncmanager" Tue May 26 17:19:47 2020 rev:9 rq:807979 version:1.0.2 Changes: -------- --- /work/SRC/openSUSE:Factory/vncmanager/vncmanager.changes 2020-01-05 15:21:42.945577787 +0100 +++ /work/SRC/openSUSE:Factory/.vncmanager.new.2738/vncmanager.changes 2020-05-26 17:20:05.556074419 +0200 @@ -1,0 +2,20 @@ +Thu May 21 09:59:58 UTC 2020 - Petr Tesařík <[email protected]> + +- Adjust upstream project URL. + +------------------------------------------------------------------- +Thu May 14 15:28:21 UTC 2020 - Petr Tesařík <[email protected]> + +- u_Fix-TightCompressionControl-definition-for-big-endian.patch + * Fix tight compression decoder on big-endian systems + (bsc#1171344). + +------------------------------------------------------------------- +Wed May 13 03:52:02 UTC 2020 - Petr Tesařík <[email protected]> + +- u_Fix_tight_decoder_on_888_encodings.patch + * Fix tight decoder with 888 pixel encodings. (bsc#1169732) +- u_Fix-PixelFormat-ntoh-and-PixelFormat-hton.patch + * Fix PixelFormat::ntoh() and PixelFormat::hton(). (bsc#1169732) + +------------------------------------------------------------------- New: ---- u_Fix-PixelFormat-ntoh-and-PixelFormat-hton.patch u_Fix-TightCompressionControl-definition-for-big-endian.patch u_Fix_tight_decoder_on_888_encodings.patch ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ vncmanager.spec ++++++ --- /var/tmp/diff_new_pack.KZL4hk/_old 2020-05-26 17:20:06.984077489 +0200 +++ /var/tmp/diff_new_pack.KZL4hk/_new 2020-05-26 17:20:06.988077498 +0200 @@ -1,7 +1,7 @@ # # spec file for package vncmanager # -# Copyright (c) 2019 SUSE LLC +# Copyright (c) 2020 SUSE LLC # # All modifications and additions to the file contributed by third parties # remain the property of their copyright owners, unless otherwise agreed @@ -40,7 +40,7 @@ Requires: xorg-x11-Xvnc:/usr/lib/vnc/with-vnc-key.sh Recommends: vncmanager-controller -URL: https://github.com/michalsrb/vncmanager +URL: https://github.com/openSUSE/vncmanager BuildRoot: %{_tmppath}/%{name}-%{version}-build Summary: Session manager for VNC License: MIT @@ -53,6 +53,9 @@ Patch4: n_disable_mit_shm.patch Patch5: U_ControllerConnection-Split-iostream-into-istream-and.patch Patch6: n_vncmanager-add-target-to-service.patch +Patch7: u_Fix_tight_decoder_on_888_encodings.patch +Patch8: u_Fix-PixelFormat-ntoh-and-PixelFormat-hton.patch +Patch9: u_Fix-TightCompressionControl-definition-for-big-endian.patch %description Session manager for VNC. It listens on VNC port and spawns Xvnc processes for incoming clients. @@ -78,6 +81,9 @@ %patch4 -p1 %patch5 -p1 %patch6 -p1 +%patch7 -p1 +%patch8 -p1 +%patch9 -p1 %build %cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_VERBOSE_MAKEFILE=ON ++++++ u_Fix-PixelFormat-ntoh-and-PixelFormat-hton.patch ++++++ From: Petr Tesarik <[email protected]> Date: Tue, 12 May 2020 08:55:28 +0200 Subject: Fix PixelFormat::ntoh() and PixelFormat::hton() References: bsc#1169732 Upstream: merged Git-commit: 4626045b79011be2c0df8f8aa0e541ca9649f4ce The bigEndianFlag corresponds to the X server pixel byte order (defined as IMAGE_BYTE_ORDER in X.org sources). If it does not match client byte order, every pixel value must be byte-swapped. It's wrong to skip byte conversion of the red/gren/blue max values in struct PixelFormat itself when this flag is false. RFC6143 is very clear on this matter and explicitly states: > Note the -max values are always in big endian order. Signed-off-by: Petr Tesarik <[email protected]> --- rfb.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/rfb.h b/rfb.h index 949bed0..4c2e658 100644 --- a/rfb.h +++ b/rfb.h @@ -114,15 +114,15 @@ struct PixelFormat { uint8_t _padding[3] = { 0, 0, 0 }; void ntoh() { - if (bigEndianFlag) { - redMax = ntohs(redMax); - greenMax = ntohs(greenMax); - blueMax = ntohs(blueMax); - } + redMax = ntohs(redMax); + greenMax = ntohs(greenMax); + blueMax = ntohs(blueMax); } void hton() { - bigEndianFlag = (__BYTE_ORDER == __BIG_ENDIAN); + redMax = htons(redMax); + greenMax = htons(greenMax); + blueMax = htons(blueMax); } bool operator==(const PixelFormat &another) const { -- 2.16.4 ++++++ u_Fix-TightCompressionControl-definition-for-big-endian.patch ++++++ From: Petr Tesarik <[email protected]> Date: Thu, 14 May 2020 17:23:21 +0200 Subject: Fix TightCompressionControl definition for big-endian References: bsc#1171344 Upstream: merged Git-commit: b487e58a4f8d0b879d34cb9be18a292c753daf3e Bitfields are allocated from the most significant bit down to the least significant bit on big-endian systems, so the declaration order must be reversed to match on-wire format. Signed-off-by: Petr Tesarik <[email protected]> --- rfb.h | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/rfb.h +++ b/rfb.h @@ -523,13 +523,21 @@ struct VeNCryptPlainMessage { }; struct TightCompressionControl { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned rest : 4; + + unsigned resetStream3 : 1; + unsigned resetStream2 : 1; + unsigned resetStream1 : 1; + unsigned resetStream0 : 1; +#else unsigned resetStream0 : 1; unsigned resetStream1 : 1; unsigned resetStream2 : 1; unsigned resetStream3 : 1; unsigned rest : 4; - +#endif // __BYTE_ORDER int useStream() const { return rest & 0x3; } ++++++ u_Fix_tight_decoder_on_888_encodings.patch ++++++ From: Petr Tesarik <[email protected]> Subject: Fix calculation of raw 888 pixel data length in Tight encoding References: bsc#1169732 Upstream: merged Git-commit: e3c7982e56183a1f8b1f65cae3ee7b080c48e17d When raw pixel data is sent and pixels are encoded as three 8-bit true colour values aligned on byte boundaries, the Tight encoding always uses three bytes per pixel. Signed-off-by: Petr Tesarik <[email protected]> --- VncTunnel.cpp | 4 +++- rfb.h | 13 +++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) --- a/VncTunnel.cpp +++ b/VncTunnel.cpp @@ -623,7 +623,9 @@ void VncTunnel::processFramebufferUpdate } else { bpp = 8; } - } + } else if (m_pixelFormat.is888()) { + bpp = 24; + } std::size_t dataSize = (rectangle.width * bpp + 7) / 8 * rectangle.height; if (dataSize < TightMinSizeToCompress) { --- a/rfb.h +++ b/rfb.h @@ -147,6 +147,19 @@ struct PixelFormat { // Validating only things that could hurt vncmanager. If there are some other wrong values, underlying VNC server should complain. return bitsPerPixel == 8 || bitsPerPixel == 16 || bitsPerPixel == 24 || bitsPerPixel == 32; } + + bool is888() const { + return + trueColourFlag && + bitsPerPixel == 32 && + depth == 24 && + redMax == 255 && + greenMax == 255 && + blueMax == 255 && + (redShift & 0x07) == 0 && + (greenShift & 0x07) == 0 && + (blueShift & 0x07) == 0; + } }; struct ServerInitMessage {
