** Description changed: 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). + * 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 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. + * 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) + * 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). + * 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 + * now start the server with: vncserver - * run the client: xtigervncviewer <server-IP>:1 + * run the client: xtigervncviewer <server-IP>:1 - * detailed instructions how to reproduce the bug + * 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 + * 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, + 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, + * 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. + * 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. + * 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 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 + * 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 reported issue is a regression that got (upstream) introduced + into 1.10. - * The patch is upstream accepted with v1.11.90 since Aug 28, 2020, + * It is fixed be code that is known to work and that was tested on different + platforms. - * hence it's highly like no longer needed once Debian/Ubuntu pick up - the next upstream version, since it's fixed with > 1.10. + * The patch is upstream accepted with v1.11.90 since Aug 28, 2020, - * Patched tigervnc versions are available for impish and hirsute via the PPA: - https://launchpad.net/~fheimes/+archive/ubuntu/lp1929790 + * hence it's highly like no longer needed once Debian/Ubuntu pick up + the next upstream version, since it's fixed with > 1.10. - * And the issue was in detail discussed upstream at: - https://github.com/TigerVNC/tigervnc/issues/1073 - https://github.com/TigerVNC/tigervnc/pull/1084 + * 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
** Description changed: 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, - server and client, on amd64 only. + * 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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929790 Title: Request to backport fix for endianness issue in TigerVNC vncviewer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
