After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 346258 - Display problem when viewing Vino server output with Xinerama screens
Display problem when viewing Vino server output with Xinerama screens
Product: vino
Classification: Applications
Component: Server
Other All
: Normal blocker
: ---
Assigned To: Vino Maintainer(s)
Vino Maintainer(s)
Depends on:
Reported: 2006-06-30 00:49 UTC by Stewart Hardie
Modified: 2020-11-12 12:24 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14

Screenshot via GIMP showing issue (258.28 KB, image/png)
2007-09-17 19:23 UTC, Matthew A. R. Sherian

Description Stewart Hardie 2006-06-30 00:49:18 UTC
Please describe the problem:
Description of problem:
OS: Fedora Core 5
I have set up two monitors connected to a Nvidia 6200AGP card. One monitor is
connected to VGA output, the other to DVI output. Using Livna 87.62 nvidia
drivers. Setup Xinerama configuration to 'on' to share the desktop across two
monitors. Set up xorg.conf as:

Section "ServerLayout"
Identifier "Multihead layout"
Screen 0 "Screen0" RightOf "Screen1"
Screen 1 "Screen1" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
Option "Xinerama" "on"
Option "Clone" "off"

Each monitor displays 1280x960 (however this problem is also apparent at 800x600
for each monitor).

When using the Real VNC viewer (version 4.1.1) on a windows computer and
connecting to the Vino server output, I am presented with a VNC viewer desktop
of size 2560x960 as expected. However, the left side of the VNC viewer shows the
desktop displayed on the left linux monitor with a few block artifacts and the
right side of the viewer is black where it should be showing the contents of the
right linux monitor. Moving windows around on the left monitor causes 'tearing'
in the windows on the left side on the VNC viewer, and the VNC viewer window is
generally really sluggish and unresponsive.

These problems are also shown when using VNC viewer on the same FC5 computer and
looping the connection back to port 5900 (Vino server port).

Steps to reproduce:
1. Enable xinerama in xorg.conf and extend desktop across two monitors.
2. Enable remote desktop under Gnome preferences menu. 
3. Start VNC viewer under Gnome Accessories menu or a VNC viewer on another
computer and connect to the vino server.
4. Scroll to the right side of the VNC viewer window.

Actual results:
The right side of the VNC viewer window is black, although it may vary depending on how you have xinerama set up. Random artifacts on the viewer window also occur.

Expected results:
The right side of the VNC viewer window should show the desktop of the right
linux computer monitor.

Does this happen every time?

Other information:
Additional info:
This bug report is also filed at:
but I thought since its a Gnome thing, I'd put this bug report here too where the real Gnome stuff happens.

A bug report describing similar issues under vino-2.8.1-1 in FC3 is at:
Unsure whether it is exactly the same issue. However, this is a problem in FC5,
not FC3, and it was suggested to me on to file this as a new bug
for FC5.
Comment 1 Mark McLoughlin 2006-10-23 10:58:56 UTC
FWIW, I don't think we've seen any other bug reports of this upstream and I don't have Xinerama in order to try and reproduce

I suspect it might not be uniformly broken with all Xinerama configurations, though

Do you still see this problem?
Comment 2 Stewart Hardie 2006-10-24 03:32:24 UTC
The problem still exists, although as of 24/10/06, the artifacts have gone but one half of the VNC viewer window is still black. Something must have got partially fixed in FC5 updates.

I will be installing FC6 in the next week or so, so can try this again. Perhaps the combination of gnome 2.16, xorg7.1 and nvidia 9xxx drivers will fix it. I'll post another comment once tested.

