[Libusbx-devel] Announce libusb-1.0.20

Hi All, I'm pleased to announce the libusb-1.0.20 final release. It has been over a year since the last release, and a lot of changes have gone in during that time (95 commits). Changelog: * Add Haiku support * Fix multiple memory and resource leaks (#16, #52, #76, #81) * Fix possible deadlock w

[Libusbx-devel] Announcing libusb-1.0.20-rc3

Hi All, I'm pleased to announce the libusb-1.0.20-rc3 release. This release comes soon after rc2 to address a regression found in the previous releases. It has been over a year since the last release, and a lot of changes have gone in during that time (95 commits). Changelog: * Add Haiku support

Re: [Libusbx-devel] Compiling the libu

Hi, On Wed, Sep 2, 2015 at 9:14 PM, Pradeepa Senanayake < pradeepa.for...@gmail.com> wrote: > We are trying to install the latest libusbx package (1.0.18) to our > system. But we found out that there is a dependency for libudev. Since that > lib is not available in our current BSP we cannot insta

[Libusbx-devel] Announcing libusb-1.0.20-rc2

Hi All, I'm pleased to announce the libusb-1.0.20-rc2 release. It has been over a year since the last release, and a lot of changes have gone in during that time (92 commits). Changelog: * Add Haiku support * Fix multiple memory and resource leaks (#16, #52, #76, #81) * Fix possible deadlock whe

[Libusbx-devel] Announcing libusb-1.0.20-rc1

Hi All, I'm pleased to announce the libusb-1.0.20-rc1 release. It has been over a year since the last release, and a lot of changes have gone in during that time (86 commits). 2015-07-29: v1.0.20 * Add Haiku support * Fix multiple memory and resource leaks (#16, #52, #76, #81) * Fix possible dea

Re: [Libusbx-devel] [libusbx] Windows: hotplug/unplug support (#9)

Hi, If this is a matter of stepping up and volunteering, I would be more than willing to. I've been using libusb with my hotplug implementation on Windows for over 6 months now. It's on a cross-platform utility in which hotplug functionality is the single most important feature, where multiple dev

Re: [Libusbx-devel] 32-bit libusbx broken on earlier 64-bit Linux kernels

Hi Hans, Patch works as expected, thanks! Regards, Chris On Tue, Mar 11, 2014 at 10:45 AM, Hans de Goede wrote: > Hi Chris, > > > On 03/11/2014 05:27 PM, Chris Dickens wrote: > >> Hi Hans, >> >> Are you sure this is what was happening ? Can you perhaps

Re: [Libusbx-devel] 32-bit libusbx broken on earlier 64-bit Linux kernels

Hi Hans, Are you sure this is what was happening ? Can you perhaps try again with > a printf added at a strategic place to ensure this is really what is going > on? > Here's the debug output right after the DISCONNECT_CLAIM fails: [ 0.004913] [7d79] libusb: debug [libusb_claim_interface] int

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

- but the library pointing to it is a copy of the lib linked > against above: > libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0xb70ba000) > > Any further ideas? > > Best regards, > > Erik > > Chris Dickens wrote: > >> Hi Erik, >> >> Sourceforg

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

ell you if I have a too old version. > <http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a= > commit;h=858b794cf10ff1ac76a4f453bed7645aa9709c44> > > Would be nice if you could point me to the commit, thanks. > > Best regards, > > Erik > > >

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

