[Bug 1929790] tigervnc debdiff (hirsute)

[bugproxy]

Default Comment by Bridge

** Attachment added: "tigervnc debdiff (hirsute)"
   https://bugs.launchpad.net/bugs/1929790/+attachment/5526555/+files/debdiff_lp1929790_tigervnc_hirsute.patch

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1929790

Title:
  Request to backport fix for endianness issue in TigerVNC vncviewer

Status in Ubuntu on IBM z Systems:
  In Progress
Status in tigervnc package in Ubuntu:
  In Progress
Status in tigervnc source package in Hirsute:
  In Progress
Status in tigervnc source package in Impish:
  In Progress

Bug description:
  SRU Justification:
  ==================

  [Impact]

   * TigerVNC 1.11.0 contains a (pixel order) 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 amd64 desktop
      and a Linux 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 issue got fixed by a respin of the
     ARGB runtime XImage byteorder selection.

  [Test Plan]

   * Setup two systems with different endianness, ideally:
     a (little endian) Ubuntu (Desktop) system (amd64) and
     a (big endian) Ubuntu (Server) system (s390x)

   * Install tigervnc-standalone-server and tigervnc-xorg-extension on the s390x
     and tigervnc-vieweron the amd64 system (incl. all dependencies).

   * now start the server with: vncserver

   * run the client: xtigervncviewer <server-IP>:1

   * detailed instructions how to reproduce the bug

   * The issue results in the display of wrong colors, 'similar' to:
     https://github.com/TigerVNC/tigervnc/issues/738

   * Another (regression) test will be using both,
     tigervnc server and client, on amd64 only.

  [Where problems could occur]

   * An onerousness patch would maybe not solve the endian problem
     and wrong colors (maybe different) still exist,

   * or in worst case it may have an impact on system combinations
     that use the same endianness.

   * The latter one is very unlikely, since there is only line 126
     that enters to code that handles the endianness.

   * And the fix here is a respin of the original runtime ARGB
     selection pull request, hence one that worked already before.

   * And the changes are very limited and only cover 3 lines
     of a single if/else statement in vncviewer/Surface_X11.cxx

  [Other Info]

   * The reported issue is a regression that got (upstream) introduced
  into 1.10.

   * It is fixed be code that is known to work and that was tested on different
     platforms.

   * The patch is upstream accepted with v1.11.90 since Aug 28, 2020,

   * hence it's highly like no longer needed once Debian/Ubuntu pick up
     the next upstream version, since it's fixed with > 1.10.

   * Patched tigervnc versions are available for impish and hirsute via the PPA:
     https://launchpad.net/~fheimes/+archive/ubuntu/lp1929790

   * And the issue was in detail discussed upstream at:
     https://github.com/TigerVNC/tigervnc/issues/1073
     https://github.com/TigerVNC/tigervnc/pull/1084

  __________

  ---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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929790/+subscriptions