From: "andrzej zaborowski" <balrogg@gmail.com>
To: qemu-devel@nongnu.org, James Pellow <james@alentdesignsolutions.com>
Subject: Re: [Qemu-devel] [PATCH] VMware SVGA II emulation
Date: Sun, 13 May 2007 16:10:18 +0200 [thread overview]
Message-ID: <fb249edb0705130710n65fc5215k9bc42397a57bf639@mail.gmail.com> (raw)
In-Reply-To: <200705031040.01616.james@alentdesignsolutions.com>
Hi,
On 03/05/07, James Pellow <james@alentdesignsolutions.com> wrote:
> Hi Andrew and others working on vmware hardware,
>
> I noticed the small patch made recently to the vmwarevga hardware in qemu, so
> I decided to test it again. Here is what I am getting on my tests:
>
> Host: Kubuntu 7.04
> Qemu: CVS from May third.
> Guest: Windows 2000
> Driver: From VMware 5.5.3 build 34685
> CPU: Opteron 165 dual core.
> Guest Memory: 256M
> Host Memory: 1G
> KQemu: No
>
> pellja@cherrypit:~/qemu$ qemu -hda win2k.raw -cdrom windows.iso -boot c -m
> 256 -vmwarevga
> Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such
> file or directory
> vmsvga_value_write: guest runs Windows 2000.
> vmmouse: unknown command 1e
> vmmouse: unknown command 1e
> vmmouse: unknown command 1e
> vmmouse: unknown command 1e
> vmmouse: unknown command 1e
> vmmouse: unknown command 1e
> vmmouse: unknown command 1e
> vmmouse: unknown command 1e
>
> The initial portion of the boot (text mode bars advancing at the bottom of the
> screen) works perfectly, then when it switches to graphics mode (Win2k splash
> screen with small progress bar below) I actually see the progress bar, but
> only the blue channel and it is disproportionately large. Once the progress
> bar completes and windows 2k kernel is fully booted, I get small vertical
> blue bars covering the entire screen (see screenshot). It appears like qemu
> is no longer responding to paint messages from the window manager because it
> will not repaint, again as you can see from the screenshot.
>
> I'm happy to gather any additional information that may be helpful, and to
> look at the code if you point me in the right direction. I imagine the best
> documentation is the source code for the vmware X drivers.
I digged out an old Windows Server 2003 (Enterprise Edition) install
and played with it a bit. As soon as I booted it with "-vmwarevga" it
autodetected the VMware SVGA II graphics adapter and installed a
microsoft-certified-signed-blessed driver which (surprisingly) came
with Windows - so I haven't tested with VMware Tools and their driver
at all.
It turned out the windows driver initialises the card in kindof the
opposite order to Xorg driver, which I thought was illegal by my
reading of the specs but apparently I misinterpreted this part. After
de-illegalising it, Windows immediately started displaying correctly
and I didn't see any other breakage except red and green components
being exchanged in 24/32 bit modes (I only test 16bpp before). I was
especially surprised that this driver didn't use any undocumented
commands - only the same subset that the Xorg driver used. In the
display properties dialog it reports only the colour depth that the
host is using and all the standard screen resolutions plus the maximum
resolution allowed by the hardware - so if you needed to use a
non-standard resolution, like 2560x1770 that you mentioned, you'll
have to edit the lines
#define SVGA_MAX_WIDTH 2360
#define SVGA_MAX_HEIGHT 1770
in hw/vmware_vga.c because we don't have SDL window resizing at the
moment (I'm wondering if the windows video driver manages that part -
if so we could easily add it with Anthony Liguori's sdl.c hacks and
the web page that had all of the VMware special io ports reverse
engineered). Also make sure the video ram size (vl.h line 903) is
enough to hold the framebuffer in given bit depth - if you don't do
that, windows will go blue screen when you change the resolution.
Windows didn't use the hardware mouse cursor but it did use hardware
rectangle filling and copying. It seems the svga driver also probed
for vmmouse for some reason (but using an undocumented command) -
would be nice to get this working too.
Here's a screenshot of Microsoft Windows 2003 running at
6400x4800x32bits with all of the bling enabled:
http://www.numenor.art.pl/balrog/screen-qemu-vmsvga-windows.jpeg (hard
to see the bling because of compression)
I couldn't get it to display non-tiled desktop background - apparently
it was running out of memory during the scaling and displayed all
black background. It worked at 4000x3000 though.
Cheers,
Andrzej
next prev parent reply other threads:[~2007-05-13 14:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200703121949.15035.james@alentdesignsolutions.com>
[not found] ` <200703190837.35544.james@alentdesignsolutions.com>
[not found] ` <fb249edb0703190949y1a59d0bbx9770e46d358fb5ae@mail.gmail.com>
2007-05-03 17:40 ` [Qemu-devel] [PATCH] VMware SVGA II emulation James Pellow
2007-05-13 14:10 ` andrzej zaborowski [this message]
2007-03-11 14:48 andrzej zaborowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb249edb0705130710n65fc5215k9bc42397a57bf639@mail.gmail.com \
--to=balrogg@gmail.com \
--cc=james@alentdesignsolutions.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).