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.

Bug 712969

Summary:	color depth does not get reverted back to 32-bit after WAN option used
Product:	Red Hat Enterprise Linux 6	Reporter:	Swapna Krishnan <skrishna>
Component:	spice-client	Assignee:	Uri Lublin <uril>
Status:	CLOSED WONTFIX	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	low	Docs Contact:
Priority:	low
Version:	6.2	CC:	acathrow, cfergeau, cmeadors, dblechte, mkenneth, mkrcmari, syeghiay
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-01 12:37:22 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Swapna Krishnan 2011-06-13 18:35:21 UTC

Description of problem:
After connecting to a guest with WAN option --color-depth 16, the next time you connect to it, the 16-bit color depth persists and is not removed. 

Version-Release number of selected component (if applicable):
spice-client-0.8.0-2.el6.x86_64
spice-server-0.8.0-1.el6.x86_64
qemu-kvm-0.12.1.2-2.160.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1. Connect to a windows guest with spicec with --color-depth 16 option
"spicec -h localhost -p 5903 --color-depth 16"
2. Notice the 16-bit color difference
3. Disconnect from the guest
4. Connect to the windows guest again without color-depth option
"spicec -h localhost -p 5903"
5. The 16-bit color depth persists
  
Actual results:
16-bit color depth persists

Expected results:
32-bit color depth (guest's default color depth)

Additional info:

Comment 2 Uri Lublin 2011-06-14 08:20:17 UTC

I'm not sure it's a bug.
One can start spicec with "--color-depth 32"; Or change the color-depth on the guest.

Comment 3 Swapna Krishnan 2011-06-14 14:22:57 UTC

(In reply to comment #2)
> I'm not sure it's a bug.
> One can start spicec with "--color-depth 32"; Or change the color-depth on the
> guest.

What you suggest are workarounds to get it back to color-depth 32. When --disable-effects wallpaper is used, it doesn't persist. The next time you connect, the wallpaper shows back up. 

Thanks,
- Swapna

Comment 4 Christophe Fergeau 2011-07-07 08:29:36 UTC

The behaviour is indeed inconsistant. Not unconditionally setting the color depth makes sense to me because we can't know from the client whether the 16bpp mode in the guest was set in reaction to an agent request or if it's the user that set it to 16bpp for some reason. If it's a user setting, changing it unconditionally is a bit rude imo.
However, we are doing precisely that for eg user font settings, which is a more subtle change, but could still override something the user did himself, so I'm a bit torn on which way to go forward :)

Comment 8 Christophe Fergeau 2012-02-02 10:57:32 UTC

Thinking about it some more, we could probably handle this partially in the agent: the windows agent could remember the color depth when it starts, and restore it when a client connects and doesn't send a VD_AGENT_DISPLAY_CONFIG_FLAG_SET_COLOR_DEPTH message.

Comment 9 David Blechter 2012-04-18 14:37:00 UTC

moving to 6.4.
In rhevm 3.1 these options will not be used by default, but should be set by user portal. see https://bugzilla.redhat.com/show_bug.cgi?id=747313

Comment 11 RHEL Program Management 2012-07-10 05:47:53 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 12 RHEL Program Management 2012-07-11 01:59:07 UTC

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 13 Marian Krcmarik 2012-08-01 12:37:22 UTC

Closing as WONTFIX, spice-client was replaced by virt-viewer which is now supported client. This bug was not reproducible with virt-viewer, If you can reproduce with remote-viewer, please file a bug for virt-viewer. Thanks.