Re: [Qemu-devel] Make -std-vga the default?
On Wed, 28 Jun 2006 06:30:51 +0100 Paul Brook <[EMAIL PROTECTED]> wrote: > On Wednesday 28 June 2006 02:21, Julian Seward wrote: > > I've been using -std-vga for a couple of weeks now, and it works > > well at least for the guests I've been using (Win2K/XP, Red Hat 9, > > SuSE 10.1). > > Really? My win2k install couldn't do anything useful with -std-vga. > It would only do the very basic 640x480x4 mode. I'm fairly sure win9x > can't do anything useful with straight VGA either. Same here. Also std-vga seemed to be slower than cirrus when I tried it recently on my linux guests, although I haven't actually measured anything. > > Overall it seems to work much better than the default 5446 Julian, in what way is std-vga better than the cirrus emulation? > > simulation and it seems to me that non-developer users, who are > > presumably the larger fraction of the user base, would benefit from > > having -std-vga as the default. The "it just works" property is > > important for new users, and -std-vga has more of that than the > > 5446 just at the moment. > > In my experience the Cirrus emulation "just works", and is supported > by pretty much every OS out the box. AFAIK Windows earlier than XP > doesn't needs additional 3rd party drivers to support anonymous VESA > hardware. Seconded - the default should be the one best supported by guests out of the box. As it stands, that's cirrus. > > Paul > -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu kbd emulation
Hi!
I wanted to correct qemu emulation of keyboard under DOS as
guest OS, so I started with simple pascal program to check
what happen on guest DOS (and DOS) when I press up/down/left/right
keys.
The program was:
-- BEGIN test.pas --
program time; {$M 2048,0,0}
uses crt, dos;
var OldKeyInt : procedure;
procedure NewKeyInt; interrupt;
begin
write(Port[$60]); write(' ')
inline($9c); OldKeyInt;
end;
begin
getintvec($9, addr(OldKeyInt));
setintvec($9, @NewKeyInt);
keep(0);
end.
-- END test.pas --
and it look that qemu does not generate some codes before
pressing and after releasing arrow keys. For example pressing
up key on qemu looks like:
224 72 224 200
while without emulation it looks:
224 42 224 72 224 200 224 170.
It's true only for single keystrokes, but good for the
beginning.
So I tried to patch qemu for this and created following patch:
-- BEGIN sdl.patch --
--- sdl.c.old 2006-05-03 20:32:58.0 +
+++ sdl.c 2006-06-28 07:26:14.0 +
@@ -254,14 +254,34 @@
kbd_put_keycode(keycode);
kbd_put_keycode(keycode | 0x80);
return;
+case 0xc8: /* up */
+case 0xd0: /* down */
+case 0xcd: /* right */
+case 0xcb: /* left */
+ if (ev->type != SDL_KEYUP) {
+ kbd_put_keycode(e0);
+ kbd_put_keycode(2a);
+ }
+ break;
}
-
+
/* now send the key code */
if (keycode & 0x80)
kbd_put_keycode(0xe0);
-if (ev->type == SDL_KEYUP)
-kbd_put_keycode(keycode | 0x80);
-else
+
+if (ev->type == SDL_KEYUP) {
+ kbd_put_keycode(keycode | 0x80);
+
+ switch(keycode) {
+case 0xc8: /* up */
+ case 0xd0: /* down */
+case 0xcd: /* right */
+ case 0xcb: /* left */
+ kbd_put_keycode(0xe0);
+ kbd_put_keycode(0xaa);
+ break;
+ }
+} else
kbd_put_keycode(keycode & 0x7f);
}
-- END sdl.patch --
Unfortunatelly results of this patch completely suprised me. After this patch
my test program produces results witch are impossible to produce in normal
situation. Example output for UP key was:
224 224 72 88224 224 170.
What's wrong with this patch? What I'm doing wrong?
Regards,
--
Rafał Cygnarowski
[EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu kbd emulation
Rafał Cygnarowski wrote:
Hi!
I wanted to correct qemu emulation of keyboard under DOS as
guest OS, so I started with simple pascal program to check
what happen on guest DOS (and DOS) when I press up/down/left/right
keys.
The program was:
-- BEGIN test.pas --
program time; {$M 2048,0,0}
uses crt, dos;
var OldKeyInt : procedure;
procedure NewKeyInt; interrupt;
begin
write(Port[$60]); write(' ')
inline($9c); OldKeyInt;
end;
begin
getintvec($9, addr(OldKeyInt));
setintvec($9, @NewKeyInt);
keep(0);
end.
-- END test.pas --
and it look that qemu does not generate some codes before
pressing and after releasing arrow keys. For example pressing
up key on qemu looks like:
224 72 224 200
while without emulation it looks:
224 42 224 72 224 200 224 170.
It's true only for single keystrokes, but good for the
beginning.
So I tried to patch qemu for this and created following patch:
-- BEGIN sdl.patch --
[snipped patch]
-- END sdl.patch --
Unfortunatelly results of this patch completely suprised me. After this patch
my test program produces results witch are impossible to produce in normal
situation. Example output for UP key was:
224 224 72 88224 224 170.
What's wrong with this patch? What I'm doing wrong?
Regards,
What SDL version are you using? I noticed some strange keyboard behavior
with SDL 1.2.9 (Debian package), and this didn't happen when using SDL
1.2.10 (self-built). The problems were things like no Shift-Tab in
Windows, and "showkey" under Linux displaying strange keycodes when
using Shift-Tab.
Regards,
Oliver
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Qemu developement documentation?
Hi all, I'm developping Qemu to simulate ARM processor and I also read the file qemu-tech.html in Qemu source code. But I don't understand very well the idea that Qemu simulates a (exp: x86) instruction. [quote]The basic idea is to split every x86 instruction into fewer simpler instructions. Each simple instruction is implemented by a piece of C code (see `target-i386/op.c'). Then a compile time tool (`dyngen') takes the corresponding object file (`op.o') to generate a dynamic code generator which concatenates the simple instructions to build a function (see `op.h:dyngen_code()') [/quote] (I don't understand the explanation in bold) + What does the explanation in bold mean? Or do you have any document which clarifies this? + Do you have any document which explains how Qemu works (idea for the working of Qemu)? + Does Qemu works (i.e get the instruction from the target OS, splits the instruction into simpler instructions, executes the instructions on host OS...) same as the other simulators? Best regards Tieu Yahoo! Music Unlimited - Access over 1 million songs. Try it free. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu developement documentation?
On 28 jun 2006, at 10:48, Tieu Ma Dau wrote: [quote] The basic idea is to split every x86 instruction into fewer simpler instructions. Each simple instruction is implemented by a piece of C code (see `target-i386/op.c'). Then a compile time tool (`dyngen') takes the corresponding object file (`op.o') to generate a dynamic code generator which concatenates the simple instructions to build a function (see `op.h:dyngen_code()') [/quote] (I don't understand the explanation in bold) Since I'm reading your message in plain text, I don't know what part of your quote is bold, but what happens is this: * a number of basic operations are defined, and each of these basic operations is implemented using a C function (so the implementation is mostly cpu-independent) * the functions with these simple operations are put together in "op.c", and this file is compiled by a compiler on the host platform into op.o * dyngen more or less disassembles this generated op.o: for each of those functions, it gets the assembler code, but strips out entry and exit code * when emulating, for each to be emulated instruction Qemu simply copies the appropriate assembler code gotten by dyngen from op.o By putting all those copied code fragments after each other, the full program is emulated. There are some special tricks for things like jumps (a special symbol which is found using the relocation information, and which then can be replaced during emulation with the actual target), but overall that's it. Jonas ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu kbd emulation
On Wed, Jun 28, 2006 at 10:27:31AM +0200, Rafa?? Cygnarowski wrote: > and it look that qemu does not generate some codes before > pressing and after releasing arrow keys. For example pressing > up key on qemu looks like: > > 224 72 224 200 > > while without emulation it looks: > > 224 42 224 72 224 200 224 170. (e0 2a e0 48 e0 c8 e0 aa) FWIW, 2a is the left shift key. See http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html -- Stuart Brady ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows Vista D0000144
Hi, Ask in Windows Vista official forums in technet page (http:// technet.microsoft.com/) what the error is, and so we can know what the problem is inside qemu. Regards Natalia Portillo El 27/06/2006, a las 20:52, Marco Sanvido escribió: Numerous people successfully installed vista on qemu. I'm able to bootstrap (pass the ACPI test), and do most of the installation, but I still get the d144 error message. 1) Someone had reported that they where able to pass this point, could you share your configuration? 2) What is the error d144 exactly, is an ide.c problem? My configuration: virtual machine: memory 512 hda20GB raw cdromiso options -win2k-hack and without -- Marco ___ 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 kbd emulation
On Wed, Jun 28, 2006 at 10:27:31AM +0200, Rafa?? Cygnarowski wrote:
> +case 0xc8: /* up */
> +case 0xd0: /* down */
> +case 0xcd: /* right */
> +case 0xcb: /* left */
> + if (ev->type != SDL_KEYUP) {
> + kbd_put_keycode(e0);
> + kbd_put_keycode(2a);
> + }
> + break;
> }
As I suspected, this is the "fake shift" sequence. It's should also be
needed for the insert, delete, home, end, page up and page down keys.
Note that fake shifts shouldn't be generated for the numeric keypad.
--
Stuart Brady
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] SystemC hw simulation in qemu
2006/6/20, Fabrice Bellard <[EMAIL PROTECTED]>: Alessandro Corradi wrote:> Hi all,> I've tried to create my simple hw and it's ok. Now my teacher tells me> that i must use a hw description written in SystemC and plug in Qemu.> Have you got any idea to do it? Can somebody link me to documents where > I can find info?Hi,If you do that I am interested to see the results. Use a simple devicesuch as the serial port (hw/serial.c) as an example.Regards,Fabrice. The idea is to create a SystemC wrapper file in hw dir, where there is the code for connect via socket to a SystemC process in host machine. The problem is that I write my simple hw, but instead use io address such as 0x378 i need to use memory address, so I can use it in every virtualizzation (i386, mips etc...). Where can I look for it?ThanksAle ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] SystemC hw simulation in qemu
> The idea is to create a SystemC wrapper file in hw dir, where there is the > code for connect via socket to a SystemC process in host machine. The > problem is that I write my simple hw, but instead use io address such as > 0x378 i need to use memory address, so I can use it in every virtualizzation > (i386, mips etc...). Why do you want to have SystemC in its own process? BTW, SystemC freely available lib is really slow. Take a look at some lookalikes such as FastSysC. Laurent ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] SystemC hw simulation in qemu
2006/6/28, Laurent DESNOGUES <[EMAIL PROTECTED]>: > The idea is to create a SystemC wrapper file in hw dir, where there is the> code for connect via socket to a SystemC process in host machine. The> problem is that I write my simple hw, but instead use io address such as > 0x378 i need to use memory address, so I can use it in every virtualizzation> (i386, mips etc...).Why do you want to have SystemC in its own process?BTW, SystemC freely available lib is really slow. Take a look at some lookalikes such as FastSysC.Laurent___Qemu-devel mailing listQemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-develIt can be an idea, but I'm not the systemc developer, I've already got the sc module, and I must integrate it into qemu. This is that I must to do for thesis' degree. ThanksAle ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu kbd emulation
> > +case 0xc8: /* up */
> > +case 0xd0: /* down */
> > +case 0xcd: /* right */
> > +case 0xcb: /* left */
> > + if (ev->type != SDL_KEYUP) {
> > + kbd_put_keycode(e0);
> > + kbd_put_keycode(2a);
This should be:
+ kbd_put_keycode(0xe0);
+ kbd_put_keycode(0x2a);
my fault...
> > + }
> > + break;
> > }
>
> As I suspected, this is the "fake shift" sequence. It's should also be
> needed for the insert, delete, home, end, page up and page down keys.
>
> Note that fake shifts shouldn't be generated for the numeric keypad.
Yes, but now I'm trying only these few keys...
--
Rafał Cygnarowski
[EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu kbd emulation
> What SDL version are you using? I noticed some strange keyboard behavior
> with SDL 1.2.9 (Debian package), and this didn't happen when using SDL
> 1.2.10 (self-built). The problems were things like no Shift-Tab in
> Windows, and "showkey" under Linux displaying strange keycodes when
> using Shift-Tab.
I was using SDL 1.2.9. After upgrade to 1.2.10 (and qemu
recompilation) nothing changed.
I also made same more tests and now I know sth more.
1. ps2_queue
I changed ps2_queue to see if my patch do what I thought
it should do.
-- BEGIN --
--- ps2.c.old 2006-06-28 13:21:01.0 +0200
+++ ps2.c 2006-06-28 13:00:17.0 +0200
@@ -117,6 +117,8 @@
void ps2_queue(void *opaque, int b)
{
+printf("%i ", b);
+
PS2State *s = (PS2State *)opaque;
PS2Queue *q = &s->queue;
-- END --
Result on pressing UP key: 224 42 224 72 224 200 224 170,
so it's correct.
2. I understood output of my program wrong. Output was sth like:
224 224 72 88224 224 170 where these to 8s were strange for me.
The true is that qemu dropped somewhere part of my fake keycodes
+ kbd_put_keycode(0xe0);
+ kbd_put_keycode(0x2a);
^^ - this one was lost
+ kbd_put_keycode(0xe0);
+ kbd_put_keycode(0xaa);
^^ - and this one too
As the result of this drop, after pressing UP key (without my
test program loaded) DOS displays ONE '8' character. When I load
my TSR test program DOS displays TWO '8' characters! I suppose
these 8s are the answare(?) why arrow keys are interpreted twice
in such programs like Dos Navigator when I run them with qemu.
So now I have to find out:
- where those fake keycodes were dropped,
- why after loading my test program those two 8s are displayed
(there is some unneeded interrupt generated - am I right?).
Honestly, I don't know where I should start looking...
--
Rafał Cygnarowski
[EMAIL PROTECTED]
PS. My goal is to lost those fake twice pressed keys
becouse I use (want to use) qemu only for DOS guest OS.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu kbd emulation
On Wed, Jun 28, 2006 at 02:16:56PM +0200, Rafa?? Cygnarowski wrote: > So now I have to find out: > - where those fake keycodes were dropped, > - why after loading my test program those two 8s are displayed > (there is some unneeded interrupt generated - am I right?). > > Honestly, I don't know where I should start looking... > Not sure if this is the cause, but I believe that ps2_read_data remembers the last key pressed and returns it if there is no new key to be read (to make it work with EMM386 it seems). I have an ugly hack that fixes the code so there are no more key repeats, but I was never able to figure out what caused the key drops. -- 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
Re: [Qemu-devel] Make -std-vga the default?
Hi, I've been using -std-vga for a couple of weeks now, and it works well at least for the guests I've been using (Win2K/XP, Red Hat 9, SuSE 10.1). Really? My win2k install couldn't do anything useful with -std-vga. It would only do the very basic 640x480x4 mode. I'm fairly sure win9x can't do anything useful with straight VGA either. Same here Overall it seems to work much better than the default 5446 simulation and it seems to me that non-developer users, who are presumably the larger fraction of the user base, would benefit from having -std-vga as the default. The "it just works" property is important for new users, and -std-vga has more of that than the 5446 just at the moment. In my experience the Cirrus emulation "just works", and is supported by pretty much every OS out the box. AFAIK Windows earlier than XP doesn't needs additional 3rd party drivers to support anonymous VESA hardware. That are most of time difficult to find and commercial only. Not to say for OS/2, Windows 3.x, etc Regards ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] pronunciation of Qemu
How should you pronounce Qemu? FYI, my best guess is Q (as in the letter Q) followed by the first 2 syllables of emulator. Regards, Paul Robinson. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Make -std-vga the default?
> > Really? My win2k install couldn't do anything useful with -std-vga. > > It would only do the very basic 640x480x4 mode. I'm fairly sure win9x > > can't do anything useful with straight VGA either. > > Same here. Also std-vga seemed to be slower than cirrus when I tried > it recently on my linux guests, although I haven't actually measured > anything. My mistake; Win2K doesn't like -std-vga. I confused 2K and XP. > > > Overall it seems to work much better than the default 5446 > > Julian, in what way is std-vga better than the cirrus emulation? I can go above 1024x768, which is realistically something I need in order to use QEMU as a viable replacement for VMware. With SuSE 10.1 guest I can't even get 1024x768 with Cirrus. SuSE claims it's doing 1024x768 but what I get is 1024x600. > > In my experience the Cirrus emulation "just works", and is supported > > by pretty much every OS out the box. AFAIK Windows earlier than XP > > doesn't needs additional 3rd party drivers to support anonymous VESA > > hardware. I agree that avoiding additional drivers is good. However it seems that both cirrus and std-vga have their shortcomings and neither is an ideal out-of-the-box solution right now. J ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu kbd emulation
On Wed, Jun 28, 2006 at 02:16:56PM +0200, Rafa?? Cygnarowski wrote: > So now I have to find out: > - where those fake keycodes were dropped, I'm not sure. > - why after loading my test program those two 8s are displayed > (there is some unneeded interrupt generated - am I right?). 8 is on the same key as "up" on the numeric keypad. > Honestly, I don't know where I should start looking... Have you tried toggling numlock? The URL I posted might help -- especially the bit about fake shifts. The output you're getting is: e0 e0 48 e0 e0 aa but you should get: e0 2a e0 48 e0 c8 e0 aa So you're losing 2a (which after e0 would fakes pressing shift) and then c8 (which would release the up key itself). (BTW, it'd be easier if you used hexadecimal in your output.) It seems that having the MSB bit set in the output of sdl_keyevent_to_keycode() means that it's one of the 'e0'-escaped keys (mostly the 'grey' versions of the numeric keypad keys)... and the MSB in the final keycode is set if the key is being released, otherwise it's cleared. I can't see anything wrong... but I'm not sure if you're adding code in the wrong place. QEMU uses PC keycodes internally but I'm not sure this should go as far as including fake shifts -- either way, you'll probably need to look at hw/ps2.c. I don't know much about PS/2, unfortunately, but hw/ps2.c seems to translate keycodes from set 1 to set 2, and they get converted back to set 1 elsewhere. Maybe that's where the bug is? -- Stuart Brady ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu kbd emulation
Dnia środa, 28 czerwca 2006 16:28, Jim C. Brown napisał:
> On Wed, Jun 28, 2006 at 02:16:56PM +0200, Rafa?? Cygnarowski wrote:
> > So now I have to find out:
> > - where those fake keycodes were dropped,
> > - why after loading my test program those two 8s are displayed
> > (there is some unneeded interrupt generated - am I right?).
> >
> > Honestly, I don't know where I should start looking...
>
> Not sure if this is the cause, but I believe that ps2_read_data remembers
> the last key pressed and returns it if there is no new key to be read (to
> make it work with EMM386 it seems).
And it's ok while reading port 0x60 should return last key.
What I can say is that I found 1st REAL bug.
Value recived from port 0x60 in interrupt function should
always be the same.
While I'm not sure if this is clear, here is sample code
for testing:
-- BEGIN test.pas --
program time; {$M 2048,0,0}
uses crt, dos;
var oldkbd : procedure;
procedure kbd; interrupt;
begin
Write(' 1. '); Write(Port[$60]);
Write(' 2. '); Write(Port[$60]);
Write(' 3. '); Writeln(Port[$60]);
inline($9c); oldkbd;
end;
begin
getintvec($9, addr(oldkbd));
setintvec($9, @kbd);
keep(0);
end.
-- END test.pas --
kbd function works fine on qemu for keys which fill ps2_queue
to q->count == 1 (like letters). It works in this case becouse
after reading first value from queue q->count is equal 0 and
then last key is returned.
For keys which are suppressed by 0xe0 for example this code fails.
ps2_read_data is used to recive Port[$60] value and every use of
this function decrease q->count (and moves pointer to next value)
which is wrong in this case while this action should take place
after exiting my "kbd" function.
Any idea how to fix it? (I'm not familiar with qemu src code and
I don't know where to put the code which should move ps2_queue
pointer to next value.)
--
Rafał Cygnarowski
[EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] pronunciation of Qemu
On Wed, 28 Jun 2006, Paul Robinson wrote: > How should you pronounce Qemu? > > FYI, my best guess is Q (as in the letter Q) followed by the first 2 > syllables of emulator. I've personally always pronounced it "kwemu"... -- Michael "Soruk" McConnell Eridani Star System MailStripper - http://www.MailStripper.eu/ - SMTP spam filter Mail Me Anywhere - http://www.MailMeAnywhere.com/ - Mobile email ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] pronunciation of Qemu
On 6/28/06, Paul Robinson <[EMAIL PROTECTED]> wrote: How should you pronounce Qemu? FYI, my best guess is Q (as in the letter Q) followed by the first 2 syllables of emulator. That's how I've always pronounced it, but I've also heard people say "kee-moo", which I have to admit is kind of cute. --Ed ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] pronunciation of Qemu
To me no matter how you pronounce it, It's not a pronounce friendly type name - IMO. Joe Ed Swierk wrote: On 6/28/06, Paul Robinson <[EMAIL PROTECTED]> wrote: How should you pronounce Qemu? FYI, my best guess is Q (as in the letter Q) followed by the first 2 syllables of emulator. That's how I've always pronounced it, but I've also heard people say "kee-moo", which I have to admit is kind of cute. --Ed ___ 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] pronunciation of Qemu
Thats why i just call it sue Joe Lee wrote: To me no matter how you pronounce it, It's not a pronounce friendly type name - IMO. Joe Ed Swierk wrote: On 6/28/06, Paul Robinson <[EMAIL PROTECTED]> wrote: How should you pronounce Qemu? FYI, my best guess is Q (as in the letter Q) followed by the first 2 syllables of emulator. That's how I've always pronounced it, but I've also heard people say "kee-moo", which I have to admit is kind of cute. --Ed ___ 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] QEMU GUI
I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT, Basilisk II, SheepShaver, etc. ;-) Gwenole, can you elaborate more on your comments above. Are your comments referring to having a GUI that can both run and manage several virtualization product (QEMU, XEN, etc) from one central GUI interface? If so, I had a similar thought on this BUT was not sure how possible this was. Would like to hear more on what your thoughts are on this. Anyone else thought and comments to this would be appreciated! -joe [EMAIL PROTECTED] wrote: Hi, If people are interested, we could try to port Q as a base, since it's going to be obsolete anyway (either by the new QEMU GUI or leopard)... :) I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT, Basilisk II, SheepShaver, etc. ;-) That could imply the use of an internal configs format with translators to suit various emulators. Some IPC could also be involved to communicate with the application for suspend, resume, fullscreen-switch, etc. qt4 is also an interesting toolkit and the Open Source edition is available under the GPL license for Linux/Unix, MacOS X and even Windows. Bye, Gwenole. ___ 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
