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
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
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 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?
--
_
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 -
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
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
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
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
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 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
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 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
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 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
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 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
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
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 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
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.
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
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
23 matches
Mail list logo
