Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Paul Brook wrote: On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote: In order to stop the release of incomplete BGR patches, I am implementing a more complete patch. I am just adding depth = 32 with BGR instead of RGB. If other pixel formats are wanted, you should signal it now. I don't have any paticular favourite pixel formats, but qemu now has [at least] 3 different sets of low-level pixel conversion routines (vga, tcx and pl110). If you're feeling really enthusiastic it would be nice if they could be unified :-) It's one of the things I've been meaning to look at when I've nothing better to do, but haven't got round to yet.. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel 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. My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. Hope someone likes the idea, otherwise I will have to do it myself if I can find some spare time. Dan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH: Solaris/Sparc patch against yesterdays' BGR CVS update
Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> In order to stop the release of incomplete BGR patches, I am
> implementing a more complete patch. I am just adding depth = 32 with BGR
> instead of RGB. If other pixel formats are wanted, you should signal it now.
Fabrice - nice job. The patch works fine. I munged something up when
I was redoing my patches for Solaris sparc so I mistakenly reported a
problem with the patch. I redid them and figured out what I did wrong,
and have validated DSL and Win98SE.
I'm still seeing color munging when using vnc and this patch, but I did
not expect this patch to fix that problem.
Enclosed is the latest version of the qemu solaris/sparc patch, applied
against yesterday's CVS (post BGR update).
Bendiff -ruN qemu-presol-sparc/Makefile qemu/Makefile
--- qemu-presol-sparc/Makefile 2006-04-30 19:54:18.0 -0400
+++ qemu/Makefile 2006-05-11 08:39:01.93155 -0400
@@ -4,6 +4,9 @@
ifdef CONFIG_DARWIN
CFLAGS+= -mdynamic-no-pic
endif
+ifeq ($(ARCH),sparc)
+CFLAGS+=-mcpu=ultrasparc
+endif
LDFLAGS=-g
LIBS=
DEFINES+=-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
diff -ruN qemu-presol-sparc/Makefile.target qemu/Makefile.target
--- qemu-presol-sparc/Makefile.target 2006-05-03 18:02:44.0 -0400
+++ qemu/Makefile.target 2006-05-11 08:39:06.248166000 -0400
@@ -102,6 +102,11 @@
endif
ifeq ($(ARCH),sparc)
+ifeq ($(CONFIG_SOLARIS),yes)
+CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3
+LDFLAGS+=-m32
+OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -fno-omit-frame-pointer -ffixed-i0
+else
CFLAGS+=-m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6
LDFLAGS+=-m32
OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -ffixed-i0
@@ -109,6 +114,7 @@
# -static is used to avoid g1/g3 usage by the dynamic linker
LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc.ld -static
endif
+endif
ifeq ($(ARCH),sparc64)
CFLAGS+=-m64 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6
diff -ruN qemu-presol-sparc/cpu-exec.c qemu/cpu-exec.c
--- qemu-presol-sparc/cpu-exec.c 2006-04-27 17:05:14.0 -0400
+++ qemu/cpu-exec.c 2006-05-11 08:39:41.49382 -0400
@@ -253,7 +253,7 @@
uint32_t *saved_regwptr;
#endif
#endif
-#ifdef __sparc__
+#if defined(__sparc__) && !defined(HOST_SOLARIS)
int saved_i7, tmp_T0;
#endif
int ret, interrupt_request;
@@ -323,7 +323,7 @@
#if defined(reg_T2)
saved_T2 = T2;
#endif
-#ifdef __sparc__
+#if defined(__sparc__) && !defined(HOST_SOLARIS)
/* we also save i7 because longjmp may not restore it */
asm volatile ("mov %%i7, %0" : "=r" (saved_i7));
#endif
@@ -447,7 +447,7 @@
T0 = 0; /* force lookup of first TB */
for(;;) {
-#ifdef __sparc__
+#if defined(__sparc__) && !defined(HOST_SOLARIS)
/* g1 can be modified by some libc? functions */
tmp_T0 = T0;
#endif
@@ -467,7 +467,7 @@
do_interrupt(intno, 0, 0, 0, 1);
/* ensure that no TB jump will be modified as
the program flow was changed */
-#ifdef __sparc__
+#if defined(__sparc__) && !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -486,7 +486,7 @@
env->error_code = 0;
do_interrupt(env);
env->interrupt_request &= ~CPU_INTERRUPT_HARD;
-#ifdef __sparc__
+#if defined(__sparc__) && !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -497,7 +497,7 @@
env->error_code = 0;
do_interrupt(env);
env->interrupt_request &= ~CPU_INTERRUPT_TIMER;
-#ifdef __sparc__
+#if defined(__sparc__) && !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -516,7 +516,7 @@
env->error_code = 0;
do_interrupt(env);
env->interrupt_request &= ~CPU_INTERRUPT_HARD;
-#ifdef __sparc__
+#if defined(__sparc__) && !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -534,7 +534,7 @@
env->interrupt_request &= ~CPU_INTERRUPT_HARD;
do_interrupt(env->interrupt_index);
env->interrupt_index = 0;
-#ifdef __sparc__
+#if defined(__sparc__) && !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -565,7 +565,7 @@
env->interrupt_request &= ~CPU_INTERRUPT_EXITTB;
/* ensure that no TB jump will be modified as
the program flow was changed */
-#ifdef __sparc__
+#if defined(__sparc__) && !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -633,7 +633,7 @@
lookup_symbol(tb->pc));
}
#endif
-#ifdef __sparc__
+#if defin
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Am Donnerstag, 11. Mai 2006 15:04 schrieb Dan Sandberg: > Are you using an OpenGL directdraw surface for the graphics emulation in > Qemu? Qemu is using SDL, as this is a very portable library/framework. I'm not sure, if SDL uses DirectX on Win32, but I'd rather think it does not. Of course one might want to check this and maybe have a look at the SDL mail lists, if DirectX was discussed there. > My suggestion would be to write a frontend similar to VMware's for Qemu > in Lazarus. Why Lazarus? > 1. The fantastic GLscene is available for Lazarus making > OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ > 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and > directly compileable for most operating systems without need for > modifications. There already are a few projects for external qemu GUIs, but for an internal GUI it would have to be done in SDL, too, as to not introduce further dependencies. Please keep in mind that qemu is ported to many platforms and therefor the code would have to be very portable anyways. If you're keen on doing a GUI in Lazarus, feel free to do so, but have a look at the ml archive and some existing GUIs first. With regards, Jan Simons ___ 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: Paul Brook wrote: On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote: In order to stop the release of incomplete BGR patches, I am implementing a more complete patch. I am just adding depth = 32 with BGR instead of RGB. If other pixel formats are wanted, you should signal it now. I don't have any paticular favourite pixel formats, but qemu now has [at least] 3 different sets of low-level pixel conversion routines (vga, tcx and pl110). If you're feeling really enthusiastic it would be nice if they could be unified :-) It's one of the things I've been meaning to look at when I've nothing better to do, but haven't got round to yet.. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Hi, some comments on your suggestions: 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 Not sure how much faster it is on Windows; currently Qemu uses plain SDL for drawing which probably uses DirectDraw under Windows. However, AFAIK under Linux SDL is not hardware accelerated in most cases, while OpenGL could give hardware acceleration. 2: It gives full control over things like window or fullscreen mode in any (almost) resolution and color depth. AFAIK the windowing/fullscreen stuff is not done by OpenGL itself, but by some external library; SDL offers this functionality, GLUT is another possibility, and apparently the GlScene lib you mentioned does this as well. 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. Basically, that sounds like a good idea to me. My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. Hope someone likes the idea, otherwise I will have to do it myself if I can find some spare time. Dan Before you start working on this, I have some suggestions as well: Is the drawing part really a performance bottleneck? And will this really be improved by changing the drawing functions, or wouldn't a better graphics card emulation give much more improvements? What does a profiler say about this? I seem to recall that in most cases, SDL doesn't slow down performance in Qemu. It might be interesting to see how much the new RGB<->BGR conversions costs, though. Another thing that I think is important is that not all computers have OpenGL acceleration. And at least on Linux, software OpenGL rendering is quite slow, so a port to OpenGL would probably be a huge drawback for some people. If OpenGL is really worth the trouble, one could add OpenGL rendering so that people can still use the "old" way of drawing if no hardware acceleration is available. A GUI frontend would be quite nice, I think. So far several people have submitted (quite useful) patches for this, but nothing more has happened in that direction. Not sure what is required for a GUI that will be integrated into Qemu finally... Thanks, Oliver ___ 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
On Thu, May 11, 2006 at 04:57:23PM +0200, Jan Marten Simons wrote: > Am Donnerstag, 11. Mai 2006 15:04 schrieb Dan Sandberg: > > Are you using an OpenGL directdraw surface for the graphics emulation in > > Qemu? > > Qemu is using SDL, as this is a very portable library/framework. I'm not > sure, > if SDL uses DirectX on Win32, but I'd rather think it does not. Of course one > might want to check this and maybe have a look at the SDL mail lists, if > DirectX was discussed there. He is askinng about OpenGL, not DirectX. Dunno if it is the default, but iirc SDL supports OpenGL on Windows. > > > My suggestion would be to write a frontend similar to VMware's for Qemu > > in Lazarus. Why Lazarus? > > 1. The fantastic GLscene is available for Lazarus making > > OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ > > 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and > > directly compileable for most operating systems without need for > > modifications. SDL has support for OpenGL builtin, so qemu should be able to use that with only a few modifications. > > There already are a few projects for external qemu GUIs, but for an internal > GUI it would have to be done in SDL, too, as to not introduce further > dependencies. No one has tried to make an SDL Gui for qemu. SDL guis tend to be ugly in general. There is a well supported GUI for OS X called Q, and there are 2 versions of qemu that use a GTK GUI internally. > Please keep in mind that qemu is ported to many platforms and > therefor the code would have to be very portable anyways. Supporting something that runs (or can run) on top of X would catch most of the platforms that qemu runs on, the only ones I can think of that would need their own stuff would be Windows and OS X (well OS X has an X server but users prefer a native GUI there). > If you're keen on doing a GUI in Lazarus, feel free to do so, but have a look > at the ml archive and some existing GUIs first. > > With regards, > Jan Simons > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] -smb switch and national character support
With the default settings, using -smb switch causes the national characters in shared files' names to display incorrectly. I've put together a simple patch (attached for reference only) that addresses this issue. As this feature looks useful for me, I thought it would be nice to include such functionality in qemu. The idea is simple - using -smb-dos-charset and -smb-unix-charset switches to archieve the desired goal. Example usage: qemu -smb-dos-charset cp852 -smb-unix-charset iso8859-2 Also, another switch, named for example -smb-read-only, would be useful. As the number of options is growing, it might be better to introduce another form: -qemu-options dos-charset=cp852,read-only,... Or, making a more general approach: -smb directory[,options] As it is with -net and other switches. However, the charset settings should be put in the [global] section. We can introduce another switch or use a simple and nice hack: -smb global,charset=cp852,... Also, this form of -smb switch would allow to inject _any_ strings into the smb.conf file, making it far more flexible. As always, comments are welcome before I start to work on the code - I don't want to make a patch that would be rejected. Kosma diff -urp qemu-0.7.2/vl.c qemu-0.7.2-pl/vl.c --- qemu-0.7.2/vl.c 2005-09-04 19:11:31.0 +0200 +++ qemu-0.7.2-pl/vl.c 2006-01-17 00:08:50.0 +0100 @@ -1605,6 +1605,9 @@ void net_slirp_smb(const char *exported_ "log file=%s/log.smbd\n" "smb passwd file=%s/smbpasswd\n" "security = share\n" + "dos charset=CP852\n" + "unix charset=ISO8859-2\n" + "display charset=ISO8859-2\n" "[qemu]\n" "path=%s\n" "read only=no\n" ___ 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: 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. My own feeling is that a smarter thing to do is to pass the VGA ops to another program to actually do the rendering. I think a GUI that used VNC to interact with QEmu would be a very good start. localhost VNC performance seems good enough to me that this should be a reasonable approach. Hardware scaling would, perhaps, be a useful feature of using OpenGL. Unfortunately, OpenGL is not available enough widely to make this practical in my mind. I'd rather devote the same effort to fast software scaling (via SIMD instructions). Regards, Anthony Liguori My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. Hope someone likes the idea, otherwise I will have to do it myself if I can find some spare time. Dan ___ 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] qemu-0.8.1 and Solaris-10
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)? -ishwar ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw mips_r4k.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/05/11 21:15:08 Modified files: hw : mips_r4k.c Log message: mips bios loading fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.16&tr2=1.17&r1=text&r2=text ___ 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: 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
Re: [Qemu-devel] qemu/hw mips_r4k.c
Fabrice Bellard wrote: > CVSROOT: /sources/qemu > Module name: qemu > Branch: > Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/05/11 21:15:08 > > Modified files: > hw : mips_r4k.c > > Log message: > mips bios loading fix > > CVSWeb URLs: > http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.16&tr2=1.17&r1=text&r2=text Why is this correct? I would have expected moving parts of the initialisation in front of the file loads would be the right fix. (Those parts which aren't supposed to be done by the BIOS.) Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw vga_template.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/05/11 21:54:44 Modified files: hw : vga_template.h Log message: BGR_FORMAT fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/vga_template.h.diff?tr1=1.12&tr2=1.13&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for ne2000.c
OK for (2).
For (1) It would be good to find the exact behaviour of the NE2000 card.
Maybe ENISR_RX remain set as long are there are packets in the buffer ?
Otherwise your fix is a workaround to correct a bug in the OS driver...
Fabrice.
Han, Zhu wrote:
> Any comments for this patch?
>
> Best Regards,
> hanzhu
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Han, Zhu
> Sent: 2006年5月9日 12:27
> To: qemu-devel@nongnu.org
> Subject: [Qemu-devel] patch for ne2000.c
>
> Hi, All!
>
> I'm a developer working on xen project! It's well known that xen has
> adopted a lot of codes and features from QEMU, especially the Device
> Mode Part!
>
> I fix a bug for ne2000 device emulation code in XEN and I expect it to
> be a potential bug for QEMU, either! Because you are all device mode
> experts, I submit this patch to you at first in order to ask you to
> review my patch.
>
> Several notes:
> 1) Because XEN use event driven mechanism in the main_loop(), irq may be
> missed due to the rather high speed and large file! For example, the
> ne2000_receive will filled up with the buffer and set up the ENISR_RX
> signal, however, the driver could ack and clear the ENISR_RX signal due
> to it could only handle a certain amount of packets once in it's
> interrupt handling routine! The consequence for this specific steps is
> the netcard buffer is full but it never resend the ENISR_RX signal, at
> the last, the netcard will be halted! This problem could be rather rare
> for QEMU. Anyway, it's a potential bug.
> 2) Many of the ne2000 spec said we should set boundary register should
> be set to indicate the last receive buffer page the host has read, and
> the driver in linux follows this guideline. So, we boundary == index,
> the buffer for the netcard is full and we can't write any packets into
> this buffer. This minor fix could prevent the ne2000 emulated card from
> overflow and destroying the previous received packet page! This problem
> could also be rare for QEMU since it could happen only under extreme
> circumstance!
>
> Any feedbacks and comments will be appreciated!
>
> --- qemu-snapshot-2006-05-07_23\hw\ne2000.c Mon May 08 16:13:49 2006
> +++ ./ne2000.cMon May 08 16:57:33 2006
> @@ -159,9 +159,19 @@
> }
> }
>
> +static int ne2000_buffer_full(NE2000State *s);
> static void ne2000_update_irq(NE2000State *s)
> {
> int isr;
> +
> +if(ne2000_buffer_full(s)
> +&& !(s->isr & ENISR_RX)){
> + /* The freeing space is not enough, tell the ne2k driver
> + * to fetch these packets!
> + */
> +s->isr |= ENISR_RX;
> +}
> +
> isr = (s->isr & s->imr) & 0x7f;
> #if defined(DEBUG_NE2000)
> printf("NE2000: Set IRQ line %d to %d (%02x %02x)\n",
> @@ -206,7 +216,10 @@
>
> index = s->curpag << 8;
> boundary = s->boundary << 8;
> -if (index < boundary)
> +if (index <= boundary)
> + /* when index == boundary, we should assume
> + * the buffer is full instead of empty!
> + */
> avail = boundary - index;
> else
> avail = (s->stop - s->start) - (index - boundary);
>
> Best Regards,
> hanzhu
>
>
> ___
> 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]Fix for minor video corruption under Windows
Hi, I think the proper fix must be done in the BIOS (set VRAM to 0xFF at cirrus mode init). I made a patch for that but I must test it a little more. Fabrice. Dugger, Donald D wrote: Leo- Yeah, I started there but it turns out there are multiple reasons why that is the wrong place to fix things: 1) `hw/vga.c' only knows about resolution changes, the bug also appears if you change the pixel size, e.g. 24 bpp to 16 bpp. 2) Technically, because of the lazy screen update, your change would be too late. To improve performance the vga code is only called periodically, not after every VRAM change. It is theoretically possible for the target to change video mode, assume VRAM got reset, do a bitblt from non-visible VRAM to visible VRAM and then have the `hw/vga.c' code get called, overwriting the changes done to visible VRAM. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: (303)440-1368 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Leonardo E. Reiter Sent: Tuesday, May 09, 2006 2:29 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [PATCH]Fix for minor video corruption under Windows Donald... thanks... I actually posted a patch to fix this sometime ago, but your patch seems more thorough and probably more correct. Just FYI, I attached my patch again. I will test your patch as well. Thanks again, Leo Reiter Donald D. Dugger wrote: If you change the video resolution while running a Windows XP image such that it uses fewer bytes of VRAM (either by using fewer bytes per pixel or by lowering the resolution) then some window backgrounds will become corrupted. This happens because the Windows XP Cirrus Logic driver assumes that VRAM is initialized to 0xff whenever the video mode switches between VGA and SVGA. This patch fixes this problem by resetting VRAM whenever a VGA/SVGA mode switch occurs. Signed-off-by: [EMAIL PROTECTED] -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing that means Business Main: +1 512 339 7979 Fax: +1 512 532 6501 http://www.win4lin.com ___ 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] qemu/hw mips_r4k.c
Thiemo Seufer wrote: Fabrice Bellard wrote: CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/05/11 21:15:08 Modified files: hw : mips_r4k.c Log message: mips bios loading fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.16&tr2=1.17&r1=text&r2=text Why is this correct? I would have expected moving parts of the initialisation in front of the file loads would be the right fix. (Those parts which aren't supposed to be done by the BIOS.) The "bug" I fixed was that the BIOS could not be used without specifying "-kernel x". Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] [PATCH]Fix for minor video corruption under Windows
Fabrice- Well, I've been assuming that the Windows driver doesn't call the BIOS to do a video mode switch (that seems like a silly thing to do and without sources I hate having to guess at things) but this is Windows so I guess it's possible. If you've got a BIOS patch I'd love to try it out when you're ready. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: (303)440-1368 >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] >] On Behalf Of Fabrice Bellard >Sent: Thursday, May 11, 2006 4:48 PM >To: qemu-devel@nongnu.org >Subject: Re: [Qemu-devel] [PATCH]Fix for minor video >corruption under Windows > >Hi, > >I think the proper fix must be done in the BIOS (set VRAM to 0xFF at >cirrus mode init). I made a patch for that but I must test it >a little more. > >Fabrice. > >Dugger, Donald D wrote: >> Leo- >> >> Yeah, I started there but it turns out there are multiple reasons why >> that is the wrong place to fix things: >> >> 1) `hw/vga.c' only knows about resolution changes, the bug >also appears >> if you change the pixel size, e.g. 24 bpp to 16 bpp. >> >> 2) Technically, because of the lazy screen update, your >change would be >> too late. To improve performance the vga code is only called >> periodically, not after every VRAM change. It is >theoretically possible >> for the target to change video mode, assume VRAM got reset, >do a bitblt >> from non-visible VRAM to visible VRAM and then have the >`hw/vga.c' code >> get called, overwriting the changes done to visible VRAM. >> >> -- >> Don Dugger >> "Censeo Toto nos in Kansa esse decisse." - D. Gale >> [EMAIL PROTECTED] >> Ph: (303)440-1368 >> >> >>>-Original Message- >>>From: [EMAIL PROTECTED] >>>[mailto:[EMAIL PROTECTED] >>>] On Behalf Of Leonardo E. Reiter >>>Sent: Tuesday, May 09, 2006 2:29 PM >>>To: qemu-devel@nongnu.org >>>Subject: Re: [Qemu-devel] [PATCH]Fix for minor video >>>corruption under Windows >>> >>>Donald... >>> >>>thanks... I actually posted a patch to fix this sometime >ago, but your >>>patch seems more thorough and probably more correct. Just FYI, I >>>attached my patch again. I will test your patch as well. >>> >>>Thanks again, >>> >>>Leo Reiter >>> >>>Donald D. Dugger wrote: >>> If you change the video resolution while running a Windows >>> >>>XP image such that >>> it uses fewer bytes of VRAM (either by using fewer bytes per >>> >>>pixel or by >>> lowering the resolution) then some window backgrounds will >>> >>>become corrupted. >>> This happens because the Windows XP Cirrus Logic driver >>> >>>assumes that VRAM is >>> initialized to 0xff whenever the video mode switches between >>> >>>VGA and SVGA. >>> This patch fixes this problem by resetting VRAM whenever a >>> >>>VGA/SVGA mode switch >>> occurs. Signed-off-by: [EMAIL PROTECTED] >>> >>>-- >>>Leonardo E. Reiter >>>Vice President of Product Development, CTO >>> >>>Win4Lin, Inc. >>>Virtual Computing that means Business >>>Main: +1 512 339 7979 >>>Fax: +1 512 532 6501 >>>http://www.win4lin.com >>> >> >> >> >> ___ >> 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
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
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? 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 AT&T 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
[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
