This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 167827

Summary: after xrandr, vnc.so informs client of old screen size, but image matches new size
Product: [Fedora] Fedora Reporter: Alexandre Oliva <oliva>
Component: tigervncAssignee: Adam Tkac <atkac>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 12CC: atkac, bugzilla-redhat, ovasik, triage
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-05 02:18:50 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Alexandre Oliva 2005-09-08 12:56:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b3) Gecko/20050827 Fedora/1.1-0.2.8.deerpark.alpha2 Firefox/1.0+

Description of problem:
I've been trying to compare performance of vino with vnc.so, expecting the latter to perform better to export my desktop's display to my notebook or vice-versa.

Problem is that I have my desktop configured to go up to 1920x1440 of resolution, and use that as default, but my login switches to 1600x1200 with the gnome desktop settings (equivalent to running xrandr -s 1600x1200).  Although vino handles resolution changes just fine (it used to crash on xrandr, but this was recently fixed), vnc.so sends the wrong screen size to the client even if I connect after the resolution change.

When I connect after logging in on the server (i.e., after the display was changed to 1600x1200), the client still includes vertical and horizontal scroll bars to enable me to view the entire 1920x1440 area.

Worse yet: the visible area on the server is not in the upper left corner of the scrollable area on the client; instead, the upper area has content in its full length, and the lower portion is all black, if I scroll down.  Worse yet, the screen is garbled.  That's because the server is sending lines with 1600 pixels, but the client displays the first 1600 pixels in the first line, then continues for another 320 pixels of the next line on the same first line, then wraps to the next line and displays the remaining pixels of the second line plus some of the third, and so on.  Here's a text depiction of what happens.  Here's what the screen should look like:

0123456789abcdef
0123456789abcdef
0123456789abcdef
0123456789abcdef
0123456789abcdef

here's what it looks like:

0123456789abcdef012
3456789abcdef012345
6789abcdef012345678
9abcdef0123456789ab
cdef0123456789abcde
f..................
...................

I.e., it's wider (19x7, instead of 16x5), and lines are wrapped around, then the rest is filled with black dots.  Very hard to use it like that :-)

Re-running xrandr with the client already connected to switch back to 1920x1200 restores the display to a usable state, but requires scrolling on the client, which I'd rather avoid.  Running xrandr to lower the resolution again corrupts the display again.

Version-Release number of selected component (if applicable):
xorg-x11-6.8.2-45
vnc-server-4.1.1-17
vnc-4.1.1-17

How reproducible:
Always

Steps to Reproduce:
1.Configure vnc.so on an X server
2.Connect to it with vncviewer
3.Use xrandr to lower the resolution
  

Actual Results:  The display gets corrupted

Expected Results:  It should report the new resolution to the client, such that it can display correctly the image that is sent with the new number of pixels per line.

Additional info:

Using vino is a reasonable work around, and so is setting the initial resolution as desired, avoiding the need for xrandr.
Comment 1 Adam Tkac 2006-10-27 09:12:42 EDT
please, could you try to reproduce this with latest version of vnc?? vncserver
now uses improved version of xorg-server which can fix this problem
Comment 2 Adam Tkac 2007-03-07 01:46:50 EST
still exists :(
Comment 3 Bug Zapper 2008-04-03 12:18:56 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 4 Adam Tkac 2008-04-04 05:47:00 EDT
moving back to assigned
Comment 5 Bug Zapper 2008-05-13 22:01:49 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Henrique Martins 2008-06-29 14:44:20 EDT
I see something similar to this without even having to switch resolutions on
either the client or the server.  The server has a Radeon 7500 (Radeon RV2000
QW) and comes up on 1280x1024.  Trying to connect from a laptop with a 1440x1050
screen produces a garbled screen, like the client and server don't properly
match resolutions.

I'm on F9 with vnc-server-4.1.2-30.fc9, and otherwise daily updated from
updates.  Client is on WinXp with latest RealVNC 4.1.2 free edition.
Comment 7 Henrique Martins 2008-07-01 11:33:59 EDT
I now have two F9 machines where vnc, sharing the console session, doesn't size
properly.  Hitting F8 on the client and asking for connection options shows that
vnc thinks the server is running on a 1600x1600 window, when both my consoles
are at 1280x1024, making the garbled remote display unusable.
Is anyone else seeing this?
Comment 8 Henrique Martins 2008-07-18 21:00:35 EDT
Latest update of vnc/vnc-server and some x-drivers now has vncviewer still
broken, reporting a 1400x1400 window, instead of 1280x1024.  Shall I move this
to a new bug?
vnc-4.1.2-31.fc9.i386
vnc-server-4.1.2-31.fc9.i386
libvncserver-0.9.1-2.fc9.i386.rpm
vnc-libs-4.1.2-31.fc9.i386.rpm
Not sure which of the many xorg-x11-drv-... I should report.

Comment 9 Bug Zapper 2009-06-09 18:03:06 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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 10 Bug Zapper 2009-07-14 12:51:11 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 11 Adam Tkac 2009-07-15 03:40:51 EDT
This bug is still present, moving back to rawhide.
Comment 12 Bug Zapper 2009-11-16 02:49:57 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
Comment 13 Bug Zapper 2010-11-04 08:18:28 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 14 Bug Zapper 2010-12-05 02:18:50 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.