Hi,
On 05/03/2012 12:19 AM, Pete Batard wrote:
> If we're going to have a bugfix release by the end of the week, I wouldn't
> mind also having at least one useful new feature besides the fix.
>
> Timestamped logging looks like a good candidate, but we may want to improve
> on Peter's implementat
Hi,
On 05/02/2012 12:33 PM, Pete Batard wrote:
> On 2012.05.02 09:28, 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 driver for the othe
On Thu, May 3, 2012 at 3:44 PM, Hans de Goede wrote:
> Looks good to me!
>
>> Also note that on POSIX, the tid is obtained through syscall(SYS_gettid).
> I expect it to work everywhere, but I have only tested the call on Linux.
>
> I think we should get this tested on *BSD before shipping 1.0.11.
On 02/05/12 22:58, Pete Batard wrote:
> On 2012.05.02 17:33, Toby Gray wrote:
> This could lead to one of two deadlocks:
>
> 1) If the transfer completes while usbi_fd_notification() is waiting for
> the event lock and the callback attempts to resubmit the transfer.
> So transfer completes and we g
Without this change the Windows backend needed to call usbi_fd_notification()
from within the backend's submit_transfer. This could cause deadlock
when attempting to lock the event lock if another thread was processing
events on the just-submitted transfer.
The deadlock comes about as the thread c
On 2012.05.03 08:55, Hans de Goede wrote:
> Well you've hotplug and hotplug, 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.
Which will happen when
On 2012.05.03 10:36, Xiaofan Chen wrote:
> On Thu, May 3, 2012 at 3:44 PM, Hans de Goede wrote:
>> I think we should get this tested on *BSD before shipping 1.0.11.
Agreed. In case you wonder, I still plan to have an RC for 1.0.11.
> Integrated this in git and I should be able to carry out tests
Hi,
On 05/03/2012 12:40 PM, Pete Batard wrote:
> On 2012.05.03 08:55, Hans de Goede wrote:
>> Well you've hotplug and hotplug, 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
On 2012.05.03 02:47, Xiaofan Chen wrote:
> Also Tim's view on this topic in the OSR mailing list / forum.
> http://www.osronline.com/showthread.cfm?link=223812
> +++
> One can also argue that this is a security measure. The USB spec
> requires that the low byte of wIndex be set to the interfac
On 2012.05.03 11:55, Hans de Goede wrote:
> IMHO the current libusbx-1.0.x behavior on windows is a bug and needs
> to be fixed,
IMHO, not having hotplug in libusb(x) is a major bug, rather than a just
another very desirable feature, that should be fixed ASAP. In terms of
priority, besides criti
On 2012.05.03 11:25, Toby Gray wrote:
> Without this change the Windows backend needed to call usbi_fd_notification()
> from within the backend's submit_transfer. This could cause deadlock
> when attempting to lock the event lock if another thread was processing
> events on the just-submitted trans
Hi,
On 05/03/2012 01:13 PM, Pete Batard wrote:
> On 2012.05.03 11:55, Hans de Goede wrote:
>> IMHO the current libusbx-1.0.x behavior on windows is a bug and needs
>> to be fixed,
>
> IMHO, not having hotplug in libusb(x) is a major bug, rather than a just
> another very desirable feature, that sh
On Thu, 3 May 2012, Xiaofan Chen wrote:
> Last time we have a long discussion here and there is no good
> solution to the following ticket.
> http://www.libusb.org/ticket/125
> libusb_kernel_driver_active() and _detach() are racy
> "If the functionality is to be kept in the next API then let's do
Hans Petter Selasky wrote:
> In the answers from the Microsoft guy, there were some arguments about
> security. Many kind of device drivers could have been made more secure by
> moving out of the kernel, for example webcam drivers, which is a class of
> devices which are especially using a lot o
On Thursday 03 May 2012 19:02:35 Tim Roberts wrote:
> Hans Petter Selasky wrote:
> > In the answers from the Microsoft guy, there were some arguments about
> > security. Many kind of device drivers could have been made more secure by
> > moving out of the kernel, for example webcam drivers, which i
Hello
I am new to libusbx and I have one basic question
I would like to determine to which usb port particular device is attached.
I can see this information with UsbView from Microsoft or UsbDeview program.
I have tested lisdev.c program from examples directory however function
libusb_get_devic
Patch has now been pushed.
I also pushed a fix for xusb, as a result of the WinUSB limitations
discussion.
Regards,
/Pete
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security
After testing on OS X, and finding the syscall didn't work, it seems
that each POSIX platform has its own way of getting a thread ID.
This v2 of the patch should ensure that all the libusbx supported
platforms return a valid thread ID. It was tested for OS X and Linux,
but not for BSD.
Regar
Hi Janko,
On 2012.05.03 13:23, Janko Kolar wrote:
> I would like to determine to which usb port particular device is attached.
> I can see this information with UsbView from Microsoft or UsbDeview program.
This is the topology call, which we plan to implement in the v1.0.12
release of libusbx -
On Thu, 3 May 2012 23:20:09 +0100, Pete Batard said:
>+#elif defined(__APPLE__)
>+ ret = mach_thread_self();
>+ mach_port_deallocate(mach_task_self(), ret);
Perhaps I missed an earlier discussion, but why drop to the mach level?
Wouldn't pthread_self() be more portable?
--
_
On 2012.05.03 14:22, Hans de Goede wrote:
>> What are your constraints there?
>
> We need a solution in say max a month from now.
Realistically, I don't think we can have an hp solution by then, so that
means we'll probably need to apply the patch.
Regards,
/Pete
--
On 2012.05.03 23:27, Sean McBride wrote:
> On Thu, 3 May 2012 23:20:09 +0100, Pete Batard said:
>
>> +#elif defined(__APPLE__)
>> +ret = mach_thread_self();
>> +mach_port_deallocate(mach_task_self(), ret);
>
> Perhaps I missed an earlier discussion, but why drop to the mach level?
> Would
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 received? Ie. when a device driver changes,
does the sa
23 matches
Mail list logo
