[Qemu-devel] [PATCH] VLAN and Tap for win32
Hi, VLAN and Tap patches for win32 are updated. I added handling for wait objects. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-0.8.1-vlan.patch http://www.h7.dion.ne.jp/~qemu-win/download/qemu-0.8.1-tap.patch Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Fabrice Bellard wrote: Dan Sandberg wrote: Just curious... Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? If not, then consider the benefits: 1. It is much faster than any native graphics 2D/3D primitives like Windows GDI 2: It gives full control over things like window or fullscreen mode in any (almost) resolution and color depth. 3. It is operating system independent. 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha channel etc in hardware, all you have to do is select the pixelformat you like to use for the buffer and OpenGL does the rest - lightning fast, minimum CPU-load. [...] I am not sure the bottleneck is in the rendering itself and the single primitive that QEMU uses (display a rectangle of bitmap) is accelerated by every graphic card since many years. But you are free to modify the SDL library to include OpenGL rendering if it is not already done :-) Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel OK, I am no expert at Qemu's inner workings as you are, but I think I have seen mentioned that host and guest pixel formats should be kept identical for best performance eg. an undesired need to select 16-bit graphics on the host when one wants to use high resolution on the guest at which resolution the emulated graphics board only supports 16-bit. I also get the impression that the quest display area is updated less frequently than the native intervall probably to keep CPU-load down and also meaning that the guest OS waste CPU-time on rendering that is sometimes thrown away when it happens in between actual Qemu display updates. To me this suggests that the needed RectangleBlit operation is not CPU-transparent and it seems from the discussions that the lower than native update frequency may introduce totally new problems like graphic artefacts or possibly the guest OS going out of sync with the emulated display adapter and a pointer that cannot keep up with fast movements sometimes. Creating a rectangular direct output area in OpenGL is actually like vitualizing a graphics card. It is updated at native speed and you can select pixelformat for that area independent of the host pixel format and you do not have to be doing any RectangleBlit operation or causing any CPU-load - to my understanding at least. The next logical step would be to emulate a more competent graphics board in this rectangular area including hardware acceleration for guest RectangleBlit operations etc. This would give much better 2D-performance for any guest OS that knows have to take advantage of it and of course OpenGL would be used for this too. It is more or less a mapping of OpenGL functionality between guest and host OS'es. No fancy 3D OpenGL stuff is needed, only the very basic 2D functionality is required to boast performance in windowed enviroments so even old and cheap graphics cards would do the job. It is OS-independent as long you can find an OpenGL-driver. I realize that the latter may be a problem in some cases so I am not saying that any of todays possibilities in Qemu should be retired, rather that it could be sort of a new plug-in module for those who want a virtual display adapter with close to native graphic performance and happen to have what is needed in terms of graphic card and drivers. I am also not suggesting that you should do the hard work Fabrice. I am truly impressed of what you are doing and don't understand how you find the time. I am also not suggesting that I know exactly how to do it, I am a beginner when it comes to OpenGL-programming and only starting to realize the possibilities of it. So I only wanted to start the discussion and hopeing for an OpenGL-genious out there with lots of spare time. :) Regards Dan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Hi, On 12/05/06, Troy Benjegerdes [EMAIL PROTECTED] wrote: On Fri, May 05, 2006 at 09:06:20AM -0500, Anthony Liguori wrote: Ben Taylor wrote: I'm seeing quite a few bugs on Qemu 0.8.1 with the vnc feature 1) Sparc based system comes up in distored colors (foreground of a Damn Small linux iso comes up in yellow, instead of white) This is a know problem. qemu doesn't give any indication that the guest is storing pixels in big endian mode. A proper fix is on my TODO list. 2) When it bounces from the initial syslinux text to the grahpical screen, it leaves the text in the top left corner not cleared. (to the boot: at the bottom) Yeah, I've noticed something similar myself. It's on the TODO list (see vnc.c). 3) screen autoresize is not working. 2 examples with DSL. a) initial screen is 80x25, but qemu comes up in 80x24 and stays there and I can't see boot: prompt at the bottom. b) when it goes into graphical mode, it's not resizing so I'm missing some portion of the screen TightVNC doesn't support the desktop resize encoding. Try RealVNC. I am running the current CVS code and seeing endian color problems with a x86 machine running qemu and a PPC linux machine running xrealvncviewer. This is the debian xvncviewer package version 3.3.7-7. Also, how does one get to the qemu console with the vnc? Currently you need to either apply this patch: http://www.zabor.org/balrog/qemu-curses-etc.patch which will add switching consoles the SDL way (ctrl-alt-number) or run qemu with -monitor stdio, and the monitor will then accept commands from the terminal in which qemu was started. The vnc server also seems to occasionally send invalid vnc packets, and the screen resize does not seem to work. Included is a log of starting up and exiting because a bad message.. The bad message problem occurs with Chicken of the VNC on MacOS X as well. VNC viewer version 3.3.7 - built Sep 25 2004 21:02:46 Copyright (C) 2002-2003 RealVNC Ltd. Copyright (C) 1994-2000 ATT Laboratories Cambridge. See http://www.realvnc.com for information on VNC. VNC server supports protocol version 3.3 (viewer 3.3) No authentication needed Desktop name QEMU Connected to VNC server, using protocol version 3.3 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 and visual, TrueColor, depth 24. Got 256 exact BGR233 colours out of 256 Using BGR233 pixel format: 8 bits per pixel. True colour: max red 7 green 7 blue 3, shift red 0 green 3 blue 6 Throughput 2 kbit/s - changing to Hextile Throughput 2 kbit/s - changing from 8bit Using viewer's native pixel format: 32 bits per pixel. Most significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Rect too large: 69x1 at (705, 577) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Greetings, Andrew -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Troy Benjegerdes [EMAIL PROTECTED] wrote: On Fri, May 05, 2006 at 09:06:20AM -0500, Anthony Liguori wrote: Ben Taylor wrote: I'm seeing quite a few bugs on Qemu 0.8.1 with the vnc feature 1) Sparc based system comes up in distored colors (foreground of a Damn Small linux iso comes up in yellow, instead of white) This is a know problem. qemu doesn't give any indication that the guest is storing pixels in big endian mode. A proper fix is on my TODO list. 2) When it bounces from the initial syslinux text to the grahpical screen, it leaves the text in the top left corner not cleared. (to the boot: at the bottom) Yeah, I've noticed something similar myself. It's on the TODO list (see vnc.c). TightVNC doesn't support the desktop resize encoding. Try RealVNC. I am running the current CVS code and seeing endian color problems with a x86 machine running qemu and a PPC linux machine running xrealvncviewer. This is the debian xvncviewer package version 3.3.7-7. Also, how does one get to the qemu console with the vnc? I usually start qemu with -S -monitor stdio -vnc 0 which gives me a (qemu) prompt on the starting terminal, then I start vnc and then type cont in the monitor window (starting terminal) However, another buglet WRT to vnc that I've found is this. When I do the following from a Solaris/Sparc host, and display on a Solaris/X86 client using vncviewer, I get the following corruption (see attachment Solaris-sparc-qemu-monitor.png) The vnc server also seems to occasionally send invalid vnc packets, and the screen resize does not seem to work. Included is a log of starting up and exiting because a bad message.. The bad message problem occurs with Chicken of the VNC on MacOS X as well. VNC viewer version 3.3.7 - built Sep 25 2004 21:02:46 Copyright (C) 2002-2003 RealVNC Ltd. Copyright (C) 1994-2000 ATT Laboratories Cambridge. See http://www.realvnc.com for information on VNC. VNC server supports protocol version 3.3 (viewer 3.3) No authentication needed Desktop name QEMU Connected to VNC server, using protocol version 3.3 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 and visual, TrueColor, depth 24. Got 256 exact BGR233 colours out of 256 Using BGR233 pixel format: 8 bits per pixel. True colour: max red 7 green 7 blue 3, shift red 0 green 3 blue 6 Throughput 2 kbit/s - changing to Hextile Throughput 2 kbit/s - changing from 8bit Using viewer's native pixel format: 32 bits per pixel. Most significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Rect too large: 69x1 at (705, 577) I am definitely seeing this happen with the Solaris/Sparc host and Solaris/X86 Real vncviewer. Ben Solaris-Sparc-Qemu-monitor.png Description: PNG image ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-0.8.1 and Solaris-10
Ishwar Rattan [EMAIL PROTECTED] wrote: I was able to compile the qemu-cvs code with Taylor's patches applied. I did not see a qemu executable? Is it the same as qemu/aprc-softmmu/qemu-system-sparc? When I try to use it it keeps complaining that it can't load:: /usr/local/share/qemu/proll.elf: No such file or directory qemu: could not load prom '/usr/local/share/qemu/proll.bin' I know I have not installed it in /usr/local as I do not have the privileges but should this file be somewhere in the qemu/* (where it was compiled)? Why don't you try installing it in your home directory, ie ./configure --prefix=/home/myhome/mqemu . Qemu expects things to be installed, even if your debugging things, otherwise you have use a bunch of flags to tell qemu where to find the components. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: Support for multi-file raw images
On Thu, May 11, 2006 at 02:30:45AM -0400, Ryan Lortie wrote: Hello. Attached is a C file (and small patch) to add support for multi-file raw images to QEMU. The rationale (for me at least) is as follows: I use rsync to backup my home directory. The act of starting up QEMU changes a 20GB file on my drive. This causes 20GB of extra copying next time I do backups. If I could split the drive image into smaller parts (maybe 2048 10MB files) then the amount of extra copying is drastically reduced (since only a few of these files are modified). There are definitely other reasons that this may be useful. Have you tried making a read-only 'base' image and using qcow images instead? I'm not convinced that splitting things up is going to help a lot. You might end up writing 1 512 byte block each to 500 files.. in the qcow image case, that is writing 256K, and with 10mb files, that's 5GB. o If the files comprising the device are deleted (for example) while QEMU is running then this is quite bad. Currently this will result in read/write requests returning -1. Maybe it makes sense to panic and cause QEMU to exit. at the very least, the console should print an error. If you can keep all the files open, deleting the file won't be a problem. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Jamie Lokier wrote: Dan Sandberg wrote: Creating a rectangular direct output area in OpenGL is actually like vitualizing a graphics card. That is what X's XF86DGA (Direct Graphics Adapter) feature does. And I believe SDL already supports XF86DGA when in full screen mode. It is updated at native speed Not necessarily. When I tried using mplayer (a video player) with the video output set to use OpenGL, it was the slowest of all options - even slower than writing the images though X11 shared memory with a copy-to-screen bitblt for each frame. But then, OpenGL drivers vary considerably in their performance and quality. and you can select pixelformat for that area independent of the host pixel format and you do not have to be doing any RectangleBlit operation or causing any CPU-load - to my understanding at least. Well, OpenGL does a RectangleBlit each time it redraws the 3d rendering area, doesn't it? If you have hardware accelerated OpenGL support, that shouldn't use much CPU. But then, the same is true for old-fashioned hardware accelerated 2d bitblt, if the pixel format is supported. [...] I am not saying that any of todays possibilities in Qemu should be retired, rather that it could be sort of a new plug-in module for those who want a virtual display adapter with close to native graphic performance and happen to have what is needed in terms of graphic card and drivers. I agree it's worth a look, because it may be faster for some people, and because it provides access to image scaling (potentially hardware assisted), which classic X11 bitblt does not. It might be worth looking at mplayer's OpenGL driver, which does something similar to what Qemu would need. Other X features which can do similar things and may provide equal or better performance are: Xv (used to display video, but generally provides a resizable overlay; may or may not provide a usable pixel format), and Xrender. -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Yes, in the worst case the OpenGL-driver is all software emulation and then it is slow and CPU-consuming. It may also be that some old OpenGL-drivers have to emulate a direct output area by bitblt operations from an off-screen buffer to the on-screen buffer and then there will be no gain, I agree. But technically that's not the only way to do the trick and newer boards should be capable of doing it much smarter without any bitblt operations involved. I still remember my old favorite, the Amiga computer with its unique virtual screens that allowed multiple programs to coexist in the same physical screen, each with its own display buffer, pixel format and all rendering in full speed. That was never done by bitblt-operations, instead much smarter by synchronized on-the-fly switching between multiple display buffers as the electron beam painted the screen. Lets say that you want to set up a 800x600 direct output rectangle with BGR-pixel format inside a 1600x1200 RGB host screen on a modern card with an adequate OpenGL driver. When the screen is painted the DAC's read from the host video buffer (1600x1200) and interpret it as RGB. Somewhere they hit the left boundary of the separate viewport that you have set up and bang, on the fly they switch to reading 800x600-organized data from the other video buffer and interpreting it as BGR. Later on the same video line they hit the right boundary of the separate viewport and bang they switch back to reading from the main buffer and interpreting it as RGB. As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are equally active and equally often updated on the same physical screen - without need for any moving data around, and without any time consuming activity at all taking place as all switches are done on the fly in the background by special hardware (if the board supports this). It is like having two separate physical video boards, each with its own display buffer. Regards Dan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Dan Sandberg wrote: When the screen is painted the DAC's read from the host video buffer (1600x1200) and interpret it as RGB. Somewhere they hit the left boundary of the separate viewport that you have set up and bang, on the fly they switch to reading 800x600-organized data from the other video buffer and interpreting it as BGR. Later on the same video line they hit the right boundary of the separate viewport and bang they switch back to reading from the main buffer and interpreting it as RGB. As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are equally active and equally often updated on the same physical screen - without need for any moving data around, and without any time consuming activity at all taking place as all switches are done on the fly in the background by special hardware (if the board supports this). It is like having two separate physical video boards, each with its own display buffer. Thanks; I didn't know OpenGL had that function as well as 3d rendering. That's what the Xv extension does (X video) - it's to provide an overlay to be used by video players. Xv scales the source image and mixes it with the primary framebuffer in the way you describe. However, Xv is intended for non-RGB colourspace source formats, so may not be suitable for Qemu. I don't know if Xv sometimes can support RGB. Since Xv is supported by many video cards, even old ones without 3d, or without working 3d drivers, I'm surprised that particular OpenGL function isn't commonly implemented with equal performance. -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: Support for multi-file raw images
Hi there, o If the files comprising the device are deleted (for example) while QEMU is running then this is quite bad. Currently this will result in read/write requests returning -1. Maybe it makes sense to panic and cause QEMU to exit. at the very least, the console should print an error. If you can keep all the files open, deleting the file won't be a problem. I think 99% of the software used today assumes nobody deletes its files while it's running and it's not a very bad assumption. QEMU is not particularly verbose about errors in general, but if it was going to check for a deleted file, I think it should rather report an I/O error to the guest than print errors to the console. Greetings, Andrew -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Anyway, many people think of OpenGL as just 3D, but it is extremely competent for 2D (given a good driver). That's where your argument falls down. I wouldn't be surprised if even a crappy OpenGL implementation could beat plain GDI. However I'd guess most OpenGL drivers are optimised for common 3D operations. OpenGL provides a very wide range of functionality, however if you go outside the commonly used (and hence optimized) feature set performance is likely to be fairly poor when compared if optimized routines. standard Windows GDI and 145 ms for the OpenGL 2D-canvas (and its just a standard business computer with no fancy graphic card at all). If GDI was writing directly to video memory and OpenGL was writing to a buffer in system memory that would explain the large difference. I'm not saying OpenGL is necessarily a bad thing, but it's certainly not (yet) what I'd consider good solution. Especially considering that 90% of modern graphics cards don't have any open source OpenGL capable drivers. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] VNC cross-endian failures
The VNC protocol says the server is is supposed to send the data in the format the client wants, however the current implementation sends vnc data in the server native format. What is the best way to fix this? Using -bgr is not right since that will mess up same-endian clients. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: Support for multi-file raw images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Lortie wrote: I use rsync to backup my home directory. The act of starting up QEMU changes a 20GB file on my drive. This causes 20GB of extra copying next time I do backups. OT for qemu, but if you use *rsync*, then only the changed part of the file are copied, not all the file. Rsync was written just for this reason, to avoid copying unneccessary unchanged data. - -- Flavio Visentin GPG Key: http://www.zipman.it/gpgkey.asc There are only 10 types of people in this world: those who understand binary, and those who don't. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEZO45usUmHkh1cnoRAk+iAJ0QsNj0Uz3X6WBexI7tIEXE/7TMhwCgiv4e djj3DV1vfOG+d5qKikqLZfM= =FYVh -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: Support for multi-file raw images
On Fri, 2006-12-05 at 22:21 +0200, Flavio Visentin wrote: OT for qemu, but if you use *rsync*, then only the changed part of the file are copied, not all the file. Rsync was written just for this reason, to avoid copying unneccessary unchanged data. But as soon as the modification stamp changes rsync still needs to scan the entire 20GB file to determine what part has changed. With two separate drives on a local system this takes exactly as long as just copying the entire file. Cheers ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC cross-endian failures
Troy Benjegerdes wrote: The VNC protocol says the server is is supposed to send the data in the format the client wants, however the current implementation sends vnc data in the server native format. What is the best way to fix this? Using -bgr is not right since that will mess up same-endian clients. A fix will be commited ASAP... Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC cross-endian failures
Much better.
I did have one bogon after running xvncview on a big-endian host,
closing it, then starting it on a little-endian host that resulted in
this from realvnc:
Rect too big: 24832x33024 at 8448,16640 exceeds 640x480
main:Rect too big
On Sat, May 13, 2006 at 01:02:47AM +0200, Fabrice Bellard wrote:
Troy Benjegerdes wrote:
The VNC protocol says the server is is supposed to send the data in the
format the client wants, however the current implementation sends vnc
data in the server native format.
What is the best way to fix this? Using -bgr is not right since that
will mess up same-endian clients.
Try the attached patch.
Fabrice.
Index: vnc.c
===
RCS file: /sources/qemu/qemu/vnc.c,v
retrieving revision 1.5
diff -u -w -r1.5 vnc.c
--- vnc.c 3 May 2006 21:18:59 - 1.5
+++ vnc.c 12 May 2006 22:54:21 -
@@ -42,6 +42,14 @@
typedef int VncReadEvent(VncState *vs, char *data, size_t len);
+typedef void VncWritePixels(VncState *vs, void *data, int size);
+
+typedef void VncSendHextileTile(VncState *vs,
+int x, int y, int w, int h,
+uint32_t *last_bg,
+uint32_t *last_fg,
+int *has_bg, int *has_fg);
+
struct VncState
{
QEMUTimer *timer;
@@ -53,12 +61,19 @@
int height;
uint64_t dirty_row[768];
char *old_data;
-int depth;
+int depth; /* internal VNC frame buffer byte per pixel */
int has_resize;
int has_hextile;
Buffer output;
Buffer input;
kbd_layout_t *kbd_layout;
+/* current output mode information */
+VncWritePixels *write_pixels;
+VncSendHextileTile *send_hextile_tile;
+int pix_bpp, pix_big_endian;
+int red_shift, red_max, red_shift1;
+int green_shift, green_max, green_shift1;
+int blue_shift, blue_max, blue_shift1;
VncReadEvent *read_handler;
size_t read_handler_expect;
@@ -130,6 +145,66 @@
}
}
+/* fastest code */
+static void vnc_write_pixels_copy(VncState *vs, void *pixels, int size)
+{
+vnc_write(vs, pixels, size);
+}
+
+/* slowest but generic code. */
+static void vnc_convert_pixel(VncState *vs, uint8_t *buf, uint32_t v)
+{
+unsigned int r, g, b;
+
+r = (v vs-red_shift1) vs-red_max;
+g = (v vs-green_shift1) vs-green_max;
+b = (v vs-blue_shift1) vs-blue_max;
+v = (r vs-red_shift) |
+(g vs-green_shift) |
+(b vs-blue_shift);
+switch(vs-pix_bpp) {
+case 1:
+buf[0] = v;
+break;
+case 2:
+if (vs-pix_big_endian) {
+buf[0] = v 8;
+buf[1] = v;
+} else {
+buf[1] = v 8;
+buf[0] = v;
+}
+break;
+default:
+case 4:
+if (vs-pix_big_endian) {
+buf[0] = v 24;
+buf[1] = v 16;
+buf[2] = v 8;
+buf[3] = v;
+} else {
+buf[3] = v 24;
+buf[2] = v 16;
+buf[1] = v 8;
+buf[0] = v;
+}
+break;
+}
+}
+
+static void vnc_write_pixels_generic(VncState *vs, void *pixels1, int size)
+{
+uint32_t *pixels = pixels1;
+uint8_t buf[4];
+int n, i;
+
+n = size 2;
+for(i = 0; i n; i++) {
+vnc_convert_pixel(vs, buf, pixels[i]);
+vnc_write(vs, buf, vs-pix_bpp);
+}
+}
+
static void send_framebuffer_update_raw(VncState *vs, int x, int y, int w,
int h)
{
int i;
@@ -139,7 +214,7 @@
row = vs-ds-data + y * vs-ds-linesize + x * vs-depth;
for (i = 0; i h; i++) {
- vnc_write(vs, row, w * vs-depth);
+ vs-write_pixels(vs, row, w * vs-depth);
row += vs-ds-linesize;
}
}
@@ -162,35 +237,26 @@
#include vnchextile.h
#undef BPP
+#define GENERIC
+#define BPP 32
+#include vnchextile.h
+#undef BPP
+#undef GENERIC
+
static void send_framebuffer_update_hextile(VncState *vs, int x, int y, int
w, int h)
{
int i, j;
int has_fg, has_bg;
uint32_t last_fg32, last_bg32;
-uint16_t last_fg16, last_bg16;
-uint8_t last_fg8, last_bg8;
vnc_framebuffer_update(vs, x, y, w, h, 5);
has_fg = has_bg = 0;
for (j = y; j (y + h); j += 16) {
for (i = x; i (x + w); i += 16) {
- switch (vs-depth) {
- case 1:
- send_hextile_tile_8(vs, i, j, MIN(16, x + w - i), MIN(16, y + h
- j),
- last_bg8, last_fg8, has_bg, has_fg);
- break;
- case 2:
- send_hextile_tile_16(vs, i, j, MIN(16, x + w - i), MIN(16, y +
h - j),
- last_bg16, last_fg16, has_bg, has_fg);
- break;
- case 4:
- send_hextile_tile_32(vs, i, j,
[Qemu-devel] PATCH: enable samba for Solaris
This patch is to allow the onboard samba configuration in qemu to correctly start the samba server on Solaris (It's in a different location than a normal linux system). Bendiff -ruN qemu-orig/vl.c qemu/vl.c --- qemu-orig/vl.c 2006-05-03 18:02:44.0 -0400 +++ qemu/vl.c 2006-05-12 20:48:32.642704000 -0400 @@ -2496,8 +2496,13 @@ fclose(f); atexit(smb_exit); +#ifdef HOST_SOLARIS +snprintf(smb_cmdline, sizeof(smb_cmdline), /bin/env LC_ALL=C /usr/sfw/sbin/smbd -s %s, + smb_conf); +#else snprintf(smb_cmdline, sizeof(smb_cmdline), /usr/sbin/smbd -s %s, smb_conf); +#endif slirp_add_exec(0, smb_cmdline, 4, 139); } ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Ben Taylor wrote: Troy Benjegerdes [EMAIL PROTECTED] wrote: On Fri, May 05, 2006 at 09:06:20AM -0500, Anthony Liguori wrote: Ben Taylor wrote: I'm seeing quite a few bugs on Qemu 0.8.1 with the vnc feature 1) Sparc based system comes up in distored colors (foreground of a Damn Small linux iso comes up in yellow, instead of white) This is a know problem. qemu doesn't give any indication that the guest is storing pixels in big endian mode. A proper fix is on my TODO list. 2) When it bounces from the initial syslinux text to the grahpical screen, it leaves the text in the top left corner not cleared. (to the boot: at the bottom) Yeah, I've noticed something similar myself. It's on the TODO list (see vnc.c). TightVNC doesn't support the desktop resize encoding. Try RealVNC. I am running the current CVS code and seeing endian color problems with a x86 machine running qemu and a PPC linux machine running xrealvncviewer. This is the debian xvncviewer package version 3.3.7-7. Also, how does one get to the qemu console with the vnc? I usually start qemu with -S -monitor stdio -vnc 0 which gives me a (qemu) prompt on the starting terminal, then I start vnc and then type cont in the monitor window (starting terminal) However, another buglet WRT to vnc that I've found is this. When I do the following from a Solaris/Sparc host, and display on a Solaris/X86 client using vncviewer, I get the following corruption (see attachment Solaris-sparc-qemu-monitor.png) This is a problem with the VNC protocol itself. The format of the protocol messages depend on the current pixel format which requires that the server and client are in sync with what they think the pixel format is. A problem arises when the client sends a SetPixelFormat message. There is no ack message from the server so the client has to assume that as soon as it sends out the message, the server is now using the new pixel format. RealVNC uses totally synchronous IO routines so in practice, the window for this race condition is small for them. It definitely can occur though and I've reproduced it with a normal VNC server. Since the QEmu VNC code is completely asynchronous, we have a much larger window where this race can occur. The easiest thing to do is avoid the race all together and not have your client use SetPixelFormat frequently. This is really only an issue with the RealVNC client. You can avoid this by doing: vncviewer AutoSelect=0 FullColor=1... A proper fix requires extending the VNC protocol. Of course, this requires that the client support the extension. Regards, Anthony Liguori The vnc server also seems to occasionally send invalid vnc packets, and the screen resize does not seem to work. Included is a log of starting up and exiting because a bad message.. The bad message problem occurs with Chicken of the VNC on MacOS X as well. VNC viewer version 3.3.7 - built Sep 25 2004 21:02:46 Copyright (C) 2002-2003 RealVNC Ltd. Copyright (C) 1994-2000 ATT Laboratories Cambridge. See http://www.realvnc.com for information on VNC. VNC server supports protocol version 3.3 (viewer 3.3) No authentication needed Desktop name QEMU Connected to VNC server, using protocol version 3.3 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 and visual, TrueColor, depth 24. Got 256 exact BGR233 colours out of 256 Using BGR233 pixel format: 8 bits per pixel. True colour: max red 7 green 7 blue 3, shift red 0 green 3 blue 6 Throughput 2 kbit/s - changing to Hextile Throughput 2 kbit/s - changing from 8bit Using viewer's native pixel format: 32 bits per pixel. Most significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Rect too large: 69x1 at (705, 577) I am definitely seeing this happen with the Solaris/Sparc host and Solaris/X86 Real vncviewer. Ben ___ 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
