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.
Bug 1886147 - Wrong colors when using color depths of 16 on s390x
Summary: Wrong colors when using color depths of 16 on s390x
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: mesa
Version: 8.3
Hardware: s390x
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Karol Herbst
QA Contact: Desktop QE
Marek Suchánek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-07 18:39 UTC by Karol Herbst
Modified: 2022-04-07 07:27 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.VNC Viewer displays wrong colors with the 16-bit color depth on IBM Z The VNC Viewer application displays wrong colors when you connect to a VNC session on an IBM Z server with the 16-bit color depth. To work around the problem, set the 24-bit color depth on the VNC server. With the `Xvnc` server, replace the `-depth 16` option with `-depth 24` in the `Xvnc` configuration. As a result, VNC clients display the correct colors but use more network bandwidth with the server.
Clone Of:
: 1973824 (view as bug list)
Environment:
Last Closed: 2022-04-07 07:27:27 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Screenshot (94.70 KB, image/png)
2020-10-08 12:09 UTC, Karol Herbst 		no flags Details
View All

Description Karol Herbst 2020-10-07 18:39:32 UTC 
Description of problem:
Colors seem to be wrong when using a depth of 16 with tiger-vnc. 24 works fine.

How reproducible:
Always

Steps to Reproduce:
1. Follow these instructions to set up a VNC server: https://access.redhat.com/solutions/2516
2. Connect to VNC

Actual results:
Wrong colors seen in the gdm login

Expected results:
Correct colors :)
Comment 1 Jan Grulich 2020-10-08 05:49:54 UTC 
What tigervnc version? Can you share a screenshot of the wrong colors?
Comment 2 Jan Grulich 2020-10-08 05:54:16 UTC 
(In reply to Jan Grulich from comment #1)
> What tigervnc version? Can you share a screenshot of the wrong colors?

Please tell me your tigervnc versions for both the server and the client.
Comment 3 Karol Herbst 2020-10-08 12:08:38 UTC 
(In reply to Jan Grulich from comment #2)
> (In reply to Jan Grulich from comment #1)
> > What tigervnc version? Can you share a screenshot of the wrong colors?
> 
> Please tell me your tigervnc versions for both the server and the client.

ohh, this was with the latest RHEL8.3 image, so tigervnc-1.10.1-7.el8.s390x.
Comment 4 Karol Herbst 2020-10-08 12:09:30 UTC 
Created attachment 1719932 [details]
Screenshot
Comment 5 Karol Herbst 2020-10-08 12:10:28 UTC 
I am sure this is some big endian issue somewhere. At this point I just have no idea where exactly :)
Comment 6 Jan Grulich 2020-10-08 15:56:09 UTC 
There was a fix for this in Tigervnc 1.10.0, which seems to fix it for some people, however some people reports this bug started to appear.

Upstream bug: https://github.com/TigerVNC/tigervnc/issues/738
Potential fix (not merged upstream): https://github.com/TigerVNC/tigervnc/pull/1084
Comment 7 Karol Herbst 2020-10-09 09:11:03 UTC 
(In reply to Jan Grulich from comment #6)
> There was a fix for this in Tigervnc 1.10.0, which seems to fix it for some
> people, however some people reports this bug started to appear.
> 
> Upstream bug: https://github.com/TigerVNC/tigervnc/issues/738
> Potential fix (not merged upstream):
> https://github.com/TigerVNC/tigervnc/pull/1084

mhh, doesn't seem like that applying the patch from the pull requests helps at all.

I did a bit more digging and I think this might actually be a gnome-shell or just a mesa bug. Killing gnome-shell made colors to appear normal for applications. Some rendering was still incorrect though.
Comment 8 Marek Suchánek 2020-10-29 17:11:09 UTC 
Hi Karol,
Thanks for the draft doc text. I've edited it to our release note format. Could you please review the new doc text?

I'm not sure what to do about the KBase linked from your draft. Was that just a note or do you want me to edit the article, too? A release note saying that an article has bugs probably isn't the most discoverable way to present the information.
Comment 9 Karol Herbst 2020-10-29 17:17:02 UTC 
(In reply to Marek Suchánek from comment #8)
> Hi Karol,
> Thanks for the draft doc text. I've edited it to our release note format.
> Could you please review the new doc text?
> 
> I'm not sure what to do about the KBase linked from your draft. Was that
> just a note or do you want me to edit the article, too? A release note
> saying that an article has bugs probably isn't the most discoverable way to
> present the information.

yeah, editing the KBase article was what I intended with that. There is already a similar note: "For RHEL 7: If using Gnome, you should be using only 24bit pixel depth, otherwise you may experience graphical artifacts and other odd rendering behavior." Which already tells users to apply the same workaround for other known issues.

Anyway, the new doc texts sounds good. Thanks!
Comment 10 Marek Suchánek 2020-10-30 12:51:30 UTC 
Thanks, Karol. I'm going to add a short note in the KBase about the issue.
Comment 11 Karol Herbst 2020-10-30 13:23:26 UTC 
already working on the bug, so should probably just assign to myself anyway.
Comment 12 Marek Suchánek 2020-10-30 13:48:45 UTC 
I've edited the KBase to add the warning about color depth on RHEL 8, and while I was at it, I also polished the style and formatting a bit:

https://access.redhat.com/solutions/2516
Comment 17 RHEL Program Management 2022-04-07 07:27:27 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.