Re: [Qemu-devel] vnc patch
did I understand well ? 1) there's a rework of the original vnc patch 2) there are no problems of sync using the usb tablet what is this usb tablet stuff? do I really need a usb tablet connected to the host or this is yet another emulated hardware inside the qem guest ? If this is the case, it means the client OS must have the proper drivers, etc... I'm a bit lost. Christian On 4/29/06, Anthony Liguori [EMAIL PROTECTED] wrote: Lonnie Mendez wrote: Lonnie Mendez wrote: There is another vnc patch by Anthony Liguori (same person involved with the tablet along with others). From what I've heard it will reduce the bandwidth usage greatly. Also, afaik this is still under development. The source was posted on the irc channel a few days ago: http://www.cs.utexas.edu/users/aliguori/vnc.diff The mercurial tree is located at http://hg.codemonkey.ws/qemu-vnc If you go to Manifest - Changeset you can download a static tarball if you're unfamiliar with mercurial. It's in a pretty good state now. I don't think there's any significant bugs and all the features I plan on implementing for the first rev are there. I'll have a patch ready for submission in a day or so. Regards, Anthony Liguori ___ 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 ___ 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);
+
+
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook [EMAIL PROTECTED] 06/04/29 23:05:23 Modified files: . : configure Log message: Fix non-portable use of expr. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/configure.diff?tr1=1.97tr2=1.98r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
lo. The attached patch addresses the problem with removing the
usbhub/tablet devices and switches the handle_packet call in the port
reset call to handle_msg which just happens to make the hub functional.
--- a/qemu/hw/usb-hub.c 2006-04-28 19:44:18.0 -0500
+++ b/qemu/hw/usb-hub.c 2006-04-29 18:55:46.0 -0500
@@ -240,6 +240,13 @@
return 1;
}
+int usb_hub_handle_close(USBDevice *dev)
+{
+USBHubState *s = (USBHubState *)(dev-opaque);
+qemu_free(s);
+return 1;
+}
+
int usb_hub_handle_control(USBDevice *dev, int request, int value,
int index, int length, uint8_t *data)
{
@@ -385,8 +392,7 @@
break;
case PORT_RESET:
if (dev) {
-dev-handle_packet(dev,
- USB_MSG_RESET, 0, 0, NULL, 0);
+dev-handle_msg(dev, USB_MSG_RESET);
port-wPortChange |= PORT_STAT_C_RESET;
/* set enable bit */
//port-wPortChange |= PORT_STAT_C_ENABLE;
@@ -578,6 +584,7 @@
dev-handle_packet= usb_hub_handle_packet;
dev-handle_attach= usb_hub_attach;
dev-handle_reset= usb_hub_handle_reset;
+dev-handle_close= usb_hub_handle_close;
dev-handle_control=usb_hub_handle_control;
dev-handle_data= usb_hub_handle_data;
--- a/qemu/hw/usb-hid.c 2006-04-28 19:44:18.0 -0500
+++ b/qemu/hw/usb-hid.c 2006-04-29 18:56:15.0 -0500
@@ -526,6 +526,7 @@
dev-handle_packet= usb_generic_handle_packet;
dev-handle_reset= usb_mouse_handle_reset;
+dev-handle_close= usb_mouse_handle_close;
dev-handle_control=usb_mouse_handle_control;
dev-handle_data= usb_mouse_handle_data;
s-kind=USB_TABLET;
___
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 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
