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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
With all due respect, Tino Seifert, I must comment on your USB patch. I do
not normally post to this list, but I follow it very closely as the project
is of great interest to me. I must admit that I have rarely even looked at
qemu code, and that I
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 susp
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 2006-
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 1
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,
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
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
Johannes Schindelin wrote:
Also, you rename some things when it has no apparent use to rename them,
such as usb_device_add, or product_name.
Sorry but on that point you say things which are in no case provable by
any study.
Also kindly look into line 1417 and 1419 of your patch.
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,
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 pat
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
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
> 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.
> t
Hello,
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
the patch which applies cleanly agai
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 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 a
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 blocki
[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 the
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 ca
[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 synt
>
> 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 commo
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 add_usb_dev
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 re
[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 s
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 don't
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 att
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 more
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 add
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.c20
[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.
--- a/q
you are too fast for me :)
Lonnie Mendez wrote:
> lo. The attached patch applied on top of your patchset seems to
> work as far as signaling resume goes.
>
>
>
>
___
Qemu-de
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 suspe
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 DEBUG_PAC
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.
T
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
http:/
[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
[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
http:/
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/scanne
[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 while
Hello everybody,
I have extended the USB support for Qemu. The patch is included and
compiles just fine against todays cvs repository. As explained below,
this patch touches 15 different files, which makes it not so easy to
keep it applying on that very fast developing project. Thats why I would
a
41 matches
Mail list logo
