Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
+++ This bug was initially created as a clone of Bug #1306576 +++
Description of problem:
Weird colours of remote desktop via freerdp on ppc64 and s390x architectures.
Version-Release number of selected component (if applicable):
freerdp-1.0.2-4.el6.(ppc64|s390x)
How reproducible:
always
Steps to Reproduce:
1. xfreerdp $WindowsIP
Actual results:
colours of remote desktop are deformed, maybe due to different endianness
Expected results:
colours of remote desktop are normal
Additional info:
This is arch specific bug, appears on ppc64 and s390x; x86_64 and i386 are fine.
--- Additional comment from RHEL Product and Program Management on 2016-02-11 11:41:21 CET ---
Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
--- Additional comment from Tomas Hudziec on 2016-02-11 11:41 CET ---
--- Additional comment from Tomas Pelka on 2016-02-12 08:00:54 CET ---
Endianess issue?
--- Additional comment from Oded Gabbay on 2016-02-12 08:13:45 CET ---
I'm missing some info about the setup.
What is the client and what is the remote machine ? Are they both ppc64 ?
Please describe the steps you did both on the client and the remote machine (steps to setup the remote display server)
--- Additional comment from Tomas Pelka on 2016-02-12 08:36:08 CET ---
Tomas was connected from x86_64 to ppc4/s390x via VNC and in VNC session freerdp was executed.
--- Additional comment from Ondrej Holy on 2016-02-12 10:28:33 CET ---
I see weird colors with 8/16/24 color depth also. 32bit color depth (-a 32) seems to work correctly...
Yes probably endianess issue.
I used ssh -X to connect from x86_64 to ppc64 machine and see this issue when accessing Windows 7 machine over rdp.
--- Additional comment from Ondrej Holy on 2016-02-12 16:08:47 CET ---
I hoped it is fixed upstream, but it seems it is even worse. I tried several newer versions and the result is almost same, or it exits with decryption error, or it crashes with segfaults instead.
Several upstream reports exists in regards to color/endianness problems. Probably the most relevant one is following:
https://github.com/FreeRDP/FreeRDP/issues/2520
I proposed several upstream patches though they are not merged yet and I cooperate with upstream in order to fix FreeRDP under big endian. We decided to defer this for 7.4 due to its complexity. It may be fixed also as a part of the rebase, Bug 1291254.
Unfortunately, the color-related fixes were not merged. I discussed this with upstream several times, but my suggestions were not taken into account. I have to propose new patches on top of recent color-overhaul. But I am afraid that fixing this bug would require rebase anyway.
Big endian fixes for colors have been merged upstream recently:
https://github.com/FreeRDP/FreeRDP/pull/4135
Although the handling in master is totally different, the approach which was finally used upstream should not be so hard to use in downstream also...
I tested the fix with Windows 7 server with all combinations of -a 8/16/24/32, --gdi sw/hw, on X server with depth 16/24/32 and LE/BE systems. The colors on BE systems should be the same as on LE with that fix. It doesn't mean that the colors are 100% correct. There are some problems with -a 8 (Bug 1357558) and also with X server depth 32 (https://github.com/FreeRDP/FreeRDP/issues/4134).
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:0724