659505 – can not connect to vino VNC server (setPF: not 8, 16 OR 32 BPP)

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 659505 - can not connect to vino VNC server (setPF: not 8, 16 OR 32 BPP)

Summary: can not connect to vino VNC server (setPF: not 8, 16 OR 32 BPP)

Keywords:
Status:	CLOSED WONTFIX
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	vino
Sub Component:
Version:	6.0
Hardware:	x86_64
OS:	Linux
Priority:	low
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Ondrej Holy
QA Contact:	Desktop QE
Docs Contact:
URL:
Whiteboard:
Depends On:	527758
Blocks:	1002711
TreeView+	depends on / blocked

Reported:	2010-12-02 22:32 UTC by Steve Bonneville
Modified:	2018-12-09 16:42 UTC (History)
CC List:	9 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:	527758
Environment:
Last Closed:	2015-09-18 13:53:03 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Steve Bonneville 2010-12-02 22:32:19 UTC

This bug appears to also affect RHEL 6.

+++ This bug was initially created as a clone of Bug #527758 +++

Description of problem:
I can not connect to the vino VNC server using the TigerVNC client from Fedora 11.

Version-Release number of selected component (if applicable):
vino-2.28.0-3.fc12.x86_64 

How reproducible:
Every time

Steps to Reproduce:
1. Login to GNOME.
2. Activate the remote desktop.
3. Stop the firewall if necessarily.
3. Connect to the VNC server from another computer.
  
Actual results:
The VNC client gives this error "setPF: not 8, 16 OR 32 BPP".

Expected results:
No errors.

Additional info:
I'm using tigervnc-0.0.91-0.12.fc11.x86_64 as a client:
TigerVNC Viewer for X version 0.0.91 - built Aug 14 2009 09:54:10
Copyright (C) 2002-2005 RealVNC Ltd.
Copyright (C) 2000-2006 TightVNC Group
Copyright (C) 2004-2009 Peter Astrand for Cendio AB
See http://www.tigervnc.org for information on TigerVNC.

Wed Oct  7 18:39:52 2009
 CConn:       connected to host 192.168.122.100 port 5900
 CConnection: Server supports RFB protocol version 3.7
 CConnection: Using RFB protocol version 3.7
 main:        setPF: not 8, 16 or 32 bpp?

--- Additional comment from fedora-triage-list on 2009-11-16 08:22:38 EST ---


This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from cristian.ciupitu on 2009-11-16 15:40:11 EST ---

Just in case this matters, Fedora 12 (beta) was running on a KVM virtual machine under Fedora 11 (qemu-kvm-0.10.6-9.fc11.x86_64).

--- Additional comment from andri on 2009-11-17 05:19:13 EST ---

No go with Vinagre's client either.

--- Additional comment from fukawi2+fedora on 2010-06-15 19:18:46 EDT ---

I get the same issue with Fedora 12, and Ubuntu 9.10, under a Xen HVM so it perhaps is an upstream issue?

--- Additional comment from jamundso on 2010-09-02 00:03:38 EDT ---

My assumption is that the Assigned To here is either,
1. Deceased, or
2. Not interested.

--- Additional comment from jamundso on 2010-09-02 13:36:33 EDT ---

Or,
3. Assigned To is busy, and has other priorities!

My apologies for the earlier remark - I have bugs with no activity for months and assumed otherwise. But I see updates by sandmann as recently as 2010-08-24 09:11:27 EDT.

I'll try to help by marking duplicates. Sorry for the noise.

--- Additional comment from fedora-triage-list on 2010-11-04 05:36:07 EDT ---


This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 2 Steve Bonneville 2010-12-03 04:35:03 UTC

RHEL 6 package affected is vino-2.28.1-3.el6.x86_64.
Client used was tigervnc-1.0.90-0.10.20100115svn3945.el6.x86_64.

So our own VNC client isn't working with our "easy-to-use" vino VNC server in GNOME.  The machine affected was using a 24-bit color depth by default in X.

Comment 3 RHEL Program Management 2011-01-07 15:41:05 UTC

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 4 Jesus M. Rodriguez 2011-01-21 22:49:42 UTC