Also, what would be most excellent is for vino to transmit NX. FreeNX desktops is much faster than VNC desktops over the internet, but does not yet support the 0 desktop (seen on the connected monitors) like what vino does. Is it possible to either build NX export into vino or provide an alternative??
Comment 3 Stewart Hardie 2006-11-05 05:00:54 UTC
I have installed Fedora core 6 (vino 2.13.5?), and the problem still exists. In the VNC viewer, half of the screen is black. Used all latest nvidia drivers, updates etc. It would seem vino does not handle xinerama well. I tried Nvidia TwinView, and that works fine, presumably because it appears as one desktop to all top level apps.
Comment 4 Matthew A. R. Sherian 2007-09-17 19:23:41 UTC
Created attachment 95758 [details]
Screenshot via GIMP showing issue
Comment 5 Anton Fedorov 2008-07-08 07:48:16 UTC
I have same bug too :(

It VERY annoyng, since i'm use vino + vnc connection for remote controlling of running process. On second screen displayed also important info, so i can't see it, nor control it.

Mine configuration:
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600 GT (rev a1)

NVRM version: NVIDIA UNIX x86 Kernel Module  173.14.05  Mon May 19 00:06:12 PDT 2008
GCC version:  gcc version 4.1.3 20080420 (prerelease) (Debian 4.1.2-22)

Package: vino
State: installed
Version: 2.22.2-1

======== xorg.conf: =============================================

Section "ServerLayout"
    Identifier     "Default Layout"
    Screen      0  "Screen0" 0 0
    Screen      1  "Screen1" RightOf "Screen0"
    InputDevice    "Generic Keyboard"
    InputDevice    "Configured Mouse"

Section "ServerFlags"
    Option         "Xinerama" "1"

Section "Monitor"
    Identifier     "VP930 Series"
    Option         "DPMS"

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "ViewSonic VP930 Series"
    HorizSync       30.0 - 82.0
    VertRefresh     50.0 - 75.0

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "ViewSonic VP930 Series"
    HorizSync       30.0 - 82.0
    VertRefresh     50.0 - 75.0

Section "Device"
    Identifier     "nVidia Corporation NVIDIA Default Card"
    Driver         "nvidia"

Section "Device"
    Identifier     "Videocard0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 8600 GT"
    BusID          "PCI:1:0:0"
    Screen          0

Section "Device"
    Identifier     "Videocard1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 8600 GT"
    BusID          "PCI:1:0:0"
    Screen          1

Section "Screen"
    Identifier     "Default Screen"
    Device         "nVidia Corporation NVIDIA Default Card"
    Monitor        "VP930 Series"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
        Modes      "1280x1024" "1152x864" "1024x768" "832x624" "800x600" "720x400" "640x640" "640x480"

Section "Screen"
    Identifier     "Screen0"
    Device         "Videocard0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "metamodes" "DFP-0: 1280x1024 +0+0; DFP-0: 1152x864 +0+0; DFP-0: 1024x768 +0+0; DFP-0: 832x624 +0+0; DFP-0: 800x600 +0+0; DFP-0: 640x480 +0+0"
    SubSection     "Display"
        Depth       24
        Modes      "nvidia-auto-select"

Section "Screen"
    Identifier     "Screen1"
    Device         "Videocard1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "metamodes" "DFP-1: nvidia-auto-select +0+0"
    SubSection     "Display"
        Depth       24
        Modes      "nvidia-auto-select"

======== /xorg.conf: =============================================
Comment 6 Anton Fedorov 2008-08-01 15:16:16 UTC
x11vnc have no that issue. Since i have no dual-head setup under hand to testing, i just read up code comparsion.

the only difference i see, is vino uses XCopyArea to get damaged pixels, while x11vnc always copy fullscrin or tiles with XShmGetImage.

If no shm enabled, both use just XGetSubImage -- can someone who can access to non-working setup, try to run vino-server without SHM support?
either with recompile with HAVE_XSHM disabled, or by remove SHM extension from server (that will slowdown it, but just for testing)...
Comment 7 Anton Fedorov 2008-08-01 15:25:50 UTC
please, someone, who can:
try add to xorg.conf:
  Section "Extensions"
    Option "MIT-SHM" "disable"
and see, will second display visible then
Comment 8 Anton Fedorov 2008-08-01 15:45:34 UTC
also, one other moment is try to enable
  Option "DDCMode" "True"
in both Device sections (try that with and without disabling shm)
Comment 9 Mike Hogye 2008-08-05 17:23:03 UTC
With SHM disabled, the right half of my vnc image (where my second monitor is) is no longer black -- it shows the desktop! However, it does not refresh -- it's like it did a one-time screengrab when I started vncviewer. Even the mouse pointer is not drawn on that half of the vnc image.

DDCMode seems to have no effect -- if SHM is enabled, half the vnc image is black, regardless of DDCMode, and if SHM is disabled, half the vnc image is a non-refreshing screengrab, regardless of DDCMode.
Comment 10 Mike Hogye 2008-08-05 17:24:51 UTC
Oh, left out a detail: to disabled SHM, I changed my xorg.conf (instead of recompiling vino).
Comment 11 Anton Fedorov 2008-08-06 15:14:24 UTC
Well, that's great! That mean two points:
  1. XCopyArea have bug with xinerama, i'll post that problem to uplink
  2. Possible, XDamage have bug with xinerama.

To verify 2nd moment, please also disable XDamage extension in your xorg.conf with 
  Section "Extensions"
    Option "MIT-SHM" "disable"
    Option "DAMAGE" "disable"
and see, is it will works in that config.
Comment 12 Anton Fedorov 2008-08-06 17:30:20 UTC
So, vino workaround can be:
  test for xinerama extension
  if xinerama enabled, then:
    1. use XGetSubImage instead of XCopyArea
    2. use polling instead of XDamage
or, get from x11vnc their method:
  1. use XDamage for realtime update
  2. do once a period (1s, f.e.) full changes scan
  3. if found changes, not found with XDamage -- change from XDamage completely to polling
Comment 13 Anton Fedorov 2008-08-12 12:09:35 UTC
Have access to system with problem (as shown above).

Have edit server/vino-fb.c
1. vino_fb_init_from_screen
have replaced line
  vfb->priv->use_x_shm = XShmQuery...
  vfb->priv->use_x_shm = False;

2. vino_fb_init_xdamage
just added 
right after variables define (after line
  XGCValues values;

Re-compiled, re-install and re-start vino, now mine second screen works excellent.
Comment 14 Anton Fedorov 2008-08-17 07:55:11 UTC
Will someone confirm bug, or it will be forever unconfirmed?

Also, severity shoud be normal, not blocker.
Comment 15 Vincent Tschanz 2008-12-11 15:28:01 UTC
I ave the same problem here with Ubuntu.
happens on Ubuntu 7.04, 7.10, 8.04, 8.10
Comment 16 Jonathan Sambrook 2010-07-27 18:59:30 UTC
Problem here too Ubuntu 10.04.1 LTS with Vino 2.28.2-0ubuntu2

Any chance of this getting addressed please?
Comment 17 Michele Baldessari 2013-03-04 21:19:13 UTC
Can you try 'gconftool-2 -s --type bool "/desktop/gnome/remote_access/disable_xdamage" false' and see if the issue persists?
Comment 18 André Klapper 2020-11-12 12:24:40 UTC
Vino is not under active development anymore and unmaintained.

Please use gnome-remote-desktop instead.

Closing this report as WONTFIX to reflect reality.