Comment 3 for bug 117229

Revision history for this message
Mike Hicks (hick0088) wrote :

Interesting idea with xtightvncviewer, but I end up getting a similar problem with it too. Here I was connecting to a QEMU session booting OpenSolaris:

    [mhicks@accra][~]$ xtightvncviewer -compresslevel 7 -encodings "copyrect tight hextile zlib corre rre raw" localhost:1
    Connected to RFB server, using protocol version 3.8
    No authentication needed
    Authentication successful
    Desktop name "QEMU"
    VNC server default format:
      32 bits per pixel.
      Least significant byte first in each pixel.
      True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
    Using default colormap which is TrueColor. Pixel format:
      32 bits per pixel.
      Least significant byte first in each pixel.
      True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
    Using shared memory PutImage
    Rect too large: 720x400 at (0, 0)
    ShmCleanup called
    [mhicks@accra][~]$

Well, that's a different package, and I don't want to file bugs for that here.

I seem to have the biggest problems in xvnc4viewer when the emulated system is changing video resolution, which happens multiple times in the process of booting a guest. In QEMU or KVM, the resolution also usually changes when accessing the built-in management console by pressing Ctrl+Alt+2 and then change resolution again to go to the emulated VGA by pressing Ctrl+Alt+1.

One potential problem is that xvnc4viewer seems to destroy and re-create a window whenever the resolution changes (well, my compiz window manager thinks it's doing that anyway -- I'm getting the window open/close effects to trigger at these times). I'm suspicious that there may be a timing issue where the client may be trying to draw an image at the new resolution before the window has switched, or in that instant between the old window being destroyed and the new one being created.

Of course, there's a decent probability that there are bugs in the bulit-in VNC servers on QEMU and KVM, but the client should be more tolerant of bogus data coming down the pipe.