Re: building vgabios-stdvga.bin
Hi,
> I don't know if this is the right place to make this suggestion,
> but it would be nice if this version could make it into the
> qemu-kvm distribution.
> Do you know what the real constraints are? Do you know if they're
> imposed by the vgabios driver, the VNC module, or the guest
> operating system (Windows 7 in this case)?
vnc works with 16x16 internally, so a multiple of 16 should be fine.
Reminds me of a bug, I've trapped into this before, digging ...
Patch attached. Seems to be still not applied, has been on the
qemu-devel list several times already :-(
HTH,
Gerd
commit a22fe41d90d484a68317e0ac46785611afab545f
Author: Gerd Hoffmann
Date: Mon Jun 14 12:28:23 2010 +0200
Fix vnc memory corruption with width = 1400
vnc assumes that the screen width is a multiple of 16 in several places.
If this is not the case vnc will overrun buffers, corrupt memory, make
qemu crash.
This is the minimum fix for this bug. It makes sure we don't overrun the
scanline, thereby fixing the segfault. The rendering is *not* correct
though, there is a black border at the right side of the screen, 8
pixels wide because 1400 % 16 == 8.
Signed-off-by: Gerd Hoffmann
diff --git a/ui/vnc.c b/ui/vnc.c
index e85ee66..afbf82c 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2445,7 +2445,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd)
guest_ptr = guest_row;
server_ptr = server_row;
-for (x = 0; x < vd->guest.ds->width;
+for (x = 0; x + 15 < vd->guest.ds->width;
x += 16, guest_ptr += cmp_bytes, server_ptr += cmp_bytes) {
if (!test_and_clear_bit((x / 16), vd->guest.dirty[y]))
continue;
Re: building vgabios-stdvga.bin
>> With this questionable version of dev86, I went back to the kvm/vgabios >> directory and tried to build there again. Much to my surprise, it >> actually ran, and built 4 variants on VGABIOS-lgpl-latest.bin... >> Cool, says I, now what do I do with these? I did the only thing >> I could think of, and installed VGA-lgpl-latest.bin as > > Almost correct. You need VGABIOS-lgpl-latest.stdvga.bin That sounds great, but unfortunately, the build didn't create that one. It created the following: VGABIOS-lgpl-latest.bin VGABIOS-lgpl-latest.cirrus.bin VGABIOS-lgpl-latest.cirrus.debug.bin VGABIOS-lgpl-latest.debug.bin > Thats the one qemu is using. Also available from > http://git.qemu.org/?p=vgabios.git;a=summary I pulled this version down. Indeed, it does build several additional versions, including stdvga. Hurray! I don't know if this is the right place to make this suggestion, but it would be nice if this version could make it into the qemu-kvm distribution. Now, if I may add a few more questions... I've been experimenting with adding some special-purpose resolutions, and I've had some rather mixed success. I've found that I get varying results depending on the width and color depth I use. For example, with 32-bit color depth, if I use a width of 2560, it works perfectly, but if I use 2556, the screen only resizes vertically to reflect the new resolution, and the screen fills with garbage. I thought that perhaps it needs an integer multiple of some power of two, so I started backing it off by progressively larger powers of two. At a width of 2552, the guest crashes completely. At 2544, 2528, 2496, and 2432, it works, but I get some very odd artifacts, both in the mouse cursor and in places where the mouse cursor has been recently. If I bring it all the way down to 2304 (nearest multiple of 256), everything seems to work properly again. At 24-bit color depth, I get better results. 2556 is still garbage, but 2552 and below now work just fine. (Actually, 2552 crashed once, but I think maybe I accidentally clicked on 32-bit color instead of 24. I hope so, anyway) Do you know what the real constraints are? Do you know if they're imposed by the vgabios driver, the VNC module, or the guest operating system (Windows 7 in this case)? And perhaps most importantly, is this a bug that can be fixed? I can live with needing a multiple of 8, but 256 seems a little extreme (and unlikely, given that 800x600 works). It would be nice if I could use 32-bit color with my chosen resolution. I'd be happy to go looking for the bug myself, but if you happen to know off the top of your head where to look, or whether it's an impossible dream, that would save me a lot of time. This isn't exactly my normal area of expertise. -- Rick -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Building vgabios-stdvga.bin
Hi, > I noticed that there's a directory, kvm/vgabios, in the distribution > which appears to have source code for the relevant targets. Indeed, > one of the source files there, vbetables-gen.c, seems to be the one > I need to modify to add my new display resolutions. Great. > So naturally, I tried to run a make there, but it wanted to use bcc. Thats the one qemu is using. Also available from http://git.qemu.org/?p=vgabios.git;a=summary > With this questionable version of dev86, I went back to the kvm/vgabios > directory and tried to build there again. Much to my surprise, it > actually ran, and built 4 variants on VGABIOS-lgpl-latest.bin... > Cool, says I, now what do I do with these? I did the only thing > I could think of, and installed VGA-lgpl-latest.bin as Almost correct. You need VGABIOS-lgpl-latest.stdvga.bin > Of course, what this thing really needs is a way for us to configure, > at runtime, the available resolutions. I have no idea how hard that > would be, but we're obviously not there now. There is some work in progress to put the vgabios included in seabios.git into better shape, which hopefully gives us a vgabios which does (a) does not require dev86 to build and (b) is almost completely c code not assembler and thus much easier to hack. There is a communication channel between seabios & qemu already (fw_cfg), that could be used by vgabios too to get non-standard screen resolutions configured at runtime. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Building vgabios-stdvga.bin
Short version of the question: How do I (re)build vgabios-stdvga.bin? Here's why: I want to run a Windows guest with some non-standard customized display resolutions available. In particular, I'm trying to get 2556x1574 and 2556x1414 working (they play well with vnc when I maximize the vnc client window on my actual display machines). I'd settle for 2560x1440, but as long as I'm recompiling, I might as well go for exactly what I want, right? What have I tried? Before I go into the whole saga, since I'm sure most of you won't want to read it, I'd love to be pointed at some kind of a "how to build vgabios" document, if such a thing exists. Or, heck, a pointer to a current source distribution of dev86 would probably go a long way. Really, I'll take anything. Failing that, here's what I tried. Maybe someone can tell me which part I can fix. I downloaded the qemu-kvm sources and built the package. That was very easy, and the newly-created binaries worked just as well as the precompiled binaries I got from the Arch Linux distribution. Unfortunately, this doesn't build the vgabios*.bin files. I noticed that there's a directory, kvm/vgabios, in the distribution which appears to have source code for the relevant targets. Indeed, one of the source files there, vbetables-gen.c, seems to be the one I need to modify to add my new display resolutions. Great. So naturally, I tried to run a make there, but it wanted to use bcc. Some research later, and I find the dev86 package of tools which contains bcc. Unfortunately, I can't find a precompiled version of that, so I downloaded the source code to version 0.16.17 from http://homepage.htlworld.com/robert.debath/dev86/ I'm honestly not sure if this is the right source for this, especially since it appears to be almost 7 years old, but I was unable to find anything more recent. In any case, it doesn't exactly compile cleanly on my machine. First it complains about having no rule for "libc3.a()" (note the parens at the end), eventhough "libc3.a" seems to have been built just fine. Searching the net suggests that there may be problems with my version of make (3.82), but I don't have an easy way of downgrading that. Besides, the error seems to be purely a 'make' problem, as the relevant files are being built. So I tried 'make -k' (still on dev86 here), and it built more stuff, then choked on an include file, 'sys/vm86.h'. First I tried adding -I to CFLAGS to point the build to the version that came with the distribution. That didn't work, claining MAX_INT wasn't being defined. So I made a cheesy symlink, /usr/include/sys/vm86.h pointing to /usr/include/asm/vm86.h, which already existed, ran 'make -k' again, and... surprise! It built. Someone dubious, I nevertheless installed the result. With this questionable version of dev86, I went back to the kvm/vgabios directory and tried to build there again. Much to my surprise, it actually ran, and built 4 variants on VGABIOS-lgpl-latest.bin... Cool, says I, now what do I do with these? I did the only thing I could think of, and installed VGA-lgpl-latest.bin as /usr/local/kvm/share/qemu/vgabios-stdvga.bin, the only vgabios-* file being accessed (going by access times here) when I ran my guest (using 'qemu-system-x86_64 -vga std'). At that point, running my guest worked... rather poorly. It briefly displayed a 640x480 black screen, then showed "Microsoft Corporation" with a "progress" bar (not really a progress bar since the little thumb bounces back and forth normally, giving no indication of actual progress, but you get the idea), then went black again, then froze (or perhaps went into a busy loop -- hard to tell) forever. Now, I realize that more than one part of this whole saga is guesswork, poor procedure, or just plain wrong on my part. I'm hoping someone can tell me a better way. Of course, what this thing really needs is a way for us to configure, at runtime, the available resolutions. I have no idea how hard that would be, but we're obviously not there now. Thanks in advance for any help, suggestions, or pointers at more documentation. Cheers! -- Rick -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
