On 08/13/2012 02:30 PM, Uri Lublin wrote:
> After that xusb was able to successfully read read a block from a usb
> mass storage device.
>
> Hoping for a miracle, I tried usbredir, but it failed with a bunch of
> "the device is not connected" error messages.
These er
36b613f40a16e5eff Mon Sep 17 00:00:00 2001
From: Uri Lublin
Date: Sun, 12 Aug 2012 18:13:52 +0300
Subject: [PATCH] windows_usb: filter_driver: pass char* filter_driver
Since the callee function does not allocate the buffer, only fills it
there is no need to pass char **.
Also since the buffer is
On 07/05/2012 10:17 PM, Pete Batard wrote:
> On 2012.07.05 13:55, Uri Lublin wrote:
>> .libs/libusbredirhost_la-usbredirhost.o: In function
>> `usbredirhost_send_device_connect':
>> ../src/usbredirhost/usbredirhost.c:356: undefined reference to
>> `libus
file
Note that I did not check if those patches (specifically Patch 2)
changes the ability of the library to be used by Windows tools.
Also do you prefer in Patch 1 the help to be (from commit message):
"Enable MinGW and MSVC DLL interchangeability"
Thanks,
Uri.
Uri
When mingw-building libusbx with dlltool (create_import_lib), a mingw-build of
code using libusbx (usbredirhost) fails with errors similar to the following:
.libs/libusbredirhost_la-usbredirhost.o: In function
`usbredirhost_send_device_connect':
../src/usbredirhost/usbredirhost.c:356: undefin
It seems that breaks mingw build of usbredirhost
With this patch, users can disable create_import_lib by running
configure --enable-create-import-lib=no
Default is "yes" (for mingw), as it was before this patch.
Related commit: 6b33cd4 (Windows: Enable MinGW and MSVC DLL interchangeability)
On 05/22/2012 04:30 AM, Xiaofan Chen wrote:
> On Mon, May 21, 2012 at 8:11 PM, Hans de Goede wrote:
The problem is that with usb device redirection we can have 1 device
already redirected, and then the user asks to redirect another device
to the virtual machine, so we install a driv
On 05/17/2012 04:27 PM, Peter Stuge wrote:
> Uri Lublin wrote:
>>>> Only if old backend api is UNSUPPORTED.
>>> Hm. Shouldn't the check be done unconditionally - and for all
>>> devices, ie. in every pass except perhaps HCD? Otherwise I think
>>> t
On 05/15/2012 08:57 AM, Peter Stuge wrote:
> Uri Lublin wrote:
>> Only if old backend api is UNSUPPORTED.
> Hm. Shouldn't the check be done unconditionally - and for all
> devices, ie. in every pass except perhaps HCD? Otherwise I think the
> bug still bites when install
On 05/15/2012 03:08 PM, Pete Batard wrote:
> On 2012.05.14 19:47, Uri Lublin wrote:
>> BTW, is the plan for libusbx hotplug feature to also install the libusb
>> driver ?
> Not really. This would pretty much require integrating libwdi or some
> other driver installation fa
On 05/14/2012 03:12 PM, Pete Batard wrote:
I addressed this point already. It doesn't matter if you modify libusbx
or add an extra layer on top of it. The issue is you are replicating a
feature that libusbx is planning to provide, and that, as far as I could
see from my tests, unless somebody els
On 05/14/2012 01:41 AM, Pete Batard wrote:
> So, in summary, the issue is:
> - you have developed a custom solution/layer to add hotplug to libusbx,
> even as libusbx is going to officially implement the very same feature,
> internally, in a manner that is likely to be quite different from yours.
On 05/14/2012 06:22 PM, Pete Batard wrote:
> On 2012.05.14 16:48, Uri Lublin wrote:
>> The scenario I was looking at is:
>> libusb_get_device_list
>> device = go over the list of devices and find the one with
>> appropriate vid,pid
>> l
On 05/10/2012 02:28 PM, Pete Batard wrote:
> On 2012.05.01 16:52, Uri Lublin wrote:
>> Only if old backend api is UNSUPPORTED.
>>
>> This happens when a libusb driver (e.g. WinUSB) is installed
>> after a device has been setup/discovered (with get_device_list).
>
&g
On 05/04/2012 07:07 AM, Peter Stuge wrote:
> Hans de Goede wrote:
>> what is expected by spice is that after it detects a hotplug itself
>> (through platform dependent code) that it can then do a new
>> libusb_get_device_list() call and the new device will be there.
> What hotplug events are receiv
On 05/02/2012 01:42 PM, Xiaofan Chen wrote:
> On Wed, May 2, 2012 at 6:39 PM, Uri Lublin wrote:
>
>> The application (spice-gtk) may live for a long time before a device
>> is to be accessed. Only when the user requests a USB device
>> to be shared with a guest (or a remot
On 05/01/2012 08:54 PM, Peter Stuge wrote:
> Uri Lublin wrote:
>> Only if old backend api is UNSUPPORTED.
>>
>> This happens when a libusb driver (e.g. WinUSB) is installed
>> after a device has been setup/discovered (with get_device_list).
>> Is there a better wa
On 05/02/2012 12:18 AM, Pete Batard wrote:
> On 2012.05.01 15:34, Uri Lublin wrote:
>>> Assuming you don't need to change the device's install class,
>> I'm think that assumption is not true with WinUSB based libusb driver.
>> A new install class is created f
On 05/02/2012 01:15 PM, Pete Batard wrote:
> On 2012.05.02 10:36, Uri Lublin wrote:
>>> I think the idea of using an environmental variable is a good
>>> compromise, and I don't have much of an objection to it, but like Peter,
>>> I would like to know if NOCONFIG
On 05/01/2012 11:29 PM, Pete Batard wrote:
> On 2012.05.01 16:52, Uri Lublin wrote:
>> Only if old backend api is UNSUPPORTED.
>>
>> This happens when a libusb driver (e.g. WinUSB) is installed
>> after a device has been setup/discovered (with get_device_list).
>>
On 05/01/2012 11:06 PM, Pete Batard wrote:
> On 2012.05.01 16:56, Uri Lublin wrote:
>> For example usefull when running autogen.sh in src-dir and
>> running configure in a (different) build-dir.
> We had a discussion previously (on a different mailing list) about
> removing
On 05/01/2012 08:19 PM, Peter Stuge wrote:
> Uri Lublin wrote:
>> For example usefull when running autogen.sh in src-dir and
>> running configure in a (different) build-dir.
>> ---
>> autogen.sh |4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-
On 05/01/2012 11:00 PM, Pete Batard wrote:
> Thanks for this. The usbi_fd_notification calls were indeed
> inadvertently removed, and I have now pushed your fix to the git repository.
Thanks.
--
Live Security Virtual Con
On 05/01/2012 08:16 PM, Peter Stuge wrote:
> Uri Lublin wrote:
>>> Commit 4cccbed825fe1dc13812 removes the possibility to choose between
>>> DYNAMIC_FDS and not, and makes the previously optional behavior
>>> enforced, so the code in !defined() was likely removed on
Only if old backend api is UNSUPPORTED.
This happens when a libusb driver (e.g. WinUSB) is installed
after a device has been setup/discovered (with get_device_list).
---
We want to install libusb driver for USB devices dynamically following a
request by users. There is a problem however to acces
For example usefull when running autogen.sh in src-dir and
running configure in a (different) build-dir.
---
autogen.sh |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/autogen.sh b/autogen.sh
index 782bec7..2a05191 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -15,4 +15,6
On 04/30/2012 08:44 PM, Tim Roberts wrote:
> Arnon Gilboa wrote:
>> Tim Roberts wrote:
>>> although I suspect it
>>> would be easier just to rewrite the Enum registry entry to switch to the
>>> new service.
>>>
>> Can you pls explain this point?
> Assuming you don't need to change the device's inst
On 05/01/2012 04:59 PM, Peter Stuge wrote:
> Uri Lublin wrote:
>> Commit 4cccbed825fe1dc13812 accidently removed those calls,
>> when ! ifdef DYNAMIC_FDS blocks were removed.
> Commit 4cccbed825fe1dc13812 removes the possibility to choose between
> DYNAMIC_FDS and not, and
Commit 4cccbed825fe1dc13812 accidently removed those calls,
when ! ifdef DYNAMIC_FDS blocks were removed.
---
libusb/os/windows_usb.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c
index 709157a..1957964 100644
--- a/lib
29 matches
Mail list logo
