Bug 1973824

Summary: Wrong colors when using color depths of 16 on s390x
Product: Red Hat Enterprise Linux 9 Reporter: Ray Strode [halfline] <rstrode>
Component: mesaAssignee: Karol Herbst <kherbst>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.0CC: csoriano, desktop-qa-list, kherbst, lmanasko, msuchane, tpelka
Target Milestone: betaFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: s390x   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1886147 Environment:
Last Closed: 2022-12-18 07:27:42 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:

Description Ray Strode [halfline] 2021-06-18 19:33:56 UTC
+++ This bug was initially created as a clone of Bug #1886147 +++

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

--- Additional comment from Jan Grulich on 2020-10-08 01:49:54 EDT ---

What tigervnc version? Can you share a screenshot of the wrong colors?

--- Additional comment from Jan Grulich on 2020-10-08 01:54:16 EDT ---

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

--- Additional comment from Karol Herbst on 2020-10-08 08:08:38 EDT ---

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

--- Additional comment from Karol Herbst on 2020-10-08 08:09:30 EDT ---



--- Additional comment from Karol Herbst on 2020-10-08 08:10:28 EDT ---

I am sure this is some big endian issue somewhere. At this point I just have no idea where exactly :)

--- Additional comment from Jan Grulich on 2020-10-08 11:56:09 EDT ---

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

--- Additional comment from Karol Herbst on 2020-10-09 05:11:03 EDT ---

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

--- Additional comment from Marek Suchánek on 2020-10-29 13:11:09 EDT ---

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.

--- Additional comment from Karol Herbst on 2020-10-29 13:17:02 EDT ---

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

--- Additional comment from Marek Suchánek on 2020-10-30 08:51:30 EDT ---

Thanks, Karol. I'm going to add a short note in the KBase about the issue.

--- Additional comment from Karol Herbst on 2020-10-30 09:23:26 EDT ---

already working on the bug, so should probably just assign to myself anyway.

--- Additional comment from Marek Suchánek on 2020-10-30 09:48:45 EDT ---

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

--- Additional comment from Marek Suchánek on 2020-10-30 09:54:49 EDT ---

By the way, I've recently added product documentation on remote desktop access:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/accessing-the-desktop-remotely_using-the-desktop-environment-in-rhel-8

Currently, it covers accessing application windows through SSH and opening the remote desktop using the GNOME interface. With 8.3 GA, I'll also add a configuration using TigerVNC:

https://cee-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/CCS/job/ccs-mr-preview/21687/artifact/enterprise/titles/configuring-and-maintaining/using-the-desktop-environment-in-rhel-8/preview/index.html#remotely-accessing-the-desktop-as-multiple-users_accessing-the-desktop-remotely

Should I look into integrating the KBase and the new documentation somehow? For now, I've linked the documentation from the end of the KBase.

--- Additional comment from Karol Herbst on 2020-10-30 11:19:01 EDT ---

(In reply to Marek Suchánek from comment #13)
> By the way, I've recently added product documentation on remote desktop
> access:
> 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/
> html/using_the_desktop_environment_in_rhel_8/accessing-the-desktop-
> remotely_using-the-desktop-environment-in-rhel-8
> 
> Currently, it covers accessing application windows through SSH and opening
> the remote desktop using the GNOME interface. With 8.3 GA, I'll also add a
> configuration using TigerVNC:
> 
> https://cee-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/CCS/job/ccs-mr-
> preview/21687/artifact/enterprise/titles/configuring-and-maintaining/using-
> the-desktop-environment-in-rhel-8/preview/index.html#remotely-accessing-the-
> desktop-as-multiple-users_accessing-the-desktop-remotely
> 
> Should I look into integrating the KBase and the new documentation somehow?
> For now, I've linked the documentation from the end of the KBase.

honestly I am not sure what is the proper/preferred way of setting it up. I just used the KBase one as it was quite straightforward and got me what I needed for testing/development.

--- Additional comment from Marek Suchánek on 2020-10-30 11:26:02 EDT ---

(In reply to Karol Herbst from comment #14)
> (In reply to Marek Suchánek from comment #13)
> > 
> > Should I look into integrating the KBase and the new documentation somehow?
> > For now, I've linked the documentation from the end of the KBase.
> 
> honestly I am not sure what is the proper/preferred way of setting it up. I
> just used the KBase one as it was quite straightforward and got me what I
> needed for testing/development.

Sure, no problem. I think it's safe to leave the documentation as it is now.

Comment 3 RHEL Program Management 2022-12-18 07:27:42 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.