Re: [Qemu-devel] [PATCH] VNC display support for QEMU
Brad Campbell wrote: Also I can't access the monitor (which I can with the other vnc patch) ... again, when I get a chance. Oh how I wish I'd read the todo carefully.. thumps head on desk -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
Hi, On Mon, 1 May 2006, Brad Campbell wrote: I need to look at the protocol and see if there is a way to instruct the client to change its size on the fly also.. at the moment booting win2k I have three different client sizes and need to close/reopen the client for each change. rfbEncodingNewFBSize. You can find example code in the current CVS of LibVNCServer. Hth, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
Hi, On Sat, 29 Apr 2006, Anthony Liguori wrote: I would have been more inclined to use LibVNCServer if it wasn't based on threading. I really wanted an asynchronous implementation of a VNC server that didn't depend on threads. AFAICT it does not. In vnc_refresh(), there is a call to rfbProcessEvents, which says to select() the socket(s) for 0 microseconds. Same thread. Now, there is a facility in LibVNCServer to take advantage of pthreads, and in some applications it is actually better to run a background thread to handle all the VNC stuff. But it is not used in QEmu. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
Johannes Schindelin wrote: Hi, On Sat, 29 Apr 2006, Anthony Liguori wrote: I would have been more inclined to use LibVNCServer if it wasn't based on threading. I really wanted an asynchronous implementation of a VNC server that didn't depend on threads. AFAICT it does not. In vnc_refresh(), there is a call to rfbProcessEvents, which says to select() the socket(s) for 0 microseconds. Same thread. There is a fundamental design in the LibVNCServer code (which I believe was inherited from the various RealVNC derivatives) that all IO is done through some derivation of rfbReadExact. rfbReadExact is semantically synchronous (it uses select to enforce that). You could, perhaps, not begin an iteration of the server message process loop until the socket becomes readable but that only gives you a semi-asynchronous interface. As soon as you get 1 byte of message data, you are now handling things synchronously until that message is complete. Since QEMU is single threaded, this means everything blocks (including progress of the guest). This theoretical problem is why I implemented a true asynchronous VNC implementation. You'll notice that I use a state machine to handle the message dispatch (which is practical for the server side of the VNC protocol at least). My VNC will never (assuming it's working correctly :-)) block guest progress because of outstanding IO. There is a practical problem too with a semi-asynchronous approach. It's entirely possible to get serious congestion in odd places during a message transmission (or even a loss that requires timeout). This means you could end up blocking the guest for a prolonged period of time (and if the guest is doing serious work--like hosting some sort of network service--this is catastrophic). So, in a multithreaded application or a single-threaded application that doesn't have to worry about these things, LibVNCServer is a great solution. I just don't think it's the right solution for QEMU for the reasons outlined above. Regards, Anthony Liguori Now, there is a facility in LibVNCServer to take advantage of pthreads, and in some applications it is actually better to run a background thread to handle all the VNC stuff. But it is not used in QEmu. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
neat! it is working on windows 3.0 guest (no acceleration) on a winXP host. Fabrice fixed it live while I was trying it (he's fast!). old mouse sync problem is still here, as you mentionned no calibration is done. You mention absolute mouse. how to do it ? On 5/1/06, Christian MICHON [EMAIL PROTECTED] wrote: just a quick note: your patch breaks the mingw32 build on winXP. Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
On Sun, Apr 30, 2006 at 03:03:55AM +0200, Johannes Schindelin wrote: Hi, On Sat, 29 Apr 2006, Anthony Liguori wrote: One thing you may notice is that RealVNC has some issues with being disconnected. This is because it likes to switch from 8bit to 32bit depths automatically at startup. Unfortunately, there is a race condition in the VNC protocol and since this implementation is asynchronous, we seem to be much more prone to exposing this. This, along with other problems, has been solved with LibVNCServer. But of course, you are welcome to solve them again. I have noticed that interactive performance with the current libvncserver based patches is quite bad compared to doing the same thing on SDL. Maybe re-implementing vnc will uncover why it is slow. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
Where 1 is the first display (port 5901). This syntax may change in the near future to support binding to a particular interface. It's very useful to use an absolute mouse with VNC as the relative support is quite poor. It may be useful to adapt the libvncserver patch's calibration code here but I've not attempted to do that yet. This patch is still experimental. I've tested it with RealVNC and TightVNC under a variety of depths but I won't be suprised if there are still problems. I only implement Raw, CopyRect, and Hextile encodings too. Any sort of palette color mode or pixel format that QEMU doesn't support will not work either. One thing you may notice is that RealVNC has some issues with being disconnected. This is because it likes to switch from 8bit to 32bit depths automatically at startup. Unfortunately, there is a race condition in the VNC protocol and since this implementation is asynchronous, we seem to be much more prone to exposing this. A short near-term TODO list is: 1) More testing 2) Support switching between monitor/serial 3) Support a better encoding (like TightEncoding or ZRLE) 4) Support a vnc password (and perhaps stuff like TLS) Any feedback is greatly appreciated (especially with how it works with clients I've not tested). realvnc on debian-ppc (xvncviewer-3.3.7) has endian issues (the colors are wrong). However, mouse tracking and dragging windows actually *works*. (This is with the version currently in cvs) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] VNC display support for QEMU
Hi,
The attach patch adds VNC display support for QEMU. It does not use
libvncserver but was rather written from scratch. libvncserver is a
really neat project and I've used it in a number of other projects but I
think QEMU really requires a custom implementation.
First, to enable vnc support, you use the -vnc option like:
qemu -vnc 1
Where 1 is the first display (port 5901). This syntax may change in the
near future to support binding to a particular interface. It's very
useful to use an absolute mouse with VNC as the relative support is
quite poor. It may be useful to adapt the libvncserver patch's
calibration code here but I've not attempted to do that yet.
This patch is still experimental. I've tested it with RealVNC and
TightVNC under a variety of depths but I won't be suprised if there are
still problems. I only implement Raw, CopyRect, and Hextile encodings
too. Any sort of palette color mode or pixel format that QEMU doesn't
support will not work either.
One thing you may notice is that RealVNC has some issues with being
disconnected. This is because it likes to switch from 8bit to 32bit
depths automatically at startup. Unfortunately, there is a race
condition in the VNC protocol and since this implementation is
asynchronous, we seem to be much more prone to exposing this.
A short near-term TODO list is:
1) More testing
2) Support switching between monitor/serial
3) Support a better encoding (like TightEncoding or ZRLE)
4) Support a vnc password (and perhaps stuff like TLS)
Any feedback is greatly appreciated (especially with how it works with
clients I've not tested).
Regards,
Anthony Liguori
diff -urN -x '*.[di]' a.hg/hw/cirrus_vga.c vnc.hg/hw/cirrus_vga.c
--- a.hg/hw/cirrus_vga.c2006-04-29 16:01:36.0 -0500
+++ vnc.hg/hw/cirrus_vga.c 2006-04-29 16:18:46.0 -0500
@@ -644,15 +644,90 @@
(s-cirrus_blt_srcaddr ~7));
}
-static int cirrus_bitblt_videotovideo_copy(CirrusVGAState * s)
+static void cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h)
{
+int sx, sy;
+int dx, dy;
+int width, height;
+int depth;
+int notify = 0;
+
+depth = s-get_bpp((VGAState *)s) / 8;
+s-get_resolution((VGAState *)s, width, height);
+
+/* extra x, y */
+sx = (src % (width * depth)) / depth;
+sy = (src / (width * depth));
+dx = (dst % (width *depth)) / depth;
+dy = (dst / (width * depth));
+
+/* normalize width */
+w /= depth;
+
+/* if we're doing a backward copy, we have to adjust
+ our x/y to be the upper left corner (instead of the lower
+ right corner) */
+if (s-cirrus_blt_dstpitch 0) {
+ sx -= (s-cirrus_blt_width / depth) - 1;
+ dx -= (s-cirrus_blt_width / depth) - 1;
+ sy -= s-cirrus_blt_height - 1;
+ dy -= s-cirrus_blt_height - 1;
+}
+
+/* are we in the visible portion of memory? */
+if (sx = 0 sy = 0 dx = 0 dy = 0
+ (sx + w) = width (sy + h) = height
+ (dx + w) = width (dy + h) = height) {
+ notify = 1;
+}
+
+/* make to sure only copy if it's a plain copy ROP */
+if (*s-cirrus_rop != cirrus_bitblt_rop_fwd_src
+ *s-cirrus_rop != cirrus_bitblt_rop_bkwd_src)
+ notify = 0;
+
+/* we have to flush all pending changes so that the copy
+ is generated at the appropriate moment in time */
+if (notify)
+ vga_hw_update();
+
(*s-cirrus_rop) (s, s-vram_ptr + s-cirrus_blt_dstaddr,
s-vram_ptr + s-cirrus_blt_srcaddr,
s-cirrus_blt_dstpitch, s-cirrus_blt_srcpitch,
s-cirrus_blt_width, s-cirrus_blt_height);
-cirrus_invalidate_region(s, s-cirrus_blt_dstaddr,
-s-cirrus_blt_dstpitch, s-cirrus_blt_width,
-s-cirrus_blt_height);
+
+if (notify)
+ s-ds-dpy_copy(s-ds,
+ sx, sy, dx, dy,
+ s-cirrus_blt_width / depth,
+ s-cirrus_blt_height);
+
+/* we don't have to notify the display that this portion has
+ changed since dpy_copy implies this */
+
+if (!notify)
+ cirrus_invalidate_region(s, s-cirrus_blt_dstaddr,
+s-cirrus_blt_dstpitch, s-cirrus_blt_width,
+s-cirrus_blt_height);
+}
+
+static int cirrus_bitblt_videotovideo_copy(CirrusVGAState * s)
+{
+if (s-ds-dpy_copy) {
+ cirrus_do_copy(s, s-cirrus_blt_dstaddr - s-start_addr,
+ s-cirrus_blt_srcaddr - s-start_addr,
+ s-cirrus_blt_width, s-cirrus_blt_height);
+} else {
+ (*s-cirrus_rop) (s, s-vram_ptr + s-cirrus_blt_dstaddr,
+ s-vram_ptr + s-cirrus_blt_srcaddr,
+ s-cirrus_blt_dstpitch, s-cirrus_blt_srcpitch,
+ s-cirrus_blt_width, s-cirrus_blt_height);
+
+
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
Hi Johannes, Johannes Schindelin wrote: Hi, On Sat, 29 Apr 2006, Anthony Liguori wrote: One thing you may notice is that RealVNC has some issues with being disconnected. This is because it likes to switch from 8bit to 32bit depths automatically at startup. Unfortunately, there is a race condition in the VNC protocol and since this implementation is asynchronous, we seem to be much more prone to exposing this. This, along with other problems, has been solved with LibVNCServer. But of course, you are welcome to solve them again. I should mention, the majority of the smarts of this patch are QEMU specific optimizations. The first one maintains a separate copy of the client's framebuffer to use to reduce the size of the updates generated by the VGA code. The second one hooks the Cirrus 2d video-to-video copy to generate VNC CopyRect updates. The actual VNC side of the code is pretty trivial. I would have been more inclined to use LibVNCServer if it wasn't based on threading. I really wanted an asynchronous implementation of a VNC server that didn't depend on threads. Regards, Anthony Liguori Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
