Comment 0 for bug 1929790

---Problem Description---
TigerVNC 1.11.0 contains a regression that causes vncviewer to display
incorrect colors when vncviewer and X11 server use different endianness (e.g.,
when using X11 forwarding via SSH between an x86-64 desktop and a Linux system
on s390x). The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073 and fixed in github pull
request https://github.com/TigerVNC/tigervnc/pull/1084

The regression caused vncviewer to always use the system byte order for pixel
values instead of the byte order required by the X11 display. With the fix,
vncviewer queries the X11 display for the required byte order.

As of now, the fix has not made it into a release yet. Please consider
backporting the fix (upstream commit 7ab92639848). I confirmed that this commit
cleanly applies on top of release 1.11.0 and fixes the regression.

---uname output---
Linux s390x

Machine Type = x15

---Debugger---
A debugger is not configured

---Steps to Reproduce---
 See also https://github.com/TigerVNC/tigervnc/issues/1252

- From a Linux x86 system, connect to a Linux system on s390x via SSH with X forwarding
- Start a Xvnc session on that Linux system

tigervncserver :0 -geometry 800x600 -depth 32

- Start vncviewer on the same Linux system

xtigervncviewer :0

- On vncviewer's window on your origin X session, observe incorrect colors.
- Optionally, start X11 programs such as xlogo, xclock, or xeyes to make the problem obvious
- Optionally, connect to the vnc session directly (i.e., with a vnc client on the origin system) to compare

Userspace tool common name: vncviewer

The userspace tool has the following bit modes: 64-bit

Userspace rpm: tigervnc-viewer

Userspace tool obtained from project website: na