Hello!
I just wanted to hear about the Large USB patch that was discussed quite
alot here a couple of months ago.
As I understood it the patch was put on hold until the 0.90 release, but
I've heard nothing more about it...
Is anybody (Tino, Lonnie?) working on getting the patch into CVS?
Would
Attached is another patch to implement the said resume code. With
this patch, devices attached to windows xp guest are able to resume the
controller when necessary. Before, if a device was attached to the
usbhub and windows had the root hub set for power savings then the bus
would stay
lo. The attached patch addresses the problem with removing the
usbhub/tablet devices and switches the handle_packet call in the port
reset call to handle_msg which just happens to make the hub functional.
--- a/qemu/hw/usb-hub.c 2006-04-28 19:44:18.0 -0500
+++ b/qemu/hw/usb-hub.c
lo. The bug with the usb hub is a simple fix. We're simply using
handle_packet to pass USB_MSG_RESET when this should be passed to
handle_msg:
hw/usb-hub.c - line 388:
case PORT_RESET:
if (dev) {
dev-handle_packet(dev,
Ran into this as well when testing a gps device. Looking at hw/usb.c
and usb_20 8.5.3 now.
frame 1346: pid=OUT addr=0x03 ep=2 len=1
data_out= 30
usb_generic_handle_data(): handle setup
usb.c: usb_generic_handle_data, send more than oneconfig paket out not
implemented yet - FIXME
frame
Johannes Schindelin wrote:
I am quite sure you put a lot of work into this patch, but you sure make it
hard to appreciate, too.
First note that applying such a huge patch is bad. Let me help you (a little
more than last time) to understand that: You are almost guaranteed to
introduce bugs, and
Hi,
On 27/04/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello Johannes,
Thanks for your comments.
Johannes Schindelin wrote:
I am quite sure you put a lot of work into this patch, but you sure make it
hard to appreciate, too.
First note that applying such a huge patch is bad. Let
Hi,
nix.wie.weg wrote:
Johannes Schindelin wrote:
I am quite sure you put a lot of work into this patch, but you sure make
it hard to appreciate, too.
First note that applying such a huge patch is bad. Let me help you (a
little more than last time)
Sorry I dont know why, but I have
Hello Johannes,
I have to admit that your post did piss me off a little bit. But on the
other hand it would not help anybody, if I would shoot back, so I will
try to be as polite as possible.
My first note is on your first message, which I really have not
received. It is probably my fault, but I
Hello Lonnie.
Lonnie Mendez wrote:
Johannes Schindelin wrote:
Seeing as there is a release coming up this is most definitely not a
good thing. Initial testing yielded lots of this.
I'd like to see my all-in-one patch stripped out. Then simply
modifying the linux redirector to support
As Fabrice pointed out to me yesterday, it takes time to understand the
new usb api. To make this process easier I have assembled a small
documentation.
You will find it here:
http://217.20.126.200/tino/usb_api.pdf
http://217.20.126.200/tino/usb_api.odg
That is a nice description.
the
Hello Johannes,
Thanks for your comments.
Johannes Schindelin wrote:
I am quite sure you put a lot of work into this patch, but you sure make it
hard to appreciate, too.
First note that applying such a huge patch is bad. Let me help you (a little
more than last time)
Sorry I dont know why,
Hi,
Could you make a small patch containing just the bug fixes of the state
machine ?
Concerning your API changes, I am relunctant to include them now, but my
mind can evolve. An API change that I would consider as very useful
could be to be able to make asynchronous USB I/Os to avoid
Hello Fabrice,
I can understand, that you are not so happy with such an huge patch. But
sorry it can't be done with just patching the state machine. The main
problem is, that the cvs source needs the usbhub. But this hub is not
operational at its current state. So in fact whenever we try to find
Hello,
Lonnie Mendez wrote:
That works but not in the literal means of the attached device
actually functioning (see below). Here is something interesting:
(qemu) usb_add mouse
Controller 001: uhci
001:001 = mouse
Summary: 1 USB Controller, 1 USB Devices
(qemu)
Hello,
Lonnie Mendez wrote:
There are of course more bugs I've found. Namely being able to
usb_add any particular string with that string showing up as a new
device even though no valid entry for it exists.
I have fixed this issue, also I have found the segfault on usb_del.
Patch is
Hello,
I have made a new patch which includes all changes from yesterday,
because there were already inconsistencies Also attached is the log of
my USB scanner (The last lines are repeated for ever). It is recognized
but when the first bulk packet is send to it, I get a ETIMEDOUT Error
and I
[EMAIL PROTECTED] wrote:
I have fixed this issue, also I have found the segfault on usb_del.
Patch is attached.
Next problem:
Linux does not recognize it, if I add a tablet while linux is allready
running. The attach is not delivered to the operating system.
Hm. There also seems to be
Hello Lonnie,
Lonnie Mendez wrote:
[EMAIL PROTECTED] wrote:
Next problem:
Linux does not recognize it, if I add a tablet while linux is allready
running. The attach is not delivered to the operating system.
I have solved the problem, it was located in a rejected diff. (it was
the reason I
Sorry have forgotten the patch.
--- qemu-2006-04-22/hw/usb.c 2006-04-22 14:44:21.0 +0200
+++ qemu/hw/usb.c 2006-04-22 17:24:06.0 +0200
@@ -403,73 +403,74 @@
/* this function adds a newly created device and cares for the attach and
handles all errors */
-int
Adding a device by Vendor id and Product id doesn't seem to work.
If this is intentional then perhaps the functionality should be
restored. qemu users will find this convenient as it is a
fixed/static identification for a single usb device which is most
likely going to be the common
[EMAIL PROTECTED] wrote:
In which case did it not work, when I test it, it is functioning (only
with libusb)
usb_add host:04b6x0005
Sorry about that. I was used to the previous syntax:
usb_add host:04b6:0005
My guess is that the new syntax is to distinguish it from the
busaddr:addr
Lonnie Mendez wrote:
[EMAIL PROTECTED] wrote:
Sorry about that. I was used to the previous syntax:
usb_add host:04b6:0005
My guess is that the new syntax is to distinguish it from the
busaddr:addr syntax? It would seem checking for length would
differentiate the two in that case.
Yes
[EMAIL PROTECTED] wrote:
Lonnie Mendez wrote:
[EMAIL PROTECTED] wrote:
Sorry about that. I was used to the previous syntax:
usb_add host:04b6:0005
My guess is that the new syntax is to distinguish it from the
busaddr:addr syntax? It would seem checking for length would
differentiate
[EMAIL PROTECTED] wrote:
lo
Yes I am absolutly sure we need this changes. The usb protocoll is a
very sophisticated work. There is an exactly defined sequence in which
packets are send. (I have made some small documentation about this:
http://217.20.126.200/tino/usb-order-of-events.pdf
[EMAIL PROTECTED] wrote:
this patch breaks some things:
Sorry guys but I could not fix all of it, so I need your help, I didn't
want to destroy anybodys work, but the new api makes it necessary to
change some files:
1. usb-linux.c and usb-bsd.c will not work without adoption of the new api
Lonnie Mendez wrote:
2. I did not test usb-hid and usb-hub
There was a usb tablet device added recently. You may want to cvs
up to account for that.
Disregard that. Just saw it ;p
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
Lonnie Mendez wrote:
known problems:
1. under linux the uhci controller reports an error if no usb device is
connected
The port registers on the uhci controller shows no appropriate
response to an HCHALT command that is issued and so the hcd puts the
controller into global suspend.
lo. The attached patch applied on top of your patchset seems to work
as far as signaling resume goes.
--- a/qemu/hw/usb-uhci.c2006-04-21 11:15:40.0 -0500
+++ b/qemu/hw/usb-uhci.c2006-04-21 11:17:08.0 -0500
@@ -32,6 +32,8 @@
// #define DEBUG
// #define
Hello,
Lonnie Mendez wrote:
Lonnie Mendez wrote:
The port registers on the uhci controller shows no appropriate
response to an HCHALT command that is issued and so the hcd puts the
controller into global suspend.
The problem is more likely that the controller is being suspended
but
[EMAIL PROTECTED] wrote:
you are too fast for me :)
Had to rediff it. Fabrice already put the necessary bits in
uhci_update_irq. Right in front of my eyes too.
There is some funkiness going on with removing the device in the
linux guest once attached. Not sure what it is yet.
---
Lonnie Mendez wrote:
There is some funkiness going on with removing the device in the
linux guest once attached. Not sure what it is yet.
This problem is addressed in the attached patch.
--- a/qemu/hw/usb-uhci.c2006-04-21 11:15:40.0 -0500
+++ b/qemu/hw/usb-uhci.c
lo. A few more things to note in the current problems category:
-emulated devices don't seem to be interacting:
frame 36: pid=SETUP addr=0x00 ep=0 len=8
data_out= 80 06 00 01 00 00 40 00
frame 37: pid=SETUP addr=0x00 ep=0 len=8
data_out= 80 06 00 01 00 00 40 00
frame 38: pid=SETUP
Another patch. This one does a few things:
-fixes minor output bugs and some various OBO bugs
-adds some improvements to the emulated hub
-sets up the emulated devices to use the generic message handler (they
now work again)
-makes tablet device visible to usb_add
There are of course
[EMAIL PROTECTED] wrote:
With this patch applied I could detect a USB Epson Scanner and a USB
Epson Printer from Windows 98 + XP and I could even print pages with
the printer (see known problems below).
reasons for this patch:
I was looking for a way to address my USB printer with windows
Hello Lonnie,
First, thank you for the answer.
Lonnie Mendez wrote:
[EMAIL PROTECTED] wrote:
printer was not even detected under qemu. So I started to work on it.
Are you sure such vast changes are necessary? What was it exactly
that happened when you attached the printer/scanner? I'd
36 matches
Mail list logo
