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 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
Re: [Qemu-devel] Redirect COM1 to ttyUSB0
On Thu, 2005-08-04 at 16:38 -0700, John R. Hogerhuis wrote: > I could use -serial stdio > but how do I get it connected to the usb port? I'm guessing netcat/socat > but I've never used that utility. > > Anyone have a recipe that works? I ended up figuring out a way to do this... using socat. For qemu, I just provide option -terminal pty and qemu will print the pty it has opened. In my case it happened to be /dev/pts/6 So I had a real serial device that wanted to talk to a program in the virtual DOS machine on /dev/ttyUSB1 So I came up with a socat command that would connect them together: socat /dev/ttyUSB1,raw,cs8,echo=0 /dev/pts/6,raw,cs8,echo=0 The tricky part for me (since I had never used socat) was turning off all the echoing and editing it wanted to do. The only problem is that the app I'm using on the external device wants to see DSR asserted. I had to make a special adapter that looped back DTR to DSR. (anyone know a Linux utility I can use to turn on DTR and leave it on?) -- John. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] news on the OS X cocoa port
Natalia Portillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Better to have a architecture/machine pair. Architecture: x86-64 Machine: PC Architecture: PowerPC Machine: Core99 To be coincident with the -M flag and having the possibility of changing the qemu executable name (that should be in the GUI configuration) I do see the logical connection of the two. But -M is a commandline Parameter that should remain with the other commandline arguments. Maybe "PC Data" is not the correct name for what I had in mind: "PC Data" stores information, that is neccessary for a launcher app, to choose the correct binary and setup the right state, then apply the "Arguments" to this binary to start qemu. Since binarynames could change in the future, I agree that we should use generic names for the Architectures. I'll list them now (please correct me, if I'm mistaken): x86 x86-64 (x86_64 has more hits in google, but all the tech pages use x86-64) PowerPC (maybe PPC will make it easyer to grep?) SPARC MIPS G Mike El 04/08/2005, a las 8:36, Mike Kronenberg escribió: Mike Kronenberg wrote: I'm thinking of a new way to store the images and saved VMs, too. Maybe we could make something like vpc: A package with the config, disk-images and saved VMs, located in ~/Documents/QEMU PCs/ QEMU guest PC Format, a Proposal This should serve as a base for the discussion on a Structure/ Format to save preconfigured/saved guest PCs. Structure: all the Files needed by the VM are stored in a folder. The folder has an ending of .qvm (QEMU Virtual Machine). Mandatory Files: - Harddiskimages Configuration File (configuration.plist) Other Files: FDImages CDImages Thumbnail (thumbnail.png) VM State File (saved.vm) Host dependent Files: PkgInfo (OS X) info.plist (OS X) Format: As a general format, I propose XML. To be more exact: PropertyLists. You find the definition for PropertyLists at: http:// www.apple.com/DTDs/PropertyList-1.0.dtd Why XML? We live in a small world, the QEMU community started out from France and has now it's followers all over the world. The developers and (hard)core users may stick to ASCII characters. But this is not the case for a broader community. Localized Operating Systems and less interested/educated users will fast break compatibility of simple text/ini files. (There might even arise difficulties with ASCII/MacRoman) So XML is the choice in the long run. Why PropertyList? Because they are easy to handle. Datatypes/Values and Variable Names are stored as pairs: author Mike Kronenberg date 2005-07-27T22:00:00Z What should be covered by “configuration.plist”? Version About Arguments PC Data Temporary There is no particular Order, Data is accessed by key. 1.Version Simple String to define the version of this configurations.plist file. Format: 1.0.0 2.About Author name, Date, Copyright/left. Place for further Descriptions. 3.Arguments To have the highest compatibility, we should stick to a simple option/value Scheme here, with boolean YES/NO for arguments with no value, like -enable-audio. There should be no host dependent switches here. 4.PC Data PC Name, PC Description, PC Status, emulated CPU and other guest PC related “Meta” Information. 5.Temporary “Nice to have” data, host dependent switches – shortly everything that is NOT needed to guarantee the operation of QEMU. Sample configuration.plist: "http://www.apple.com/DTDs/PropertyList-1.0.dtd";> About author Mike Kronenberg copyright © 2005, Mike Kronenberg date 2005-07-27T22:00:00Z description This is a sample PC configuration. Arguments -boot c -cdrom /dev/cdrom -hda Harddisk1.raw PC Data name My new PC state saved system qemu-system-x86_64 Temporary Version 0.1.0 Waiting for Your Suggestions... Mike ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC8mDXSOHwOb87puQRApVgAJ432rq0FSwpBjRaxzmgVRcr3h/cpACg2+Cd O8Amp84ZCvMwvkEGJieWYkE= =npr3 -END PGP SIGNATURE- ___ 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] Serial port support
Just after deleting the thread about host serial port support I remembered seeing this done before, giving qemu good access to the host serial port: http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00105.html credits goes to the original author Cai Qiang. Regards Henrik ___ 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 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
Re: [Qemu-devel] Connecting vde and LAN
On Thu, Aug 04, 2005 at 12:14:53PM +0200, Henrik Nordstrom wrote: > On Tue, 12 Jul 2005, Jim C. Brown wrote: > > >I just tried this with libnet 1.1 (1.1.2.1 to be specific), and it doesn't > >seem to work. Pings do not go through. I only handled the vde -> host case > >though, do I need to do anything special for host -> vde packets? > > Did you fake the ARP response to the guest? If not the guest won't get > past ARP:ing for the host and no IP packet will be sent.. > I attempted to, but it seems I was only partially successful. Sometimes the ARP table would just have an "(Incomplete)" entry. > To make life simpler you should probably start testing UDP in each > direction (netcat is your friend) with static ARP entries registered on > both guest and host. > Hmm...static ARP. Never thought of that. > For host->guest packets the RAW sockets demonstrated earlier is fine if > you accept that the guest packets is also duplicated on the local lan. I > do not know of a method to have host->guest packets sent cleanly without > duplication on the Ethernet without setting up a TUN/TAP or PPP interface. > > Regards > Henrik > -- 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] Re: freebsd qemu port update - kqemu wrapper merge, need testing
Hi
Thanks for your work, but... (see below)
On Fri, 5 Aug 2005, Juergen Lock wrote:
Okay, I finally got around looking at this a little longer and
came up with the port update below. Specifically, I tried to merge
the good parts of the old kqemu wrapper:
- device cloning support on 5.x (multiple vms can use kqemu, tested
and seems to work)
- 4.x support (untested, I'm not sure if vm_map_user_pageable can
be used as a 1-to-1 replacement for vm_map_{un,}wire on 4.x, can
anyone here definitely say?)
- max_locked_pages calculation
Also:
- moved debug messages under debug.kqemu_debug sysctl
(do `sysctl debug.kqemu_debug=1' to enable)
- fixed a small bug
- added the amd64 ata irq mapping fix
Also untested on amd64.
Here it goes:
~> uname -a
FreeBSD kushnir1.kiev.ua 7.0-CURRENT FreeBSD 7.0-CURRENT #10: Thu Aug 4
04:17:5
4 EEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KUSHNIR amd64
This is Athlon64 3000+ -based box, Asus A8N SLI MB.
qemu itself builds and works like a charm ('sept the sound doesn't work),
but as far as kqemu is concerned - it loads perfectly all right but no
/dev/kqemu... is created. No warnings, no panics... and no kqemu's speed
boost (obviously).
Is there anything I could do?
Regards,
Vladimir
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: freebsd qemu port update - kqemu wrapper merge, need testing
On Sat, Aug 06, 2005 at 12:40:06AM +0300, Vladimir Kushnir wrote:
> Hi
> Thanks for your work, but... (see below)
>
> On Fri, 5 Aug 2005, Juergen Lock wrote:
>
> >Okay, I finally got around looking at this a little longer and
> >came up with the port update below. Specifically, I tried to merge
> >the good parts of the old kqemu wrapper:
> >
> >- device cloning support on 5.x (multiple vms can use kqemu, tested
> >and seems to work)
> >- 4.x support (untested, I'm not sure if vm_map_user_pageable can
> >be used as a 1-to-1 replacement for vm_map_{un,}wire on 4.x, can
> >anyone here definitely say?)
> >- max_locked_pages calculation
> >
> >Also:
> >
> >- moved debug messages under debug.kqemu_debug sysctl
> >(do `sysctl debug.kqemu_debug=1' to enable)
> >- fixed a small bug
> >- added the amd64 ata irq mapping fix
> >
> >Also untested on amd64.
> >
>
> Here it goes:
>
> ~> uname -a
> FreeBSD kushnir1.kiev.ua 7.0-CURRENT FreeBSD 7.0-CURRENT #10: Thu Aug 4
> 04:17:5
> 4 EEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KUSHNIR amd64
>
> This is Athlon64 3000+ -based box, Asus A8N SLI MB.
> qemu itself builds and works like a charm ('sept the sound doesn't work),
> but as far as kqemu is concerned - it loads perfectly all right but no
> /dev/kqemu... is created.
That's alright, it will appear when open()ed by qemu. (thats device
cloning for ya...)
> No warnings, no panics...
qemu would print a warning when it cannot open kqemu.
> and no kqemu's speed
> boost (obviously).
>
Hmm. You do use qemu-system-x86_64, since you're on amd64?
Juergen
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: freebsd qemu port update - kqemu wrapper merge, need testing
On Sat, 6 Aug 2005, Juergen Lock wrote: Hmm. You do use qemu-system-x86_64, since you're on amd64? Juergen Silly me. Now I did. And it falls with: EAX= EBX=0001 ECX=0002 EDX=0003 ESI=0004 EDI=0005 EBP= ESP=0015fd1c EIP=77fb4d83 EFL=0202 [---]CPL=3 II=0 A20=1 ES =0023 00cff300 CS =001b 00cffa00 SS =0023 00cff300 DS =0023 00cff300 FS =0023 7ffde000 0fff 7f40f3fd GS =0023 LDT= 8000 TR =0028 80042000 20ab 80008904 GDT= 8003f000 03ff IDT= 8003f400 07ff CR0=e001003b CR2=805ba6fd CR3=04631000 CR4=06d8 Unsupported return value: 0x And from dmesg output: kqemu version 0x00010100 kqemu: KQEMU installed, max_instances=4 max_locked_mem=64536kB. kqemu: aborting: Unexpected exception 0x0d in monitor space CS:EIP=f180:90001729 This was with (already made) winxp installation. Almost the same on an attempt to install it. Regards, Vladimir ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