ely - and not getting a SEGV. > > If I add a usleep(1000) as the first line in the discard-urb routines > everything goes fine - no SEGV. > > Best regards, > > Erik > > > Chris Dickens wrote: > >> This line tells a lot of the story: >> >> [ 6.849000] [0

Re: [Libusbx-devel] SIGSEGV in list_del / io.c

This line tells a lot of the story: [ 6.849000] [1fae] libusbx: debug [libusb_unref_device] destroy device 2.57 This can only happen when a device's refcount == 0, which should not happen while an active transfer is occurring. When a device is enumerated, its refcount is 1. When you open the

Re: [Libusbx-devel] why not support hotplug usb ?

The linker is linking against your system's libusb at runtime instead of your compiled one. You have two options: 1) Tell the linker to link against your libusb by using the following line in the Makefile: $(CC) $(CFLAGS) -g -o zinFrameLinuxV6 $(SRC) -L./ -lusb-1.0 -Wl,-rpath,. 2) Set LD_LIBRARY_P

Re: [Libusbx-devel] Major problems using libusbx on CentOS 5

Sep 17 00:00:00 2001 From: Chris Dickens Date: Thu, 30 Jan 2014 01:40:55 -0800 Subject: [PATCH] Remove hotplug functionality for Linux backend. --- configure.ac| 21 libusb/Makefile.am | 10 +- libusb/os/linux_usbfs.c | 253

Re: [Libusbx-devel] Major problems using libusbx on CentOS 5

You are going to have trouble using the same interface from two different processes. Linux maintains exclusive access for a process once it has claimed an interface until it is released or the file descriptor is closed (either intentionally or from the process exiting). If you claim the interface i

Re: [Libusbx-devel] [libusbx] Windows: hotplug/unplug support (#9)

Sorry for the delayed reply. Been battling some harsh illness in my household. You can find my code here: https://github.com/dickens/libusbx-hp/tree/windows-hotplug-3 On Thu, Jan 16, 2014 at 11:40 PM, mcuee wrote: > @Chirs : Nice. Where do you keep you code? > > — >

Re: [Libusbx-devel] [libusbx] Windows: hotplug/unplug support (#9)

Hi All, I have been needing hotplug support on Windows for quite some time, so I was eager to start testing this code. I've finally had the chance to, and I think it's a great start (thanks Manuel for your groundwork!!). Here's my preliminary findings: 1) The way that the hubs are enumerated is b

Re: [Libusbx-devel] Can't close and re-open an interface/device

mit_transfer(). The pointers should have different values. If it's the same, your application is trying to use the original handle. Regards, Chris To be thorough, you didn't specify that opened the newly discovered device. > A segfault at usbi_mutex_lock() means it was using freed memory, which >

[Libusbx-devel] Can't close and re-open an interface/device

To be thorough, you didn't specify that opened the newly discovered device. A segfault at usbi_mutex_lock() means it was using freed memory, which means you likely used a stale libusb_handle. Are you using hotplug notifications to find your device or using libusb_get_device_list()? In either case,

[Libusbx-devel] 32-bit libusbx broken on earlier 64-bit Linux kernels

Hi, I recently had the need to compile a 32-bit version of the libusbx library (v1.0.17) on a 64-bit RHEL 6.5 system (Linux Kernel v2.6.32). What I found was that libusbx does not function properly when auto_detach_kernel_driver is set to be used. The error-handling code in detach_kernel_driver_an

Re: [Libusbx-devel] Android build files and improved logging patches, (was "Improved log in non-console applications and Android")

Yes, love the syslog facility! Thanks very much Toby! Regards, Chris Dickens On Thu, Aug 8, 2013 at 6:09 PM, Pete Batard wrote: > On 2013.08.08 18:35, Toby Gray wrote: > > I've attached a rebase of patches 1 to 4 onto the master branch of > libusbx. > > Thanks. Much

[Libusbx-devel] [PATCH] Core: Fix potential segfault caused by using freed memory

When a transfer is submitted, the device is referenced in libusb_submit_transfer() and unreferenced in usbi_handle_transfer_completion(). This transfer could potentially be freed by any user callback, or is freed by libusb if LIBUSB_TRANSFER_FREE_TRANSFER is set in the flags. The call to unrefer

Re: [Libusbx-devel] [PATCH 0/2] linux: Fix (sporadic) deadlock on libusb_exit

: > Hi, > > On 07/19/2013 11:06 AM, Hans de Goede wrote: > > Hi All, > > > > I had some inspiration this morning how to fix the deadlock Chris Dickens > > found as a result of the bugreport I forwarded. > > > > So here is a fix for it. I'

Re: [Libusbx-devel] Fwd: [Bug 985484] New: Deadlock in linux_udev_event_thread_main at os/linux_udev.c:153

Hi, I have identified the problem. When libusb_exit() is called, the linux backend will acquire the linux_hotplug_lock before calling linux_stop_event_monitor(). In this user's particular case, it looks like the event monitor thread is seeing activity from udev and then tries to acquire the linux_

[Libusbx-devel] [PATCH] core: Fix error in signed vs. unsigned comparison in handle_events()

For messages received on the hotplug pipe, the message was read via usbi_read() (ssize_t) and compared against the size of the message struct (size_t). usbi_read() returns -1 on an error condition, so some systems can cast the ssize_t to size_t for the comparison, making it equal to SIZE_MAX and ca

Re: [Libusbx-devel] libusb_open_device_with_vid_pid () on a composite device

Hi, libusb_open_device_with_vid_pid() opens the composite device and returns you a device handle. This process does not claim any interface. Performing any device functions (e.g. claim/release interface, get/set configuration, read/write, etc.) requires a device handle, so you can use what you ge

Re: [Libusbx-devel] [Patches for 1.0.16 0/2]: Allow hotplug users to wakeup handle_events

Hi, This is the exact same problem I am experiencing in my app. I am very much in favor of this change. Regards, Chris On Thursday, July 4, 2013, Hans de Goede wrote: > Hi All, > > So to make sure the API is sane, and to give the hotplug stuff some extra > testing, I've ported Spice's usbredir

Re: [Libusbx-devel] Improving linux hotplug disconnect

Hi, On Thu, Jun 27, 2013 at 3:31 AM, Hans de Goede wrote: > Hi, > > +/* device will still be marked as attached if hotplug monitor thread >> +* hasn't processed remove event yet */ >> +if (handle->dev->attached) { >> > > This check is racy, you need to take the hotplug lock before making this

Re: [Libusbx-devel] umask affects libusb_attach_kernel_driver()

Yes, devtmpfs. Linux Kernel is 2.6.32-358 (RHEL6). Regards, Chris On Wed, Jun 26, 2013 at 8:23 AM, Hans de Goede wrote: > Hi, > > > On 06/25/2013 11:27 PM, Chris Dickens wrote: > >> Hi, >> >> I have discovered that the libusb process's file mask affe

Re: [Libusbx-devel] Improving linux hotplug disconnect

Hi, On Wed, Jun 26, 2013 at 8:34 AM, Hans de Goede wrote: > Hi, > > Hmm, the libusb_poll call in get_device_list() should make this quite hard > to trigger, this will only > happen if udev has not yet read the kernel event, and send an event on its > own socket. Which likely > means that your se

[Libusbx-devel] Improving linux hotplug disconnect

Hi, I have noticed some behavior that I believe most users will find undesirable. The situation is this: 1) The application opens a libusb device, which adds this to the poll fds 2) While the device is opened and IO is occurring, the device reboots or otherwise disappears from USB 3) When the dev

Re: [Libusbx-devel] [PATCH] Initialize auto_detach_kernel_driver to 0 for new handle

Sorry, here's the patch with correct whitespace. Regards, Chris 0001-core.c-Initialize-auto_detach_kernel_driver-to-0-for.patch Description: Binary data -- This SF.net email is sponsored by Windows: Build for Windows St

[Libusbx-devel] [PATCH] Initialize auto_detach_kernel_driver to 0 for new handle

Hi, I have discovered that the auto_detach_kernel_driver functionality was being randomly used by devices that I had not explicitly set to use it. The root cause is that the value was never initialized after allocating the new handle. This patch fixes this issue. Chris 0001-core.c-Initialize-au

[Libusbx-devel] umask affects libusb_attach_kernel_driver()

Hi, I have discovered that the libusb process's file mask affects how libusb_attach_kernel_driver() restores the driver. In my particular case, I am dealing with usblp, so the kernel enumerates /dev/usb/lpX device files. The /dev/usb folder is created and destroyed as necessary for the devices. W

[Libusbx-devel] RFC: Make usbi_log_v() print atomically to stderr

idea? Regards, Chris Dickens -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ libusbx-devel mailing list libusbx-

Re: [Libusbx-devel] hotplug_poll() on Linux hangs

rote: > > > On Jun 14, 2013, at 02:58 AM, Hans de Goede wrote: > > Hi, > > On 06/14/2013 10:19 AM, Chris Dickens wrote: > > Hi, > > > > All looks good now, thanks! > > > > I actually went with the F_GETFL/F_SETFL approach first, then I saw how

Re: [Libusbx-devel] hotplug_poll() on Linux hangs

ede wrote: > Hi, > > > On 06/13/2013 08:16 PM, Chris Dickens wrote: > >> Hi, >> >> Here's the patch. >> > > Thanks, I've just pushed a somewhat modified version to master, I made 2 > changes: > > 1) Use F_SETFL rather then F_SETFD as a

[Libusbx-devel] hotplug_poll() and linux_hotplug_lock

Hi, I see from the git log that the hotplug_poll() function was added for applications that perhaps handled hotplug notification on their own. Given the structure of the new hotplug code, it appears that a context will not be successfully created unless the hotplug monitoring thread can be created

Re: [Libusbx-devel] hotplug_poll() on Linux hangs

Hi, Here's the patch. BTW, I was running RHEL6.4 with libudev 147-2.46. Regards, Chris On Thu, Jun 13, 2013 at 2:23 AM, Hans de Goede wrote: > Hi, > > > On 06/13/2013 12:10 AM, Chris Dickens wrote: > >> Hi, >> >> I'm run

[Libusbx-devel] hotplug_poll() on Linux hangs

this issue for me. Regards, Chris Dickens -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ libusbx-devel mailing

[Libusbx-devel] [PATCH] usbi_handle_disconnect: Fix race condition leading to double completion

Hi, I had run into the same issue and agree with your findings 100%. I took a slightly different approach, and wanted to get feedback as well. --- io.c.orig 2013-02-27 14:33:56.0 -0800 +++ io.c 2013-05-07 14:07:58.022998738 -0700 @@ -1374,16 +1374,10 @@ goto out; } - r = add_to_flyin