Bug 1886147

Summary: Wrong colors when using color depths of 16 on s390x
Product: Red Hat Enterprise Linux 8 Reporter: Karol Herbst <kherbst>
Component: mesaAssignee: Karol Herbst <kherbst>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact: Marek Suchánek <msuchane>
Priority: unspecified    
Version: 8.3CC: lmanasko
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: s390x   
OS: Unspecified   
Whiteboard:
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.
 Story Points: ---
Clone Of:
: 1973824 (view as bug list) Environment:
Last Closed: 2022-04-07 07:27:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshot none

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.