RE: [Qemu-devel] QEMU 0.8.1 and vnc
We've seen multiple issues with tightVNC, mainly because I don't believe that tightvnc does resize requests at all. Can you try a realvnc client and see if you see the same issues? -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale [EMAIL PROTECTED] Ph: (303)443-3786 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Ben Taylor Sent: Friday, May 05, 2006 6:24 AM To: qemu-devel@nongnu.org Subject: [Qemu-devel] QEMU 0.8.1 and vnc 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) 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) 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 Host is solaris 9/sparc and solaris 11/x86, viewer is tightvnc V 1.2.8 on solaris 11/x86. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] No useful documentation.
Well, calling it worthless is a little harsh. As with all documentation I'm sure it could be made better but, if you read the documentation carefully, it actually tells you what to do. Note that there are instructions on how to boot a CD image (section 3.3 of the user manual, check out the options `-cdrom' and `boot'). Given that you've already found out how to create a blank disk image then all you have to do is boot the install CD for the OS you want, be it Windows or Linux or whatever, and go from there. That should be all you need to do. -- 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 Daniel Carrera Sent: Wednesday, July 05, 2006 2:57 PM To: qemu-devel@nongnu.org Subject: [Qemu-devel] No useful documentation. Hello, I write here because there doesn't seem to be a Bugzilla for qemu and whoever is responsible for the qemu documentation must be here. The documentation is quite worthless. I'm sure you don't like hearing that, but consider that it doesn't actually show the user how get qemu to do what qemu is supposed to di (ie. run a host OS). Ok, it tells me how to create a blank disk image, that's great, but how do I create a disk image with something bootable on it? Sorry, no information on that. I expect that the most typical use case for qemu is running Windows under Linux, so you'd expect to see some documentation for that, right? Nope, none. Sure, there are trouble-shooting tips, but what use are trouble-shooting tips if you can't even get started? I've looked at qemu several times over the past several years. Every time I get excited at the prospect of migrating people to GNU/Linux by letting them run the one windows app they need... and every time I hit a brick wall, as qemu fails to actually do anything useful. Try to take this approach: You are writing to a technically competent user (perhaps a sysadmin) who wants to run Windows under Linux with qemu (perhaps to migrate some of the company computers). He has a Windows install CD, he has qemu installed, and is ready to go. Please write something that this person can use to get Windows running under qemu. Cheers, Daniel. -- http://opendocumentfellowship.org The reasonable man adapts himself to the world; the unreasonable man tries to adapt the world to himself. Therefore all progress depends on unreasonable men. -- George Bernard Shaw ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Anybody working on a USB EHCI driver?
Is anybody working on creating an EHCI driver for the USB subsystem? I have a need to access high speed devices and wanted to find out if I'd be re-inventing the wheel before I start on this. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale [EMAIL PROTECTED] Ph: (303)440-1368 ___ 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] [PATCH]Fix for minor video corruption under Windows
WD- I see the problem here, `patch' got confused because my patch was against a 0.8.0 tree and you applied it to a 0.8.1 tree. You wound up making the change to `cirrus_hook_read_sr', where the Windows driver attempts to read the mode register. The patch is supposed to apply to the routine `cirrus_hook_write_sr', where the video mode is set. I've attached a version of the patch that should apply cleanly against the 0.8.1 tree. (Sorry about the attachment, IT policies force me to use a broken mailer and I can only reply to you with an attachment.) -- 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 WaxDragon Sent: Wednesday, May 10, 2006 8:27 AM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [PATCH]Fix for minor video corruption under Windows I tried out this patch (with CVS, after fixing it) with XP SP2 and 2k3 SP1. It did address the corruption when changing bpp or resolution, but paints the screen white while the UI elements repaint themselves. Just a little disturbing, but I'll get used to it. Also, I had the leave the second chunk in, otherwise XP failed to paint much of the screen upon bootup. Index: hw/cirrus_vga.c === RCS file: /sources/qemu/qemu/hw/cirrus_vga.c,v retrieving revision 1.21 diff -u -r1.21 cirrus_vga.c --- hw/cirrus_vga.c 30 Apr 2006 21:28:36 - 1.21 +++ hw/cirrus_vga.c 10 May 2006 14:08:25 - @@ -1181,6 +1181,17 @@ break; case 0x05: // ??? case 0x07: // Extended Sequencer Mode + /* Win2K seems to assume that the VRAM is set to 0xff +* whenever VGA/SVGA mode changes +*/ +if ((s-sr[0x07] ^ *reg_value) CIRRUS_SR7_BPP_SVGA) +memset(s-vram_ptr, 0xff, s-real_vram_size); +*reg_value = s-sr[0x07]; +#ifdef DEBUG_CIRRUS +printf(cirrus: handled outport sr_index %02x, sr_value %02x\n, + reg_index, reg_value); +#endif +break; case 0x08: // EEPROM Control case 0x09: // Scratch Register 0 case 0x0a: // Scratch Register 1 WD -- ReactOS is a hub, follow the spokes and you'll immediately find absolutely everything you need to know about Windows. ReactOS is not just software, it's people. kjk_hyperion ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel patch-cirrus-0510.l Description: patch-cirrus-0510.l ___ 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
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
RE: [Qemu-devel] Improper mouse reset handling
Interesting. You're right, the protocol explicitly says that both
`reset' and `set to default' are supposed to disable the mouse. I have
to admit, I was basing my patch on the fact that, in tracing the
commands I received from the X server, I saw a `reset' that was not
followed by an `enable'. I'll have to go back and find out where the
missing `enable' command got dropped or an unexpected `reset' got added.
--
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 Juergen Keil
Sent: Friday, August 05, 2005 3:16 AM
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Improper mouse reset handling
While tracking down a problem with getting X to work with the VNC
version of Qemu I discovered a problem in the way the Qemu mouse
emulation was handling mouse reset commands. Turns out, the
emulation
code is a little over aggressive in dealing with reset
commands for the
mouse. Since there are commands that enable and disable the
mouse the
emulator, quite properly, provides this control. Unfortunately, the
emulator also interprets either a `reset' or `set to
default' command to
also disable the mouse. This is wrong, neither of these commands are
supposed to affect the enabled status of the mouse
Huh?
Can you provide a pointer to a specification that `reset' or `set to
default' must not change the state of Data Reporting
enabled/disabled?
According to URL:http://www.computer-engineering.org/ps2mouse/,
Section Reset Mode, a `reset' command is supposed to set the Data
Reporting to its default value, and the default value is Data
Reporting disabled! That is, qemu's `reset' and `set to default'
implementation appears to be perfectly ok, as it is now.
so that, when X sends
a `reset', no futher mouse data is sent, making it look like
X is hung.
Why does X (the mouse driver?) send mouse resets? Any why doesn't it
enable data reporting afterwards? Isn't this a mouse driver
problem in
your X server?
Btw. in my Solaris x86 PS/2 wheel mouse driver I've always sent an
enable command after sending reset commands to the mouse, like
this:
/*
* reset the mouse (restores to the standard ps/2 mouse protocol),
* probe for (and enable) the wheel mouse protocol, and enable the
* mouse.
*/
if ((error = psm_reset(softstate)) ||
(error = psm_protocol(softstate)) ||
(error = psm_config(softstate)) ||
(error = psm_enable(softstate, 1)))
{
qprocsoff(rq);
return error;
}
___
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] Improper mouse reset handling
While tracking down a problem with getting X to work with the VNC version of Qemu I discovered a problem in the way the Qemu mouse emulation was handling mouse reset commands. Turns out, the emulation code is a little over aggressive in dealing with reset commands for the mouse. Since there are commands that enable and disable the mouse the emulator, quite properly, provides this control. Unfortunately, the emulator also interprets either a `reset' or `set to default' command to also disable the mouse. This is wrong, neither of these commands are supposed to affect the enabled status of the mouse so that, when X sends a `reset', no futher mouse data is sent, making it look like X is hung. The attached patch fixes this problem by having the `reset' or `set to default' commands ignore the enable bit. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale [EMAIL PROTECTED] Ph: 303/440-1368 patch-qemu-0804.l Description: patch-qemu-0804.l ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
