Hello community,
here is the log from the commit of package vncmanager for openSUSE:Leap:15.2
checked in at 2020-05-26 18:33:07
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Leap:15.2/vncmanager (Old)
and /work/SRC/openSUSE:Leap:15.2/.vncmanager.new.2738 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "vncmanager"
Tue May 26 18:33:07 2020 rev:17 rq:809038 version:1.0.2
Changes:
--------
--- /work/SRC/openSUSE:Leap:15.2/vncmanager/vncmanager.changes 2020-01-15
16:28:21.232751097 +0100
+++ /work/SRC/openSUSE:Leap:15.2/.vncmanager.new.2738/vncmanager.changes
2020-05-26 18:33:11.769682711 +0200
@@ -1,0 +2,15 @@
+Thu May 14 15:28:21 UTC 2020 - Petr Tesařík <ptesa...@suse.com>
+
+- 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 <ptesa...@suse.com>
+
+- 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.Lefi3x/_old 2020-05-26 18:33:12.197683647 +0200
+++ /var/tmp/diff_new_pack.Lefi3x/_new 2020-05-26 18:33:12.201683655 +0200
@@ -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 <ptesa...@suse.com>
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 <ptesa...@suse.com>
---
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 <ptesa...@suse.com>
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 <ptesa...@suse.com>
---
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 <ptesa...@suse.com>
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 <ptesa...@suse.com>
---
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 {
