RE: [Qemu-devel] Unified device model
Currently Bochs plugins APCI already begins with such C-language bindings. But inside the device is C++ based and derives from Bochs device model. It has the same log writer and debugging interface as any other Bochs module but nothing more. Could you look into the Bochs devices code and plugin code, I think you could say how much it is compatible fro QEMU and if there is something that we should consider to change ... Stanislav -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leonardo E. Reiter Sent: Saturday, April 08, 2006 9:27 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] Unified device model Well, not completely impossible, but it would require some really ugly "glue" code. And, the glue would have to happen outside of QEMU (i.e. like in the BOCHS code), to keep C++ out of QEMU. To have a truly portable API, it should definitely have C language "bindings". I'm sure this could be added to the BOCHS implementation somehow if this is important. - Leo Reiter Johannes Schindelin wrote: > IIRC bochs does it in C++. Which makes it rather impossible to share code > :-( > > Ciao, > Dscho -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center 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
RE: [Qemu-devel] Unified device model
Hi again, >>It is not a secret that all open source emulators (QEMU, Bochs, Xen) use >>the same emulated devices and mostly copy-paste their emulation one from >>another. >While from my understanding Xen uses qemu's hardware emulation for it's VT >support, this is not really true otherwise. >The devices emulated by qemu and bochs are quite similar, but the code >looks completely different (appears to be a ground-up rewrite). I am talking about the device models only. Inside CPU emulation QEMU, Bochs and Xen are completely different, but they use the same devices for full system emulation and they most likely want to move forward together. The devices system of QEMU and Bochs become outdate, it is required to add ACPI compliance and emulate new modern ACPI compatible devices, currently emulated i440FX already not so represent the real life and most of the modern OSes already have no support for it. >> I don't know who originally wrote the device models but now Bochs and >> QEMU maintain two similar implementations of the same devices. >> If one of the teams fixes the implementation or add functionality, >> another team mostly copy-paste the changes to their model. >I don't know how well Bochs and qemu keep in touch with each other. I've >never seen a Bochs developer announce themselves here, though. So may we should ;) At least I see the code changes from Bochs migrating to QEMU and vise versa when I am looking into the code. >>Xen project forked from QEMU and want to stay in touch with Bochs and QEMU >>device models and contribute the changes to make the model better. >Not true. Xen is completely independent. Unless you are refering to the >hardware emulation - which I believe is qemu's stuff. I know that it is completely independent project. But their device models could be called separate project Xen-HWEMU and it is fork from QEMU. >>I am wondering about making unified device models architecture for open >>source simulators. >>The device models will be used in QEMU, Bochs, Xen and other open source >>simulators which would use the device models. >I would support this idea, if it was possible. Why not ? You always could consider to add simple modules C++ to QEMU or build C++ device -> C device interface bridge ... I don't know all the possibilities, but I am sure there are more. >>I know about two professional teams working in simulation which would like >>to use these device models in their simulator and >>could enrich the device library with new devices device interfaces, for >>example with AGP and 3D graphics. >>Bochs is already in middle of definition of new true pluginable devices >>architecture. >This is welcome news. Currently we are thinking about making user-plugin PCI devices and when later user-plugin for any device. The C++ hierarchy for now might be: bx_devmodel_c - bx_pcidev_c - bx_user_pcidev_c The plans are to take one of the Bochs PCI devices and convert it into user-level plugin which should not be compiled with Bochs and even not known at compile time, but loaded at runtime if selected in runtime config file. When any other device models could be added, even with closed-sources and commercial licenses. >The primary reason given for not making a plugin API for qemu hardware >emulationis that qemu isn't stable enough - the code changes too often to >support a stable API. >Still, it might be easier to add support for plugins based on an external >API, rather than trying to keep a qemu plugin API consistent. Ok, I didn't knew that QEMU is so unstable. But at least there are several trivial requirements from plugin architecture which you could mention here and I am still not thought about it. I know, basically I am writing the definition in my idle time and Volker supporting me. But it is not enough ... Thanks, Stanislav ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
I was looking through the Xorg evdev driver and it doesn't appear to support absolute coordinate reporting. evdev is how the USB mouse would show up to userspace. A little googling confirmed it for me: http://lists.freedesktop.org/archives/xorg/2005-September/010140.html USB wacom still seems the most promising to me but I fear getting it to work under Windows will be a pain. Regards, Anthony Liguori Leonardo E. Reiter wrote: This is by no means a complete patch (do not apply it as it will break usb-hid.c), but it adjusts the report descriptor in usb-hid.c to provide position in 16-bits, and in absolute coordinates: Index: usb-hid.c === RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v retrieving revision 1.1 diff -a -u -r1.1 usb-hid.c --- usb-hid.c 5 Nov 2005 16:57:08 - 1.1 +++ usb-hid.c 8 Apr 2006 20:56:02 - @@ -117,7 +117,7 @@ 0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01, 0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01, 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81, -0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06, +0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02, 0xC0, 0xC0, }; According to: http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1 I'm still trying to figure out how the logical min/max apply if we are to report absolute (unsigned) positions in 16-bits. Obviously 8-bits is not enough for absolute coordinates. You could theoretically use only 12-bits per coordinate but that would make life difficult I think, and probably unnecessarily frugal in a software emulation. It's not clear to me [yet] how the scroll wheel comes into play, and whether or not it (the dz coordinate) can be kept relative for ease of implementation. Also the code would need to be changed to report coordinates in 16-bits rather than 8, and of course made to report absolute coordinates (like from sdl.c, etc.) Still it looks fairly easy to implement - the USB spec is pretty simple. So to reiterate, my patch does virtually nothing - in fact it will break usb-hid.c so please don't use it. I was just illustrating how to get it to report the device as providing 16-bit absolute coordinates instead of 8-bit relative ones. If anyone wants to chime in with more info, I'd be glad to make this a discussion. *If* using the USB HID device only, not any real USB devices, can be done without slowing down QEMU, then I think this is a great way to get a tablet emulated without having to deal with drivers on either side. Plus, in the long run, it probably means other neat stuff like being able to get away from ISA bus emulation, and also it's portable to other targets (for example, OS-X on PPC would talk to the USB HID device the same way theoretically), so it's likely the most portable and cleanest option. Regards, Leo Reiter Brad Campbell wrote: Apparently USB HID supports absolute input devices natively. Given we have a HID mouse driver of sorts in qemu I wonder if that is another avenue perhaps ? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
Leonardo E. Reiter wrote: The Win4Lin Pro version is not a driver, but rather a high-priority Windows userspace thread. We try to avoid drivers as much as possible because they are a serious obstacle to supporting new Windows versions and service packs as they come out. I can't comment on VMware's approach to be honest. I will say that using a device that has readily and/or publicly available drivers is probably ideal, such as a Wacom tablet. We are trying to move to more of a device model on Win4Lin Pro for performance reasons, which is why I am interested in this approach. But letting Microsoft maintain the guest driver, if it's built into Windows, is the best solution. It also guarantees the broadest possible guest support in general - whether it be Linux, Mac OS X, etc. The driver isn't built into Windows. It's pretty easy to install though and the way my patch works, the PS/2 mouse is used until it detects the tablet has been enabled. The Windows driver uses quite a bit more of the features of the tablet than the X driver so there's a bit more work to do but nothing extraordinary. Regards, Anthony Liguori If anyone has a link to Anthony Liguori's driver, I'd be glad to look into fixing whatever may be wrong with it and posting the patches. Thanks, Leo Reiter andrzej zaborowski wrote: I thought Anthony Liguori had already written a Wacom tablet emulator for QEMU and that worked fine except it supports only one button. I don't remember if this support was complete and I don't have a link to the patch. With this you don't need to disable mouse acceleration in the guest OS because it makes no sense to accelerate a tablet. On the other hand writing a guest-side driver for QEMU would leave room for further improvements like hiding/showing or grabbing/releasing the mouse at specific moments. Or, possibly reusing tools from Win4Lin or VMtools from VMware. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
andrzej zaborowski wrote: Hi, IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse support is rather flakey: You have to disable mouse acceleration of the guest OS. I had that cunning plan to write a virtual Wacom tablet, but I just don't find the time. I thought Anthony Liguori had already written a Wacom tablet emulator for QEMU and that worked fine except it supports only one button. I don't remember if this support was complete and I don't have a link to the patch. No, it supports all three. Works quite well for new X drivers. If you search the wacom-devel archives you'll find a link to the docs for the Wacom driver. It does kind of suck though that you have to manually configure your X server. I looked at a number of tablets and they all seem to be serial or undocumented. Regards, Anthony Liguori With this you don't need to disable mouse acceleration in the guest OS because it makes no sense to accelerate a tablet. On the other hand writing a guest-side driver for QEMU would leave room for further improvements like hiding/showing or grabbing/releasing the mouse at specific moments. Or, possibly reusing tools from Win4Lin or VMtools from VMware. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258 ___ 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] VNC terminal server?
Johannes Schindelin wrote: Hi, On Sat, 8 Apr 2006, Jim C. Brown wrote: On Sat, Apr 08, 2006 at 08:24:03PM +0200, Johannes Schindelin wrote: IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse support is rather flakey: You have to disable mouse acceleration of the guest OS. I had that cunning plan to write a virtual Wacom tablet, but I just don't find the time. Ciao, Dscho Anthony Ligouri has written a patch for wacom support. However, when I combine this with the -no-sdl-grab patch I still see syncing issues. Where can I get it? http://www.cs.utexas.edu/users/aliguori/qemu-wacom-2.tgz but as I mentioned earlier, YMMV. Regards, Anthony Liguori Ciao, Dscho ___ 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] VNC terminal server?
Johannes Schindelin wrote: Hi, On Sat, 8 Apr 2006, Leonardo E. Reiter wrote: this virtual Wacom tablet you refer to... is there a [free or built-in] Windows 2000/XP driver associated with it that supports either no acceleration and/or absolute positioning? Frankly, I do not know if they are free. But as nobody pays me to play with QEmu, I do not care about Windows so much. And the Wacom drivers for Linux are free. BTW I prefer a virtual wacom tablet to Summagraphics, since kudzu (the hardware detection which is used in Knoppix) can detect it. Unfortunately just the USB version :-( The USB version of the wacom tablet is not documented. Only the older serial tablets are. Regards, Anthony Liguori If so, perhaps I can look at implementing it in QEMU in my "spare" time ;) Do you have a link to documentation and/or drivers? Wow! What an offer! I have some documentation somewhere, I just had a look, and only found the Summagraphics documentation. I will look harder. If the guest OS can't be easily told to not do any acceleration and/or use absolute cursor positioning rather than relative moves, it's not that helpful to have a new type of input device. I suspect a tablet driver can be easily configured this way since design people who probably use these devices want perfect precision between pointer and screen - otherwise they'd probably just use a mouse/trackball. But you can never be sure how Microsoft (or Wacom) decided to implement the Windows version of the driver. My favourite cartoonist, Jamiri, is very proud of his Wacom tablet. IIRC, it has an integrated LCD display. So, I assume absolute positioning is automatically switched on with that tablet. The mouse sync solution we have in Win4Lin Pro is okay, but it's a bit slow and I'd like to do something much cleaner. Of course if I do the wacom tablet implementation, it will be open source and part of QEMU itself. Thanks! Thank you! Ciao, Dscho ___ 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] VNC terminal server?
Jim C. Brown wrote: On Sat, Apr 08, 2006 at 08:24:03PM +0200, Johannes Schindelin wrote: IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse support is rather flakey: You have to disable mouse acceleration of the guest OS. I had that cunning plan to write a virtual Wacom tablet, but I just don't find the time. Ciao, Dscho Anthony Ligouri has written a patch for wacom support. Docs are available for older Wacom tablets. I've not gotten the time to update my patches to actually implement the full protocol according to the docs. The version I wrote is based on a newer X driver so YMMV. Regards, ANthony Liguori However, when I combine this with the -no-sdl-grab patch I still see syncing issues. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
Johannes Schindelin wrote: Hi, On Sat, 8 Apr 2006, Samuel Hunt wrote: It occurs to me that this program would make an excellent basis for a VNC terminal server. Yeah, something like that has been done already: http://libvncserver.sourceforge.net/qemu/qemu-rfb13.patch.gz There is a notable update since rfb12 (which is a bit out of date _cough_): Nis Jorgensen has sent a patch to support scroll mice. IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse support is rather flakey: You have to disable mouse acceleration of the guest OS. I had that cunning plan to write a virtual Wacom tablet, but I just don't find the time. Someone posted a virtual Synaptic tablet on xen-devel recently (Xen uses qemu for VT support). If someone wants to pick it up and submit it to qemu, that would solve this problem. Regards, Anthony Liguori Ciao, Dscho ___ 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] qemu ./Makefile.target ./vl.c ./vl.h hw/integra...
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/09 01:32:52 Modified files: . : Makefile.target vl.c vl.h hw : integratorcp.c pl110.c Added files: hw : arm_pic.c arm_pic.h arm_timer.c pl011.c pl050.c pl080.c pl190.c versatilepb.c Log message: ARM Versatile Platform Baseboard emulation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.93&tr2=1.94&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.167&tr2=1.168&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.106&tr2=1.107&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/arm_pic.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/arm_pic.h?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/arm_timer.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/integratorcp.c.diff?tr1=1.7&tr2=1.8&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl011.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl050.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl080.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl110.c.diff?tr1=1.4&tr2=1.5&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl190.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/versatilepb.c?rev=1.1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu ./cocoa.m ./console.c ./monitor.c ./sdl.c ...
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/09 01:06:34 Modified files: . : cocoa.m console.c monitor.c sdl.c vl.c vl.h hw : integratorcp.c pl110.c sun4m.c tcx.c vga.c Log message: Allow multiple graphics devices. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/cocoa.m.diff?tr1=1.6&tr2=1.7&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/console.c.diff?tr1=1.4&tr2=1.5&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/monitor.c.diff?tr1=1.46&tr2=1.47&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/sdl.c.diff?tr1=1.24&tr2=1.25&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.166&tr2=1.167&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.105&tr2=1.106&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/integratorcp.c.diff?tr1=1.6&tr2=1.7&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl110.c.diff?tr1=1.3&tr2=1.4&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/sun4m.c.diff?tr1=1.13&tr2=1.14&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/tcx.c.diff?tr1=1.6&tr2=1.7&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/vga.c.diff?tr1=1.41&tr2=1.42&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw lance.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/08 23:32:52 Modified files: hw : lance.c Log message: Fix incorrect return type. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/lance.c.diff?tr1=1.6&tr2=1.7&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [usb] correct position of hid descriptor for emulated usb mouse
I was trying out qemu's emulated usb mouse under debian sid and windows xp. It worked fine under debian but failed to start under windows xp guest. It turns out the hid descriptor in the qemu_mouse_config_descriptor array is out of position. Please see section 7.1 in the document HID1_11: "The HID descriptor shall be interleaved between the Interface and Endpoint descriptors for HID Interfaces. That is, the order shall be: Configuration descriptor Interface descriptor (specifying HID Class) HID descriptor (associated with above Interface) Endpoint descriptor (for HID Interrupt In Endpoint) Optional Endpoint descriptor (for HID Interrupt Out Endpoint)" The patch is linked below: http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
Brad Campbell wrote: Now it's a long time since I've hacked on it but I wrote a userspace touch screen driver for win9x years ago that did just this.. I seem to recall having to scale the real touchscreen values to between 0x0 and 0x before feeding them in to the windows message queue. From memory 0,0 was top left and , was bottom right.. as applied to the current screen resolution. Windows worked the rest out itself.. Like I said.. very hazy memory.. There's actually a GDI call you can make if you are in user space that will allow you to do absolute cursor addressing. The problem is that you have be in user space, and you have to be able to talk to the display. By the time this happens, it's way too late in general - for example, you already got past the Windows login screen, etc. It's basically what we do on Win4Lin Pro now, but it's not really adequate for the long run and it's not too fast. Ideally, a USB HID device would "just work" with the Windows HID "class" driver, and the rest will be history. HID device drivers are ubiquotous and work on every major OS, not just Windows obviously (Linux, *BSD, OS-X, etc.), so it truly would be the most universal solution. And, keeping with the spirit of QEMU, this solution would mean not having to modify anything in the guest either. Not too mention how it's 100 times easier (at least) to hack QEMU than to code a Windows device driver of any sort (IMHO anyway.) I'll have a look in the morning and see if I can dig that code out to figure out what I did, but given the way windows mouse events work that seems logical and would be relatively easy to do in qemu. As for the wheel.. I have no idea. An idea I had a while back was to feed the wheel and buttons to the ps2 port and get the positioning info in some other fashion. Ugly.. very ugly.. Actually the usb-hid.c already seems to be sending Z axis events (the wheel most likely)... it's just not clear, from reading the USB HID spec, how this relates to the data, or how this event is described. I admit I'm pretty new to deciphering USB, and also I haven't actually played with QEMU's usb-hid device either. As for the X and Y coordinate, they would have to be sent in some precision greater than 8-bits because screen resolutions are so high. A touchscreen is an ideal example of the type of device we need, even more so than a tablet. Thankfully USB makes us not really care what type of physical device it actually is, as long as we can describe it properly to the consumer (Windows/etc.). But anyway, we would want to be able to describe coordinates up to at least 1600x1200 since that is the max that cirrus_vga accepts, and that would require at least 11 bits per axis. You'd have to add 2 padding bits in the descriptor if you did it that way - easier would be 12-bits per axis. Then [I assume], when you send the motion packet, you would need to send the 24-bits packed rather than 8 and 8 as is done now. I just am not sure what happens to the dz part, since it's not really described anywhere that I can see. The code I'm referring to is in hw/usb-hid.c, in the function usb_mouse_poll(). It looks like the VM requests the Z axis value selectively, and the code handles this. I'm starting to believe that your dual-device idea makes good sense, because for example, a touchscreen doesn't have a Z axis. It will take some trial and error I suspect. - Leo -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center 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] Absolute USB-HID device musings (was Re: VNC Terminal Server)
Leonardo E. Reiter wrote: This is by no means a complete patch (do not apply it as it will break usb-hid.c), but it adjusts the report descriptor in usb-hid.c to provide position in 16-bits, and in absolute coordinates: Index: usb-hid.c === RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v retrieving revision 1.1 diff -a -u -r1.1 usb-hid.c --- usb-hid.c 5 Nov 2005 16:57:08 - 1.1 +++ usb-hid.c 8 Apr 2006 20:56:02 - @@ -117,7 +117,7 @@ 0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01, 0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01, 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81, -0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06, +0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02, 0xC0, 0xC0, }; According to: http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1 I'm still trying to figure out how the logical min/max apply if we are to report absolute (unsigned) positions in 16-bits. Obviously 8-bits is not enough for absolute coordinates. You could theoretically use only 12-bits per coordinate but that would make life difficult I think, and probably unnecessarily frugal in a software emulation. From what I have managed to read up on thus far, the absolute coordinates are pretty much fed directly to the application as mouse move events. Now it's a long time since I've hacked on it but I wrote a userspace touch screen driver for win9x years ago that did just this.. I seem to recall having to scale the real touchscreen values to between 0x0 and 0x before feeding them in to the windows message queue. From memory 0,0 was top left and , was bottom right.. as applied to the current screen resolution. Windows worked the rest out itself.. Like I said.. very hazy memory.. I'll have a look in the morning and see if I can dig that code out to figure out what I did, but given the way windows mouse events work that seems logical and would be relatively easy to do in qemu. As for the wheel.. I have no idea. An idea I had a while back was to feed the wheel and buttons to the ps2 port and get the positioning info in some other fashion. Ugly.. very ugly.. -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
Sorry, the patch is not only incomplete, but totally wrong :( The 0x16 should be 0x10, like this: -0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06, +0x25, 0x7F, 0x75, 0x10, 0x95, 0x02, 0x81, 0x02, I must have had a momentary lapse of [radix] reason :) - Leo Reiter -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center 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] Absolute USB-HID device musings (was Re: VNC Terminal Server)
This is by no means a complete patch (do not apply it as it will break usb-hid.c), but it adjusts the report descriptor in usb-hid.c to provide position in 16-bits, and in absolute coordinates: Index: usb-hid.c === RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v retrieving revision 1.1 diff -a -u -r1.1 usb-hid.c --- usb-hid.c 5 Nov 2005 16:57:08 - 1.1 +++ usb-hid.c 8 Apr 2006 20:56:02 - @@ -117,7 +117,7 @@ 0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01, 0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01, 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81, -0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06, +0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02, 0xC0, 0xC0, }; According to: http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1 I'm still trying to figure out how the logical min/max apply if we are to report absolute (unsigned) positions in 16-bits. Obviously 8-bits is not enough for absolute coordinates. You could theoretically use only 12-bits per coordinate but that would make life difficult I think, and probably unnecessarily frugal in a software emulation. It's not clear to me [yet] how the scroll wheel comes into play, and whether or not it (the dz coordinate) can be kept relative for ease of implementation. Also the code would need to be changed to report coordinates in 16-bits rather than 8, and of course made to report absolute coordinates (like from sdl.c, etc.) Still it looks fairly easy to implement - the USB spec is pretty simple. So to reiterate, my patch does virtually nothing - in fact it will break usb-hid.c so please don't use it. I was just illustrating how to get it to report the device as providing 16-bit absolute coordinates instead of 8-bit relative ones. If anyone wants to chime in with more info, I'd be glad to make this a discussion. *If* using the USB HID device only, not any real USB devices, can be done without slowing down QEMU, then I think this is a great way to get a tablet emulated without having to deal with drivers on either side. Plus, in the long run, it probably means other neat stuff like being able to get away from ISA bus emulation, and also it's portable to other targets (for example, OS-X on PPC would talk to the USB HID device the same way theoretically), so it's likely the most portable and cleanest option. Regards, Leo Reiter Brad Campbell wrote: Apparently USB HID supports absolute input devices natively. Given we have a HID mouse driver of sorts in qemu I wonder if that is another avenue perhaps ? -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center 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] -win2k-hack needed to do Windows Update?
Andrew Barr wrote: Hi again. I'm still working on my Windows 2000 SP4 VM, and I've discovered that running Windows Update (Internet Explorer 6) causes behavior similar to the "disk full" bug encountered during Windows 2000 setup. When it gets to the part where it's looking for updates (the green scrolling bar), there is excessive disk activity and the VM slows down significantly. This is both with and without -kernel-kqemu. I've monitored the size of the disk image while the VM thrases away, and it steadily gets larger. I've not let it completely fill up, but I've seen it add 2 gigabytes to the disk size in the space of fifteen minutes. Just for kicks, I added -win2k-hack to my bootup options and tried Windows Update. It's running now--so far so good but the disk is working a bit much for my taste. At least it is moving forward, albeit a bit slowly. I just thought I'd mention this here because I've not seen this behavior documented anywhere else. I've reproduced this with a vanilla 2kSP4 install (IE 5) and all patches up to the latest and greatest. I've tried with Leo's win2k-hack patch that only delays every 16th (iirc) irq and that seems to work also, but perhaps it was not as reliable (I've done so many tests my memory may not be that flash). Anyway. -win2k-hack gets windows update working on 2k here also. -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
I saw something like this once but dismissed it for some reason (like it was questionable whether or not Windows supported these types of devices)... it's quite interesting. Thanks, - Leo Reiter Brad Campbell wrote: This link might or might not be intersting http://72.14.203.104/search?q=cache:fZ3xQJYOy6UJ:www.codecomments.com/archive421-2005-5-499360.html+hid+mouse+absolute+support&hl=en&ct=clnk&cd=1&lr=lang_en Apparently USB HID supports absolute input devices natively. Given we have a HID mouse driver of sorts in qemu I wonder if that is another avenue perhaps ? -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center 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] VNC terminal server?
Leonardo E. Reiter wrote: The mouse sync solution we have in Win4Lin Pro is okay, but it's a bit slow and I'd like to do something much cleaner. Of course if I do the wacom tablet implementation, it will be open source and part of QEMU itself. This link might or might not be intersting http://72.14.203.104/search?q=cache:fZ3xQJYOy6UJ:www.codecomments.com/archive421-2005-5-499360.html+hid+mouse+absolute+support&hl=en&ct=clnk&cd=1&lr=lang_en Apparently USB HID supports absolute input devices natively. Given we have a HID mouse driver of sorts in qemu I wonder if that is another avenue perhaps ? -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu exec.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/08 20:02:06 Modified files: . : exec.c Log message: Initialize physical memory space to IO_MEM_UNASSIGNED. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/exec.c.diff?tr1=1.76&tr2=1.77&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
Hi, On Sat, 8 Apr 2006, Jim C. Brown wrote: > On Sat, Apr 08, 2006 at 09:12:18PM +0200, Johannes Schindelin wrote: > > > Anthony Ligouri has written a patch for wacom support. > > > > > > However, when I combine this with the -no-sdl-grab patch I still see > > > syncing > > > issues. > > > > Where can I get it? > > http://www.cs.utexas.edu/users/aliguori/qemu-wacom-2.tgz Thanks! I will play around a little. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
The Win4Lin Pro version is not a driver, but rather a high-priority Windows userspace thread. We try to avoid drivers as much as possible because they are a serious obstacle to supporting new Windows versions and service packs as they come out. I can't comment on VMware's approach to be honest. I will say that using a device that has readily and/or publicly available drivers is probably ideal, such as a Wacom tablet. We are trying to move to more of a device model on Win4Lin Pro for performance reasons, which is why I am interested in this approach. But letting Microsoft maintain the guest driver, if it's built into Windows, is the best solution. It also guarantees the broadest possible guest support in general - whether it be Linux, Mac OS X, etc. If anyone has a link to Anthony Liguori's driver, I'd be glad to look into fixing whatever may be wrong with it and posting the patches. Thanks, Leo Reiter andrzej zaborowski wrote: I thought Anthony Liguori had already written a Wacom tablet emulator for QEMU and that worked fine except it supports only one button. I don't remember if this support was complete and I don't have a link to the patch. With this you don't need to disable mouse acceleration in the guest OS because it makes no sense to accelerate a tablet. On the other hand writing a guest-side driver for QEMU would leave room for further improvements like hiding/showing or grabbing/releasing the mouse at specific moments. Or, possibly reusing tools from Win4Lin or VMtools from VMware. -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center 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] VNC terminal server?
On Sat, Apr 08, 2006 at 09:12:18PM +0200, Johannes Schindelin wrote: > > Anthony Ligouri has written a patch for wacom support. > > > > However, when I combine this with the -no-sdl-grab patch I still see syncing > > issues. > > Where can I get it? http://www.cs.utexas.edu/users/aliguori/qemu-wacom-2.tgz > > Ciao, > Dscho > > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- 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] Unified device model
On Sat, Apr 08, 2006 at 09:17:52PM +0200, Johannes Schindelin wrote: > IIRC bochs does it in C++. Which makes it rather impossible to share code > :-( > > Ciao, > Dscho > This is why I guessed qemu was a rewrite-from-scratch - C++ code is forbidden in qemu. Fortunately this does not prevent a properly designed binary plugin API. -- 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] Unified device model
Well, not completely impossible, but it would require some really ugly "glue" code. And, the glue would have to happen outside of QEMU (i.e. like in the BOCHS code), to keep C++ out of QEMU. To have a truly portable API, it should definitely have C language "bindings". I'm sure this could be added to the BOCHS implementation somehow if this is important. - Leo Reiter Johannes Schindelin wrote: IIRC bochs does it in C++. Which makes it rather impossible to share code :-( Ciao, Dscho -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center 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] VNC terminal server?
Hi, > IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse > support is rather flakey: You have to disable mouse acceleration of the > guest OS. > > I had that cunning plan to write a virtual Wacom tablet, but I just don't > find the time. > I thought Anthony Liguori had already written a Wacom tablet emulator for QEMU and that worked fine except it supports only one button. I don't remember if this support was complete and I don't have a link to the patch. With this you don't need to disable mouse acceleration in the guest OS because it makes no sense to accelerate a tablet. On the other hand writing a guest-side driver for QEMU would leave room for further improvements like hiding/showing or grabbing/releasing the mouse at specific moments. Or, possibly reusing tools from Win4Lin or VMtools from VMware. > Ciao, > Dscho > > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Unified device model
Hi, On Sat, 8 Apr 2006, Jim C. Brown wrote: > On Sat, Apr 08, 2006 at 09:57:10PM +0200, Stanislav Shwartsman wrote: > > > > It is not a secret that all open source emulators (QEMU, Bochs, Xen) use the > > same emulated devices and mostly copy-paste their emulation one from > > another. > > While from my understanding Xen uses qemu's hardware emulation for it's VT > support, this is not really true otherwise. > > The devices emulated by qemu and bochs are quite similar, but the code looks > completely different (appears to be a ground-up rewrite). IIRC bochs does it in C++. Which makes it rather impossible to share code :-( Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
Johannes Schindelin wrote: Frankly, I do not know if they are free. But as nobody pays me to play with QEmu, I do not care about Windows so much. And the Wacom drivers for Linux are free. Yes, I understand. I've been looking at the XFree86 version of the driver already. Unfortunately any time I spend on this will have to apply to Windows guests as well, as you can imagine. My company sells Windows-on-Linux software that uses QEMU, so it has to play with Windows guests ;) In fact, there was a recent PS/2 mouse patch on this list and a hack for XFree86 which was very simple. I didn't try it, but if you are using Linux guests you can probably get absolute positioning very easily. I don't recall who posted the patch - it was recent. The fix for the guest X server is very simple as well. BTW I prefer a virtual wacom tablet to Summagraphics, since kudzu (the hardware detection which is used in Knoppix) can detect it. Unfortunately just the USB version :-( Yes, given the state of USB in QEMU it's probably best to stick to serial for now if you want something that works very reliably and soon. Serial would be my intention. The only issue may be how this plays with Windows guests - again, this is very important to me. Wow! What an offer! I have some documentation somewhere, I just had a look, and only found the Summagraphics documentation. I will look harder. Thanks! My favourite cartoonist, Jamiri, is very proud of his Wacom tablet. IIRC, it has an integrated LCD display. So, I assume absolute positioning is automatically switched on with that tablet. I would think so too. But, in looking at the XFree86 version of the driver, it's apparently configurable and my fear is that Windows will flick it to relative mode so it can play acceleration tricks. But anyway, it's worth investigating. Actually Jim C. Brown just posted a note that there is an existing patch, but I can't seem to find it. Jim, I'd be glad to look at it even though you are saying that it is still flaky - perhaps it can be fixed. Thanks, Leo Reiter -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center 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] Unified device model
On Sat, Apr 08, 2006 at 09:57:10PM +0200, Stanislav Shwartsman wrote: > Hello All, > > > > It is not a secret that all open source emulators (QEMU, Bochs, Xen) use the > same emulated devices and mostly copy-paste their emulation one from > another. While from my understanding Xen uses qemu's hardware emulation for it's VT support, this is not really true otherwise. The devices emulated by qemu and bochs are quite similar, but the code looks completely different (appears to be a ground-up rewrite). > > I don't know who originally wrote the device models but now Bochs and QEMU > maintain two similar implementations of the same devices. > > If one of the teams fixes the implementation or add functionality, another > team mostly copy-paste the changes to their model. I don't know how well Bochs and qemu keep in touch with each other. I've never seen a Bochs developer announce themselves here, though. > > Xen project forked from QEMU and want to stay in touch with Bochs and QEMU > device models and contribute the changes to make the model better. Not true. Xen is completely independent. Unless you are refering to the hardware emulation - which I believe is qemu's stuff. > > I am wondering about making unified device models architecture for open > source simulators. > > The device models will be used in QEMU, Bochs, Xen and other open source > simulators which would use the device models. > I would support this idea, if it was possible. > I know about two professional teams working in simulation which would like > to use these device models in their simulator and > > could enrich the device library with new devices device interfaces, for > example with AGP and 3D graphics. > > Bochs is already in middle of definition of new true pluginable devices > architecture. > This is welcome news. > In near future Bochs devices will fully separatable from Bochs binary and > when could be developed separately from Bochs. > > I call to QEMU developers join to this project and come with their > requirements to plugin architecture. > > I don't know if QEMU supports device plugins now but I would like to see > QEMU a part of this idea, > I would as well. > I would like to get single device shared library which could be loaded to > Bochs and QEMU and work perfectly for both. > > This will eliminate the need to maintain two separate implementations of the > same devices, > > these implementations very fast will converge to single one, C or C++ based, > Bochs or QEMU based, doesn't matter. > > I am listening for your opinions ! > > The primary reason given for not making a plugin API for qemu hardware emulation is that qemu isn't stable enough - the code changes too often to support a stable API. Still, it might be easier to add support for plugins based on an external API, rather than trying to keep a qemu plugin API consistent. > > Thanks, > > Stanislav > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel -- 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] VNC terminal server?
Hi, On Sat, 8 Apr 2006, Jim C. Brown wrote: > On Sat, Apr 08, 2006 at 08:24:03PM +0200, Johannes Schindelin wrote: > > IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse > > support is rather flakey: You have to disable mouse acceleration of the > > guest OS. > > > > I had that cunning plan to write a virtual Wacom tablet, but I just don't > > find the time. > > > > Ciao, > > Dscho > > > > Anthony Ligouri has written a patch for wacom support. > > However, when I combine this with the -no-sdl-grab patch I still see syncing > issues. Where can I get it? Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
Hi, On Sat, 8 Apr 2006, Leonardo E. Reiter wrote: > this virtual Wacom tablet you refer to... is there a [free or built-in] > Windows 2000/XP driver associated with it that supports either no > acceleration and/or absolute positioning? Frankly, I do not know if they are free. But as nobody pays me to play with QEmu, I do not care about Windows so much. And the Wacom drivers for Linux are free. BTW I prefer a virtual wacom tablet to Summagraphics, since kudzu (the hardware detection which is used in Knoppix) can detect it. Unfortunately just the USB version :-( > If so, perhaps I can look at implementing it in QEMU in my "spare" time > ;) Do you have a link to documentation and/or drivers? Wow! What an offer! I have some documentation somewhere, I just had a look, and only found the Summagraphics documentation. I will look harder. > If the guest OS can't be easily told to not do any acceleration and/or > use absolute cursor positioning rather than relative moves, it's not > that helpful to have a new type of input device. I suspect a tablet > driver can be easily configured this way since design people who > probably use these devices want perfect precision between pointer and > screen - otherwise they'd probably just use a mouse/trackball. But you > can never be sure how Microsoft (or Wacom) decided to implement the > Windows version of the driver. My favourite cartoonist, Jamiri, is very proud of his Wacom tablet. IIRC, it has an integrated LCD display. So, I assume absolute positioning is automatically switched on with that tablet. > The mouse sync solution we have in Win4Lin Pro is okay, but it's a bit > slow and I'd like to do something much cleaner. Of course if I do the > wacom tablet implementation, it will be open source and part of QEMU > itself. > > Thanks! Thank you! Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
On Sat, Apr 08, 2006 at 08:24:03PM +0200, Johannes Schindelin wrote: > IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse > support is rather flakey: You have to disable mouse acceleration of the > guest OS. > > I had that cunning plan to write a virtual Wacom tablet, but I just don't > find the time. > > Ciao, > Dscho > Anthony Ligouri has written a patch for wacom support. However, when I combine this with the -no-sdl-grab patch I still see syncing issues. -- 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] Unified device model
Hello All, It is not a secret that all open source emulators (QEMU, Bochs, Xen) use the same emulated devices and mostly copy-paste their emulation one from another. I don’t know who originally wrote the device models but now Bochs and QEMU maintain two similar implementations of the same devices. If one of the teams fixes the implementation or add functionality, another team mostly copy-paste the changes to their model. Xen project forked from QEMU and want to stay in touch with Bochs and QEMU device models and contribute the changes to make the model better. I am wondering about making unified device models architecture for open source simulators. The device models will be used in QEMU, Bochs, Xen and other open source simulators which would use the device models. I know about two professional teams working in simulation which would like to use these device models in their simulator and could enrich the device library with new devices device interfaces, for example with AGP and 3D graphics. Bochs is already in middle of definition of new true pluginable devices architecture. In near future Bochs devices will fully separatable from Bochs binary and when could be developed separately from Bochs. I call to QEMU developers join to this project and come with their requirements to plugin architecture. I don’t know if QEMU supports device plugins now but I would like to see QEMU a part of this idea, I would like to get single device shared library which could be loaded to Bochs and QEMU and work perfectly for both. This will eliminate the need to maintain two separate implementations of the same devices, these implementations very fast will converge to single one, C or C++ based, Bochs or QEMU based, doesn’t matter. I am listening for your opinions ! Thanks, Stanislav ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
Hi, On Sat, 8 Apr 2006, Mark Williamson wrote: > The Xen copy of pckbd.c includes a patch to emulate a Summagraphics > tablet, in order to fix this problem. This is probably reusable for > QEmu itself. I even know who wrote it... Donald Dugger. He forwarded it to me also, and I even think it is part of the RFB patch (too lazy to check right now). There are two problems: - configuration is a bitch. For example, X and gpm do not play nice together. And there is no automatic detection for Summagraphics in kudzu (which is the automatic hardware detection of Knoppix). - the patch modifies the PS/2 mouse of QEmu. However, there is no such thing as a PS/2 Summagraphics. Consequently, all win98 drivers I found did not detect a Summagraphics device. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
> On Sat, 8 Apr 2006, Samuel Hunt wrote: > > It occurs to me that this program would make an excellent basis for a VNC > > terminal server. > > Yeah, something like that has been done already: > http://libvncserver.sourceforge.net/qemu/qemu-rfb13.patch.gz > > There is a notable update since rfb12 (which is a bit out of date > _cough_): Nis Jorgensen has sent a patch to support scroll mice. > > IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse > support is rather flakey: You have to disable mouse acceleration of the > guest OS. > > I had that cunning plan to write a virtual Wacom tablet, but I just don't > find the time. The Xen copy of pckbd.c includes a patch to emulate a Summagraphics tablet, in order to fix this problem. This is probably reusable for QEmu itself. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
Hi Dscho, this virtual Wacom tablet you refer to... is there a [free or built-in] Windows 2000/XP driver associated with it that supports either no acceleration and/or absolute positioning? If so, perhaps I can look at implementing it in QEMU in my "spare" time ;) Do you have a link to documentation and/or drivers? If the guest OS can't be easily told to not do any acceleration and/or use absolute cursor positioning rather than relative moves, it's not that helpful to have a new type of input device. I suspect a tablet driver can be easily configured this way since design people who probably use these devices want perfect precision between pointer and screen - otherwise they'd probably just use a mouse/trackball. But you can never be sure how Microsoft (or Wacom) decided to implement the Windows version of the driver. The mouse sync solution we have in Win4Lin Pro is okay, but it's a bit slow and I'd like to do something much cleaner. Of course if I do the wacom tablet implementation, it will be open source and part of QEMU itself. Thanks! - Leo Reiter Johannes Schindelin wrote: I had that cunning plan to write a virtual Wacom tablet, but I just don't find the time. Ciao, Dscho -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center 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] VNC terminal server?
Hi, On Sat, 8 Apr 2006, Samuel Hunt wrote: > It occurs to me that this program would make an excellent basis for a VNC > terminal server. Yeah, something like that has been done already: http://libvncserver.sourceforge.net/qemu/qemu-rfb13.patch.gz There is a notable update since rfb12 (which is a bit out of date _cough_): Nis Jorgensen has sent a patch to support scroll mice. IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse support is rather flakey: You have to disable mouse acceleration of the guest OS. I had that cunning plan to write a virtual Wacom tablet, but I just don't find the time. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
Samuel Hunt wrote: It occurs to me that this program would make an excellent basis for a VNC terminal server. What I'm basically after is something that I can have several clients connect into one server, and the server does all the work and just outputs the screen and stuff over the network and recieves the input over the network. VNC does all the I/O that's needed, would it be possible to set Qemu up though so it works with VNC as the I/O and simply sits on something like Linux as a server, starting a new instance every time another client connects? If you use the vnc patch you kinda get a large part of this already. Major issue is still mouse synch, but to be honest if you turn of all acceleration in the guest it stays pretty well synced up now as it is. I use it all the time on my server to host a win2k session when I need to access windows only stuff.. Coupled with kqemu it makes for a pretty quick combination. I *suspect* this is sort of how win4lin terminal server works, though they use funky additions to keep the mouse sync rock solid and other groovy bits to make life really easy to manage. I've been meaning to try and get my hands on an eval version to try it out.. as the desktop version makes life dead easy for almost anyone to just install and go. (like it used to with the old win9x version) Currently I run gentoo, freebsd-6 and win2k sessions on my server.. they just sit there idle until I connect to them with vnc.. works a treat. (server is debian) Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu exec.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/08 17:36:21 Modified files: . : exec.c Log message: Fix typo in previous patch. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/exec.c.diff?tr1=1.75&tr2=1.76&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu exec.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/08 17:14:56 Modified files: . : exec.c Log message: Fix breakpoint TLB invalidation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/exec.c.diff?tr1=1.74&tr2=1.75&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] VNC terminal server?
It occurs to me that this program would make an excellent basis for a VNC terminal server. What I'm basically after is something that I can have several clients connect into one server, and the server does all the work and just outputs the screen and stuff over the network and recieves the input over the network. VNC does all the I/O that's needed, would it be possible to set Qemu up though so it works with VNC as the I/O and simply sits on something like Linux as a server, starting a new instance every time another client connects? Thanks all! Sam ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/08 14:26:41 Modified files: . : configure Log message: Move configure --help output before gcc checks. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/configure.diff?tr1=1.86&tr2=1.87&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw pckbd.c ps2.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/08 14:12:31 Modified files: hw : pckbd.c ps2.c Log message: Keyboard savevm fix (malc). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pckbd.c.diff?tr1=1.14&tr2=1.15&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ps2.c.diff?tr1=1.2&tr2=1.3&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] SPARC target : Fix carry flag update in addxcc and subxcc ops
I send a patch that should fix a bug in the update of carry flag for addxcc
and subxcc instructions when the carry flag is set before the evaluation of
the instruction.
(the fix is identical to what is done in the similar instruction
op_adcl_T0_T1_cc for arm target)
? patch-qemu-sparc-xcc_ops.txt
Index: op.c
===
RCS file: /sources/qemu/qemu/target-sparc/op.c,v
retrieving revision 1.18
diff -u -p -r1.18 op.c
--- op.c 30 Oct 2005 17:28:50 - 1.18
+++ op.c 7 Apr 2006 22:04:40 -
@@ -415,9 +415,9 @@ void OPPROTO op_addx_T1_T0(void)
void OPPROTO op_addx_T1_T0_cc(void)
{
target_ulong src1;
-
+target_ulong has_carry = FLAG_SET(PSR_CARRY);
src1 = T0;
-T0 += T1 + FLAG_SET(PSR_CARRY);
+T0 += T1 + has_carry;
env->psr = 0;
#ifdef TARGET_SPARC64
if (!(T0 & 0x))
@@ -435,7 +435,7 @@ void OPPROTO op_addx_T1_T0_cc(void)
env->xcc |= PSR_ZERO;
if ((int64_t) T0 < 0)
env->xcc |= PSR_NEG;
-if (T0 < src1)
+if (T0 < src1 || (has_carry && T0 <= src1))
env->xcc |= PSR_CARRY;
if (((src1 ^ T1 ^ -1) & (src1 ^ T0)) & (1ULL << 63))
env->xcc |= PSR_OVF;
@@ -444,7 +444,7 @@ void OPPROTO op_addx_T1_T0_cc(void)
env->psr |= PSR_ZERO;
if ((int32_t) T0 < 0)
env->psr |= PSR_NEG;
-if (T0 < src1)
+if (T0 < src1 || (has_carry && T0 <= src1))
env->psr |= PSR_CARRY;
if (((src1 ^ T1 ^ -1) & (src1 ^ T0)) & (1 << 31))
env->psr |= PSR_OVF;
@@ -505,9 +505,9 @@ void OPPROTO op_subx_T1_T0(void)
void OPPROTO op_subx_T1_T0_cc(void)
{
target_ulong src1;
-
+target_ulong has_carry = FLAG_SET(PSR_CARRY);
src1 = T0;
-T0 -= T1 + FLAG_SET(PSR_CARRY);
+T0 -= T1 + has_carry;
env->psr = 0;
#ifdef TARGET_SPARC64
if (!(T0 & 0x))
@@ -525,7 +525,7 @@ void OPPROTO op_subx_T1_T0_cc(void)
env->xcc |= PSR_ZERO;
if ((int64_t) T0 < 0)
env->xcc |= PSR_NEG;
-if (src1 < T1)
+if (src1 < T1 || (has_carry && src1 <= T1))
env->xcc |= PSR_CARRY;
if (((src1 ^ T1) & (src1 ^ T0)) & (1ULL << 63))
env->xcc |= PSR_OVF;
@@ -534,7 +534,7 @@ void OPPROTO op_subx_T1_T0_cc(void)
env->psr |= PSR_ZERO;
if ((int32_t) T0 < 0)
env->psr |= PSR_NEG;
-if (src1 < T1)
+if (src1 < T1 || (has_carry && src1 <= T1))
env->psr |= PSR_CARRY;
if (((src1 ^ T1) & (src1 ^ T0)) & (1 << 31))
env->psr |= PSR_OVF;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Translation cache sizes
On Saturday 08 April 2006 04:13, Julian Seward wrote: > Using qemu from cvs simulating x86-softmmu (no kqemu) on x86, > booting SuSE 9.1 and getting to the xdm (kdm?) graphical login > screen, requires making about 1088000 translations, and the > translation cache is flushed 17 times. Booting is not too bad, > but once user-mode starts to run the translation cache is pretty > much hammered. > > I made 2 changes: > > * increase CODE_GEN_BUFFER_SIZE from 16*1024*1024 > to 64*1024*1024, > > * observe that CODE_GEN_AVG_BLOCK_SIZE of 128 > for the softmmu case is too low; my measurements put it > at about 247. So I changed it to 256. > > With those changes in place, the same boot-to-kdm process > requires only about 57 translations to be made, and 2 > cache flushes to happen. Of course the cost is an extra > 48M of memory use. Did you measure any actual speedup from these changes? In a typical linux boot there's a lot of new code run only once, so I'd expect the tb cache to be hammered fairly heavily. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Translation cache sizes
On Saturday 08 April 2006 13:43, Gwenole Beauchesne wrote: > Hi, > > > With those changes in place, the same boot-to-kdm process > > requires only about 57 translations to be made, and 2 > > cache flushes to happen. Of course the cost is an extra > > 48M of memory use. > > I faced a similar problem in Basilisk II. MacOS 8.x had a tendency to > invalidate the code cache approx. 1000 times per second. My poor > K6-2/300 was suffering a lot. About 45% of the time was dedicated to > compilation of code, and desktop experience was very sluggish. Then, I > came up with a very simple idea I named "lazy cache flush". Performance > increased by 76% and compilation time dropped below 10%, desktop > experience was very smooth. I will give you more contemporary results > hereunder. Qemu already does this. Initially it does it on a per-page basis (writes to a given physical memory page will invalidate all code on that page), and for frequently contested pages it does more fine-grained locking. x86 doesn't have explicit icache invalidate instructions, the icache is architecturally defined to be coherent after every jump instructions. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Translation cache sizes
Hi, With those changes in place, the same boot-to-kdm process requires only about 57 translations to be made, and 2 cache flushes to happen. Of course the cost is an extra 48M of memory use. I faced a similar problem in Basilisk II. MacOS 8.x had a tendency to invalidate the code cache approx. 1000 times per second. My poor K6-2/300 was suffering a lot. About 45% of the time was dedicated to compilation of code, and desktop experience was very sluggish. Then, I came up with a very simple idea I named "lazy cache flush". Performance increased by 76% and compilation time dropped below 10%, desktop experience was very smooth. I will give you more contemporary results hereunder. So what's lazy invalidation of the translation cache? Well, the goal is simple: keep translated code as long as possible. In practise, you invalidate the complete translation cache only when it is full. Other explicit cache invalidation (CINV instructions on 68k, icbi on ppc, etc.) is virtual. This means the code is kept but it is put in a "dormant" state. That is, usual entry points (in the hash table, or inter-block jumps) are redirected to a check/recovery code where the source block is checksumed again. If it matches original's the previously compiled code is brought back to life (restoration of entry points in hash table, and inter-block links). Otherwise, it's recompiled and new code is used. It's very simple and quite efficient. Since, I had no need to increase the translation cache beyond 8MB. So, here are a few results on an Athlon64 3200+. Translation cache is set to 8MB. The test consisted in booting to MacOS 8, running all Speedometer 4 tests, then shuting down the virtual Mac. * Without lazy flush: Number of soft flushes: 0 Number of hard flushes: 101387 Number of checksums : 0 Number of calls to compile_block : 20244047 Total emulation time : 115,8 sec Total compilation time : 59,4 sec (51,3%) * With lazy flush: Number of soft flushes: 405520 Number of hard flushes: 7 Number of checksums : 46545721 Number of calls to compile_block : 340104 Total emulation time : 66,1 sec Total compilation time : 1,8 sec (2,8%) The results speak by themselves. ;-) Speedometer 4 "Performance Rating" increased by 12%. More interestingly, Color QuickDraw tests improved by a 12x factor: scored 19.95 on average with lazy cache flush, 1.67 without. Bye, Gwenolé. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Translation cache sizes
Hi, On Sat, 8 Apr 2006, Mulyadi Santosa wrote: > > With those changes in place, the same boot-to-kdm process > > requires only about 57 translations to be made, and 2 > > cache flushes to happen. Of course the cost is an extra > > 48M of memory use. > > Good to hear! Wow! Maybe we should made those constants configurable > (using ./configure script)? It might be an even better idea to make command line options out of it. I know, I know, these are #define'd, and thus the buffer would have to be malloc()ed, but it'd be nice to have the same binary running on several computers (even those which cannot afford another 48M). Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
