| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The usbredir 0.5 release introduced the new API for 64 bit packet ids, but
it kept the libusbredirparser.pc name as is, meaning that older versions of
qemu will still have their pkg-config check for usbredirparser fulfilled,
and build with the usb-redir device. Due to the API change there will be
some compiler warnings, but the build will succeed, however the usb-redir
device will be broken on 32 bit machines.
To solve this, this patch renames the libusbredirparser.pc file to
libusbredirparser-0.5.pc, so that it will no longer fulfill the pkg-config
check of the qemu-1.2 and older releases, stopping the (silent) breakage.
A patch has been send to qemu-devel to adjusts qemu master's configure.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
If the write queue gets too large our network connection likely is not keeping
up. The best (and only) thing we can do then is drop isoc input packages,
these are also the likely cause of this, since all other transfer types more
or less auto-adjust to the network speed (rhbz#855737).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Instead of only returning 0 or 1, this can be used for flowcontrol purposes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
-ABI and API breakage !!
-Bump libusbredirparser soname version
-Change version to 0.5 so that libusbredirparser users can test for the new API
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
With the upcoming qemu changes (for live migration), once a packet has been
cancelled its id may be reused for another packet immediately afterward,
the usb-guest will then expect to first get the reply to the cancelled packet,
and then to the new packet with the same id. But the actual cancellation can
finish later then the new packet.
To avoid this, this patch moves the sending back of the cancelled packet to
the usb-guest to immediately after receiving the cancel, rather then waiting
for the usb-host OS to mark the packet as completed or cancelled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Make log messages prefix constant, rather then dependent on the log level
so that it can be easily removed by the higher levels if desired, even
when translated.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
After upstream review of the libusb patch for returning ERROR_BUSY from
libusb_detach_kernel_driver if the uswbfs driver is already bound, the
behavior has been changed to instead return ERROR_NOT_FOUND. This means that
the userfriendly device is busy error test is now done in the wrong place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Bulk packets can be (ab)used as interrupt transfers without timing guarantees,
iow you can submit a bulk in transfer and let it be submitted until the
device has data to reports a few eons later.
This is used by (some?) USB cdc-acm devices (modems, smartcard readers, gps
devices), specifically a smartcard reader I've been debugging, which currently
does not work.
Not setting a timeout at the usb-host side fixes these devices. For devices
where timeouts do make sense, the timeouts should be handled by the usb-guest,
which has device specific knowledge we lack.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
On Windows libusb_(attach|detach)_kernel_driver are not supported.
A libusb driver is already installed (device was successfully opened).
In that case just continue as if operation was successful.
|
|
In libusb.h the following definition appears:
typedef void (LIBUSB_CALL *libusb_transfer_cb_fn)(struct libusb_transfer *transfer);
Added LIBUSB_CALL to the following functions:
usbredirhost_iso_packet_complete
usbredirhost_interrupt_packet_complete
usbredirhost_control_packet_complete
usbredirhost_bulk_packet_complete
This fixes the following compiler warning for Windows (mingw):
./usbredirhost/usbredirhost.c: In function 'usbredirhost_alloc_iso_stream':
./usbredir/usbredirhost/usbredirhost.c:1206:13: warning: passing argument 7 of 'libusb_fill_iso_transfer' from incompatible pointer type [enabled by default]
|
|
On Windows (mingw), ERROR is already defined (to 0)
This fixes the following compiler warning:
warning: "ERROR" redefined [enabled by default]
|
|
In some cases a usb-guest does multiple resets in a row, these are instant
from the guest pov but they are synchronously handled by us. So if a usb-guest
does 4 resets in a row (seabios does this) then we can accumulate quite a
bit of latency, sometimes so much that guests cancel a submitted transfer
because they think it has timed out while we simply have not gotten around
to handling it.
This patch fixes this issue by speeding up resets in a number of ways:
1) Keep track of a reset state, if the device was reset and no requests
were send to it since, this is true. In this case further resets are
treated as a no-op.
2) Since the first thing most guests do is a reset, do one as soon as we
open the device.
3) Remove the sleep we had in our reset code, as it is not necessary,
actually the kernel already fires multiple commands to the device
before the libusb_reset_device call returns...
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Instead of rejecting (when trying to open) or crashing (when the device
was set to unconfigured state from the guest), properly handle unconfigured
devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
This new field is only send / received if both sides have the (new)
usb_redir_cap_ep_info_max_packet_size capability.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Before this patch we were reporting unused endpoints as having a
type of control rather then invalid after a set_interface on interface 0.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Failure to reset a device means that we've lost the device, report this
to the user by returning usbredirhost_read_device_lost from the
usbredirhost_read_guest_data call which triggered the reset.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
An usbredirhost_claim failure always gets followed by a
usbredirhost_clear_device call, so there is no need to cleanup / undo
claiming of interfaces in the error path.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
No callers are interested in the return value, so lets just make it void.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
If we fail to change the config we still need to re-claim the device, otherwise
we loose access to it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
So cleanup on failure to re-claim after a set_config, and let our user know
that we've lost the device with a new usbredirhost_read_device_lost status.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
So that the same mechanism can be used to return other errors too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Changing the configuration of a device causes the drivers to get
re-attached by the kernel, so we need to detach them after a set_config
too. Since we then always detach the drivers we can drop the detach_drivers
argument to usbredirhost_claim().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
The set_config code path releases the interface without re-attaching the
kernel drivers. If after this the actual set_config call or the re-claim
failed the claimed flag would be 0, resulting in device cleanup not
re-attaching the kernel drivers.
So this patch keeps the claimed flag set to 1 when usbredirhost_release
only releases the interfaces without re-attaching the kernel drivers, to
ensure that they are properly re-attached on any later cleanup.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Before this patch we kept track of if we actually detached the kernel
driver, and would only then re-attach the kernel driver.
But if an app is using auto-redirection there is a chance that we
claim the interface before the kernel driver got a chance to attach, this
esp. happens when the module first needs to be loaded by udev. This scenario
would leave people with USB-devices without devices attached which is very
rarely what people want! So this patch changes our behavior to instead always
re-attach the kernel drivers on device cleanup.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
The direct trigger for making this change is the fact that the 0.4 release
is broken due to a return without a value in a non void function. Somehow
this happened to always do the right thing in my testing, but not for others.
This is something which should have been caught by a compiler warning, but
I always build from git, and then no -Wall (let alone -Werror) gets passed
to the compiler, which allowed this to slip through. So to avoid future
embarrassment this patch changes the configure script to add various
compiler options to CFLAGS by default, which should catch most detectable
mistakes.
Note that this change modifies CFLAGS directly, so if you're somehow specifying
your own CFLAGS nothing will change (this is intentional). Also all added flags
are checked, so if you've a compiler which is not gcc nothing will change.
This patch also fixes the few warnings actually present in the code, so as to
not have a state in the commit tree where the code does not compile.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Now that we only re-parse the interface and not the entire config when changing
the alt setting, we must first clear the ep-info of the endpoints currently
belonging to the interface as a different alt setting may have less endpoints!
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Also fix a nasty bug where we would try to cancel the head rather
then the first transfer in the list!
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
See the description of the new usbredirhost_set_device() function in
usbredirhost/usbredirhost.h
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Make this conditional on the same cap as device_reject, rename
the cap to usb_redir_cap_filter. Rename device_reject to filter_reject to
reflect that it is filtering related and that the the cap and packet names
are consistent with each other. Also cleanup some related comments / docs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Remove the wrong comment and move the free outside the locked part
of the function.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Before this patch the code would cancel the iso stream, but keep the transfers,
and then on a successfull clear of the stall re-submit the same transfers.
This means however that the transfers would get resubmitted before their
completion callback from the cancel got to run. And re-submitting an
uncompleted transfer will fail.
So instead cancel and free the stream (getting rid of the single user
of cancel_iso_stream which did not want it to also free the urbs) and
when the stall is successfully cleared, alloc a new stream and, if it is
an input stream, submit its transfers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
When an input interrupt urb failed with an error of LIBUSB_TRANSFER_NO_DEVICE,
we do not resubmit it (which is correct), but we did not set endpoint.interrupt
in_transfer to NULL either, so later on we would try to cancel the non
submitted urb.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Add an usb_redir_device_reject packet to allow notifying the usb-host when
an usb-guest rejects a device because of usb-guest side device filtering.
Also bump the version to 0.3.4 so that apps can check if libusbredirparser /
libusbredirhost knows about usb_redir_device_reject by checking the version
number.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
When changing the active configuration we must first release all interfaces,
this is done by the usbredirhost_release() helper function, but before
this patch that function also re-attached the in kernel driver, making
the interfaces busy again and causing the set_config call to fail.
This patch fixes this by not doing the kernel driver re-attach when
releasing the interfaces for a set_config call.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
