Re: [Qemu-devel] [Spice-devel] [PATCH qemu+spice] expose server mouse status
ACK series Acked-by: Arnon Gilboa agil...@redhat.com Alon Levy wrote: Below are the combined summaries. This lets the current mouse mode the server is using be shown to qemu users: (qemu) info spice Server: address: 0.0.0.0:10005 auth: none compiled: 0.10.2 mouse-mode: server qemu: Alon Levy (1): spice_info: add mouse_mode hmp.c|2 ++ qapi-schema.json |7 ++- ui/spice-core.c |5 + 3 files changed, 13 insertions(+), 1 deletion(-) spice: Alon Levy (1): server: export spice_server_is_server_mouse predicate server/reds.c|6 ++ server/spice-server.syms |4 server/spice.h |4 +++- 3 files changed, 13 insertions(+), 1 deletion(-)
Re: [Qemu-devel] [Spice-devel] [PATCH] qxl: allowing the command rings to be not empty when spice worker is stopped RHBZ #728984
Acked-by: Arnon Gilboa agil...@redhat.com
Yonit Halperin wrote:
same as 8927cfbba232e28304734f7afd463c1b84134031, but for qxl_check_state, that
was
triggered by qxl_pre_load (which calls qxl_hard_reset, which calls
qxl_soft_reset),
and caused the migration target to crash.
---
hw/qxl.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index db7ae7a..7991e70 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -821,17 +821,15 @@ static void qxl_check_state(PCIQXLDevice *d)
{
QXLRam *ram = d-ram;
-assert(SPICE_RING_IS_EMPTY(ram-cmd_ring));
-assert(SPICE_RING_IS_EMPTY(ram-cursor_ring));
+assert(!d-ssd.running || SPICE_RING_IS_EMPTY(ram-cmd_ring));
+assert(!d-ssd.running || SPICE_RING_IS_EMPTY(ram-cursor_ring));
}
static void qxl_reset_state(PCIQXLDevice *d)
{
-QXLRam *ram = d-ram;
QXLRom *rom = d-rom;
-assert(!d-ssd.running || SPICE_RING_IS_EMPTY(ram-cmd_ring));
-assert(!d-ssd.running || SPICE_RING_IS_EMPTY(ram-cursor_ring));
+qxl_check_state(d);
d-shadow_rom.update_id = cpu_to_le32(0);
*rom = d-shadow_rom;
qxl_rom_set_dirty(d);
[Qemu-devel] Re: Webcam solution for QEMU
Hello Albert, First of all, I have done nothing in the qemu project for more than two years now. My last contribution to qemu were some usb 1.1 uhci/ohci patches for very basic support of webcams and other isochronous devices (accepted), and a preliminary patch for usb 2.0 ehci (rejected due to high res timer requirement). If I remember it correctly the usb 1.1 worked reasonably on several webcams (mostly old ones, usb 1.1) and with low frames-per-second rate. I guess since then there were some significant changes in the qemu usb code, so I cannot really answer your questions. Anyway, in the following week or two I will try to catch up with qemu current usb status and update you if I have any insight. Forwarding your message to qemu-devel, so you may get some smarter answers. Best Regards, Arnon Albert Orriols Puig wrote: Hi Arnon, I'm Albert Orriols-Puig, an assistant professor at La Salle -- Ramon Llull University (in Spain). Recently, we have started using a virtualization solution based on Open Suse + KVM + QEMU. Currently we have some machines that use this software and host two Windows operating systems: WinXP and Win7. The machines work quite well, that is, we have a quite good performance in both guest OS. One of the key aspects that we need is to give support to webcams, since our users usually employ skype or similar software to make phone calls. However, we have realized that QEMU does not give direct support for webcams. We have searched for different patches, and found yours, which enables transfers in redirected host USB devices. We have tried your patch in a machine with the two aforementioned hosts and a couple of logitech webcams. We have realized that the guest OS detected the existence of a webcam, but could not show the images of these webcams. In the WinXP system, the image was in black. In the Win7, he detected the webcam but didn't allow using it since an error popped up indicating that the webcam was blocked by another application. We have searched for other patches that may help us, but we were not successful. So, I'm contacting you to ask you a couple of questions. First, in the patch notes it is mentioned that the system worked for some USB 1.1 and USB 2.0 cameras on XP. Do you remember some of the specific webcams that you tried and worked? If so, could you tell me the models and any tweak you needed to do in the guest OS side to make them work? It would be great if we could make this work even if we have to adapt to particular webcams. The second question is about the state of the progress on the support of devices in QEMU. I've seen in some forums that there are some people (including you ;)) working on QEMU to give support to different devices. Do you know if there will be new releases to support USB devices in a short time? We are specially interested in webcams, but we would also need other devices as well. Let me thank you in advance for the time spend on reading this email! Best, Albert Orriols-Puig, PhD La Salle -- Universitat Ramon Llull email: aorri...@gmail.com web: http://www.albertorriols.net http://www.albertorriols.net/
RE: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
Can you give me some details about the device? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerb Stralko Sent: Friday, February 29, 2008 4:17 PM To: Arnon Gilboa Cc: [EMAIL PROTECTED]; qemu-devel@nongnu.org Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation On Fri, Feb 29, 2008 at 2:33 AM, Arnon Gilboa [EMAIL PROTECTED] wrote: In hw/pc.c, replace usb_uhci_piix3_init(pci_bus, piix3_devfn + 2); With usb_ehci_init(pci_bus, piix3_devfn + 2); With these changes.. I can't add the usb devices anymore to a Windows XP (32 bit). This is the command i use to start kvm: /usr/local/bin/kvm/qemu-system-x86_64 -localtime -m 512 -usb -hda win32xp.img To add usb device i normally go to the qemu console and type: info usbhost find the number for my device i want to connect to usb_add host:03f0:01cda But with your patch, when i try to add a usb device i get: Could not add 'USB device host:03f0:01cda' Since i'm using EHCI emulation, do i need to add usb devices in a different way? Or should it work exactly the same way? Thanks, Jerry Note my comments on the original post: -tested on XP guest -does not support ISO transfers -timing issues -Original Message- From: Gerb Stralko [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 9:46 PM To: Arnon Gilboa Cc: qemu-devel@nongnu.org; [EMAIL PROTECTED] Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation Attached is a repost of the preliminary patch implementing USB 2.0 EHCI emulation. I want to start testing your patches for the EHCI stuff. Do i need to enable anything inorder to get EHCI emulation working after applying your patch? Unfortunately, with this patch it doesn't work for me. My guest host (windows vista) still became really slow when I add the a usb device. Waiting for your comments, Arnon Thanks, Jerry
RE: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
In hw/pc.c, replace usb_uhci_piix3_init(pci_bus, piix3_devfn + 2); With usb_ehci_init(pci_bus, piix3_devfn + 2); Note my comments on the original post: -tested on XP guest -does not support ISO transfers -timing issues -Original Message- From: Gerb Stralko [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 9:46 PM To: Arnon Gilboa Cc: qemu-devel@nongnu.org; [EMAIL PROTECTED] Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation Attached is a repost of the preliminary patch implementing USB 2.0 EHCI emulation. I want to start testing your patches for the EHCI stuff. Do i need to enable anything inorder to get EHCI emulation working after applying your patch? Unfortunately, with this patch it doesn't work for me. My guest host (windows vista) still became really slow when I add the a usb device. Waiting for your comments, Arnon Thanks, Jerry
RE: [Qemu-devel] USB support
The multi-config patch is already merged in Qemu 9.1 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Zelem Sent: Saturday, February 09, 2008 5:34 PM To: qemu-devel@nongnu.org Subject: [Qemu-devel] USB support Hi I want to inform you that I successfully attached my Canon MP830 (printer, scanner, fax) to Qemu via USB. It was not easy, I had to pass though two stoppages. 1. There is no support for multi port/config (do not know proper term for that) USB devices in Qemu. Meaning that if single USB device provides multiple functionalities (like printer, scanner, fax) it will be rejected by Qemu. Fortunately there is patch for that available on internet page http://www.wina.at/uni/html/linux-qemu.html (qemu-0.9.0-usb-multi-configs.patch). 2. When I applied the patch I hit another issue. When the USB device is not ready it is automatically switched to HALT state (if I understood it correctly) and additional ioctl USBDEVFS_CLEAR_HALT is required to give device another chance. Thus, I have written patch for that issue. The patch I am sending as attachment. When I applied both patches, everything worked fine. I suggest to include those two patches in Qemu. Best regards Marek Zelem -- e-mail: [EMAIL PROTECTED] web: http://marek.terminus.sk/ pgp key: http://marek.terminus.sk/gpg.txt
RE: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
The WinXP guest seems to work fine with the timer resolution, accuracy and latency of qemu. The problem with linux guests might be related to this issue. I will test the ehci emulation without the specified kernel config and see how can we handle timing issues in a more qemu-oriented way. Any tip? Arnon -Original Message- From: Paul Brook [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 08, 2008 3:30 AM To: qemu-devel@nongnu.org Cc: Arnon Gilboa; KVM; Roni Luxenberg Subject: Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation -The host kernel was configured with dynamic tick hi-res timers, to allow the desired timer resolution. USB 2.0 microframe is 125usec. Requiring a 8kHz timer is a non-starter. The 100kHz retry timer is even more bogus. Qemu isn't capable of this kind of realtime response. You need to figure out an implementation that doesn't require extremely fine grained timers. In paractice you're unlikely to get better than 10ms timer resolution, and 100ms latency isn't that uncommon. Paul
RE: [Qemu-devel] high resolution timer question
The usb host controller emulations in qemu (usb-uhci usb-ohci) use QEMUTimer for 1 millisecond timer. This precise interval is required for generating usb 1.1 frames. I currently implement usb 2.0 host controller emulation for qemu (usb-ehci). It uses QEMUTimer for generating usb 2.0 microframes of 125 microsecond. This resolution worked precisely only after compiling the host kernel with high resolution timers and dynamic ticks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Reif Sent: Monday, December 10, 2007 3:00 PM To: qemu-devel@nongnu.org Subject: [Qemu-devel] high resolution timer question Writing data to a serial port on the sparc emulation happens immediately. I would like to throttle the write speed to match the actual baud rate. What's the best way to do this in qemu? Will QEMUTimer work for a 1 millisecond timer?
RE: [Qemu-devel] USB performance Question
I have just copied 138 MByte (800 files) from a disk-on-key in 75 sec. This is ~14.7Mbit/s, which is more than USB 1.1 full-speed. I have checked it using KVM and WinXP guest. With QEMU only (-no-kvm), it took 130 sec, which is ~8.5 Mbit/sec. If you can give some info about your USB device (configurations, interfaces, endpoints etc.) and the transfers (isochronous? bulk?) , it would help in solving this issue. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, November 25, 2007 5:54 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] USB performance Question Thanks Arnon. USB1 works really great even for complex streaming cameras! Although it is just very very slow. As mentioned I only get about 10kbit/s! which is something I dont understand why. I would have expected 1Mbit/s and could live with that. If there are any test you want me to do please dont hesitate. Cant wait for your USB2 implementation. Great effort! Arnon Gilboa wrote: I am in the middle of coding EHCI (USB 2.0) host controller emulation. It is supposed to support faster device speeds (480 Mbit/sec instead of USB 1.1 speeds - 1.5 or 12Mbit/sec). I will post it on the list when it basicly supports simple devices such as disk-on-key. Currently I still have some major problems with the scheduling of async and periodic frame lists. I will check your comment regarding the speed and see what can be done. Anway, if you want to try to solve the issue yourself, the relevant code is in usb-linux.c (Linux host USB redirector) and the USB UHCI/OHCI controller emulations (hw/usb-uhci.c or hw/usb-ohci.c). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, November 25, 2007 3:01 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] USB performance Question Does anyone have a comment about this? It would be interesting to know where the USB development is going as it is extremely promising and the only small obstacle (i.m.o) for full feature device access. The only remaining barrier is speed which should be improved. I can look at the code if someone can point me to where in the sources the USB interface is. thanks [EMAIL PROTECTED] wrote: I could get very complicated USB devices to work under Qemu with Windows as guest, Linux as host. This is pretty amazing development and I must congratulate the Qemu developers. The only problem is the USB speed. I get only about 10kbit/s max! This is measured by downloading a 1MByte scientific camera image. Is this the expected USB speed at the moment or is there anything I can do to improve speed? Thanks
Re: [Qemu-devel] USB performance Question
I am in the middle of coding EHCI (USB 2.0) host controller emulation. It is supposed to support faster device speeds (480 Mbit/sec instead of USB 1.1 speeds - 1.5 or 12Mbit/sec). I will post it on the list when it basicly supports simple devices such as disk-on-key. Currently I still have some major problems with the scheduling of async and periodic frame lists. I will check your comment regarding the speed and see what can be done. Anway, if you want to try to solve the issue yourself, the relevant code is in usb-linux.c (Linux host USB redirector) and the USB UHCI/OHCI controller emulations (hw/usb-uhci.c or hw/usb-ohci.c). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, November 25, 2007 3:01 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] USB performance Question Does anyone have a comment about this? It would be interesting to know where the USB development is going as it is extremely promising and the only small obstacle (i.m.o) for full feature device access. The only remaining barrier is speed which should be improved. I can look at the code if someone can point me to where in the sources the USB interface is. thanks [EMAIL PROTECTED] wrote: I could get very complicated USB devices to work under Qemu with Windows as guest, Linux as host. This is pretty amazing development and I must congratulate the Qemu developers. The only problem is the USB speed. I get only about 10kbit/s max! This is measured by downloading a 1MByte scientific camera image. Is this the expected USB speed at the moment or is there anything I can do to improve speed? Thanks
RE: [Qemu-devel] USB Asynchronous I/O
Sorry, it was my mistake. I only meant it may require some changes in ohci/uhci. -Original Message- From: Paul Brook [mailto:[EMAIL PROTECTED] Sent: Sunday, November 18, 2007 3:31 PM To: qemu-devel@nongnu.org Cc: Arnon Gilboa Subject: Re: [Qemu-devel] USB Asynchronous I/O there might be some issues in the ohci/uhci because they currently assume only isochronous transfers are async. That's definitely incorrect. The USB mass storage emulation uses async bulk transfers. Paul
RE: [Qemu-devel] USB Asynchronous I/O
I believe you can do it similar to the way I did for isochronous transfers in usb-linux.c. Remember that using SUBMITURB and REAPURBNDELAY ioctls, you need to add another signal and signal handler for the async bulk, and there might be some issues in the ohci/uhci because they currently assume only isochronous transfers are async. A minute ago I tried to implement the bulk transfers using SUBMITURB and REAPURB (which blocks until response) but it seems to hang qemu upon connecting a disk-on-key. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salil Bijur Sent: Wednesday, November 14, 2007 11:49 PM To: qemu-devel@nongnu.org Subject: [Qemu-devel] USB Asynchronous I/O Hello, I've been testing Bluetooth-USB in QEMU for an arm-based processor with a Linux guest. When a bluetooth dongle is added, there is a continuous sending of bulk and interrupt packets synchronously (using the USBDEVFS_BULK ioctl) making qemu extremely slow and unusable. I wanted to know if it is a good idea to send these bulk and interrupt transfers asynchronously using the SUBMITURB and REAPURBNDELAY ioctls in a way similar as isochronous transfers in usb-linux.c. Is there any reason why only isochronous packets are being sent asynchronously when the same can be done for other types? Thanks, Salil
RE: [Qemu-devel] No cancel callback for usb-ohci
Seems like an ugly bug (common also to uhci), which I haven't noticed before. I guess this scenario has never happened to me. Can you please describe it? Call usb_defer_packet with cancel_cb which flags the packet, so the following usb_packet_complete will be ignored. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salil Bijur Sent: Thursday, November 08, 2007 8:51 AM To: qemu-devel@nongnu.org Subject: [Qemu-devel] No cancel callback for usb-ohci Hello, There is a call to the function usb_cancel_packet in hw/usb-ohci.c. However, there is no cancel_cb callback registered for the ohci-usb_packet resulting in a segmentation fault. Are there any plans to implement this cancel callback? Thanks, Salil
RE: [Qemu-devel] No cancel callback for usb-ohci
You may add a flag to USBPacket and raise it upon your ohci_async_cancel_packet. ohci_async_complete_packet will check this flag and do nothing if it is up. Am I missing something? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salil Bijur Sent: Thursday, November 08, 2007 12:47 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] No cancel callback for usb-ohci Hi Arnon, On Nov 8, 2007 3:28 PM, Arnon Gilboa [EMAIL PROTECTED] wrote: Seems like an ugly bug (common also to uhci), which I haven't noticed before. I guess this scenario has never happened to me. Can you please describe it? What I'm trying to do is to prevent the lag caused by the USBDEVFS_BULK ioctl and instead send the bulk transfers asynchronously using the USBDEVFS_SUBMITURB ioctl. I'm taking the help of the patch you had sent for isochronous packets. This scenario occurs when the usb bluetooth dongle is added to the linux guest and its interface is brought up. Call usb_defer_packet with cancel_cb which flags the packet, so the following usb_packet_complete will be ignored. To call usb_defer_packet, there needs to be a callback function like the usb_msd_cancel_io function used in hw/usb-msd.c: usb_defer_packet(p, usb_msd_cancel_io, s); There doesn't seem to be a similar cancel_cb callback for ohci. An empty stub function prevents this crash, but should it be doing more stuff like the msd one does? Salil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salil Bijur Sent: Thursday, November 08, 2007 8:51 AM To: qemu-devel@nongnu.org Subject: [Qemu-devel] No cancel callback for usb-ohci Hello, There is a call to the function usb_cancel_packet in hw/usb-ohci.c. However, there is no cancel_cb callback registered for the ohci-usb_packet resulting in a segmentation fault. Are there any plans to implement this cancel callback? Thanks, Salil
[Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support
Hi, The attached patch adds isochronous transfers support to the OHCI emulation, similarly to the UHCI patch pushed two weeks ago. In order to use ohci instead of uhci, replace the following line in pc.c: usb_uhci_piix3_init(pci_bus, piix3_devfn + 2); With: usb_ohci_init_pci(pci_bus, 3, piix3_devfn + 2); Any comments? usb-ohci-iso.patch Description: usb-ohci-iso.patch
RE: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support
Good idea -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dor Laor Sent: Monday, October 22, 2007 12:45 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support Arnon Gilboa wrote: Hi, The attached patch adds isochronous transfers support to the OHCI emulation, similarly to the UHCI patch pushed two weeks ago. In order to use ohci instead of uhci, replace the following line in pc.c: usb_uhci_piix3_init(pci_bus, piix3_devfn + 2); With: usb_ohci_init_pci(pci_bus, 3, piix3_devfn + 2); Any comments? What about making it dynamically set by cmdline? Dor
RE: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support
no. uhci ohci are for usb 1.1. ehci is for usb 2.0 and i have just started working on its qemu emulation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Itamar Heim Sent: Monday, October 22, 2007 12:30 PM To: qemu-devel@nongnu.org Subject: RE: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support So this is isochronous for usb 2.0? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnon Gilboa Sent: Monday, October 22, 2007 12:19 PM To: qemu-devel@nongnu.org Subject: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support Hi, The attached patch adds isochronous transfers support to the OHCI emulation, similarly to the UHCI patch pushed two weeks ago. In order to use ohci instead of uhci, replace the following line in pc.c: usb_uhci_piix3_init(pci_bus, piix3_devfn + 2); With: usb_ohci_init_pci(pci_bus, 3, piix3_devfn + 2); Any comments?
[Qemu-devel] Redirect your Webcam
Please connect your Webcam (or any other USB isochronous device) and redirect it, using the UHCI (already in qemu head) and OHCI isochronous patches. I need your feedback. TIA, Arnon
RE: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support
Thanks, Paul.
The attached updated patch seems to fix this bug.
Comments?
-Original Message-
From: Paul Brook [mailto:[EMAIL PROTECTED]
Sent: Monday, October 22, 2007 1:53 PM
To: qemu-devel@nongnu.org
Cc: Arnon Gilboa
Subject: Re: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers
support
On Monday 22 October 2007, Arnon Gilboa wrote:
Hi,
The attached patch adds isochronous transfers support to the OHCI
emulation, similarly to the UHCI patch pushed two weeks ago.
+uint16_t offset[8];
+};
+static inline int ohci_read_iso_td(uint32_t addr, struct ohci_iso_td
+*td) {
+return get_dwords(addr, (uint32_t *)td, sizeof(*td) 2); }
This is wrong. It will break on big-endian hosts.
set_dwords only DTRT if all the structure fields are 32-bit.
Paul
usb-ohci-iso.patch
Description: usb-ohci-iso.patch
[Qemu-devel] [PATCH] usb-linux iso: use pipe instead of bh
When handling the isocronous completion signals, use O_NONBLOCK pipe instead of bottom halves for thread-safety. usb-linux.patch Description: usb-linux.patch
RE: [Qemu-devel] EHCI emulation patch
I was in contact with Mark about 2 month ago. He told me that the company he has developed the ehci emulation for won't let him release to open source until the project is finished, which looks to be end of 2007 at least. If that changes he'll post the patch to the list. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Per ?strand Sent: Friday, September 28, 2007 11:00 AM To: qemu-devel@nongnu.org Subject: [Qemu-devel] EHCI emulation patch Hi! Has anyone seen the ehci emulation patch lately? I have tried to find it, but so far no luck! Help, anyone? Mark, are you still there? /Per On 12/24/06, Mark B [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Dear list, Just a quick note to let you know I have almost finished an implementation of an EHCI host controller for USB (usb-ehci.c) for qemu. I am testing with an XP guest and so far I have a mass storage flash key, a mouse and a tablet working. I haven't yet implemented isochronous or split transactions though. It doesn't do companion controller hand-offs for low or full speed devices either but Windows XP doesn't mind that I am attaching low/full speed devices through EHCI (I believe Linux guests won't like this). I have asked the company I am working for to give me permission to GPL the module and so far they are agreeable. So I am planning to clean up and have an initial version for check in early in the new year. If anyone has any inputs, please do let me know. I'm new to qemu development so am not sure of checkin etiquette, etc. Pointers in that regard appreciated too. Cheers, Mark ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Redirected USB devices isochronous support
Attached is a preliminary patch for supporting isochronous transfers in redirected host USB devices. The initial goal was supporting USB 1.1 Webcam. Tested on several Webcams. Works on USB 1.1 Webcams, as well as most USB 2.0 Webcams (backward compatibility) on low resolutions. Some jitter is visible in the video stream, and it will be fixed. Notice USE_ASYNCIO, which defines whether to use signal based async io or polling for receiving urbs. Currently it is disabled, so polling is used, but it does not seem to affect the performance because it uses the non-blocking USBDEVFS_REAPURBNDELAY ioctl. In order to use the signal based async io, a further patch to usb-uhci.c will be posted. The patch includes parts of previous patches posted in Qemu-devel: usb_host_update_interfaces (from qemu-0.9.0-usb-multi-configs.patch), usb_linux_update_endp_table (qemu-usb-host-async.patch) as well as some other lines of code. I am starting to work on the ehci emulation for fully supporting USB 2.0 isochronous devices. Waiting for your comments, Arnon qemu-usb-isoch.patch Description: qemu-usb-isoch.patch