I've got the same problem using tigervnc-1.0.90-0.15.20100420svn4030.fc13.x86_64

Comment 5 Pan Wang 2011-04-18 15:32:10 UTC

 VNC  viewers  cannot handle 24bpp (e.g."main: setPF: not 8, 16 or 32 bpp?"). the default vncserver corlor depth is 24bpp , so need config   /etc/X11/xorg.conf  , set depth 16

Comment 6 Pan Wang 2011-04-18 15:43:02 UTC

this happens only when there is a kvm  vm in rhel6_x86-64 , the vm guest is rhel6 ,too . and the guest is set as vncserver

Comment 7 euroford 2012-10-21 06:35:44 UTC

Hi, tigerVNC server can work well with 24bit color depth in a kvm vm, both vinagre and tigerVNC-viewer works.

Good connection (tigervnc-server)log:
TigerVNC Viewer for X version 1.0.90 - built Dec  8 2011 01:41:17
Copyright (C) 2002-2005 RealVNC Ltd.
Copyright (C) 2000-2006 TightVNC Group
Copyright (C) 2004-2009 Peter Astrand for Cendio AB
See http://www.tigervnc.org for information on TigerVNC.

Sun Oct 21 14:22:40 2012
 CConn:       connected to host 192.168.122.194 port 5902
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8

Sun Oct 21 14:22:43 2012
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using Tight encoding

Bad connection (vino server) log:
TigerVNC Viewer for X version 1.0.90 - built Dec  8 2011 01:41:17
Copyright (C) 2002-2005 RealVNC Ltd.
Copyright (C) 2000-2006 TightVNC Group
Copyright (C) 2004-2009 Peter Astrand for Cendio AB
See http://www.tigervnc.org for information on TigerVNC.

Sun Oct 21 14:23:08 2012
 CConn:       connected to host 192.168.122.194 port 5901
 CConnection: Server supports RFB protocol version 3.7
 CConnection: Using RFB protocol version 3.7

Sun Oct 21 14:23:10 2012
 main:        setPF: not 8, 16 or 32 bpp?

Comment 8 John Ellson 2013-06-10 16:52:25 UTC

I get this "main: setPF: not 8, 16 or 32 bpp?" error when displaying from a Fedora18 virtual host using:


  ssh -o CheckHostIP=no -o StrictHostKeyChecking=no -t -L localhost:5910:localhost:5900 $IPADDR $LOGIN 'x11vnc -nopw -localhost -display :0' &
  sleep 5
  vncviewer --geometry=960x540 localhost:10
  

I can work around the problem by adding -24to32 to the X11vnc options.


So, it seems to me, that 24bit support in tigervnc is not working.


* tigervnc-1.2.80-0.15.20130314svn5065.fc19.x86_64

Comment 10 b24warbaby 2015-04-06 13:56:30 UTC

Whomever broke vino in centOS-7 . please fix it 

Completely useless any more using ALL previous viewers

Comment 11 Ondrej Holy 2015-04-07 10:25:31 UTC

(In reply to b24warbaby from comment #10)
> Whomever broke vino in centOS-7 . please fix it 
> 
> Completely useless any more using ALL previous viewers

This bug report is for RHEL 6. Please use Mantis for CentOS bugs, or you can add some relevant info into the RHEL 7 bugs, but do not spam this threat with such unuseful comments, thanks...

Comment 12 Ondrej Holy 2015-04-07 10:27:19 UTC

Some vnc clients (i.e. TigerVNC) have problems with 24 depth. You have to reconfigure X to use different depth (Comment 2, Comment 5), or use different server which e.g. expands 24 to 32 (Comment 7, Comment 8). However this should be tigervnc bug instead, because it doesn't support 24 bit depth....

Comment 13 Tim Waugh 2015-04-07 11:31:07 UTC

"Depth" is a different thing than "bits per pixel".

From the protocol spec:
"Bits-per-pixel is the number of bits used for each pixel value on the wire. This must be greater than or equal to the depth which is the number of useful bits in the pixel value. Currently bits-per-pixel must be 8, 16 or 32"

Comment 15 Chris Williams 2015-09-18 13:53:03 UTC

This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 6 and therefore will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.

Note You need to log in before you can comment on or make changes to this bug.