signal11 / hidapi Goto Github PK

The read callback will currently hang if a transfer status of LIBUSB_TRANSFER_ERROR occurs. There is a simple fix.

Hi,
This is related to Windows 7 x64, no other platform tested.

I'm connecting a device for the first time requiring windows to install the device driver.
Although the device driver is not yet installed, hid_enumerate already returns the device in the list.

Subsequently hid_open works but understandably hid_read/write fail (since the device driver is not yet installed).

Now windows disconnects this device (hid_enumerate doesn't show the device anymore). And a few seconds later, once the driver is installed, the device is again added to the hid_enumerate list and all works well.

The problem now is, that IF the device is open (by hid_open) and Windows disconnects the device (just prior to installing the driver), the whole PC freezes for 20 sec. You can't even move the mouse anymore. Obvioulsy this is very annoying.

The questions are:

1. what's going on ?
2. Is it possible to detect if the device has the driver installed, so that I can delay hid_open until after the correct device is enumeated?
3. Are there other solutions to the problem?

Thank you

The Mac OS X backend uses a static variable static IOHIDManagerRef hid_mgr = 0x0;

The problem occurs with two threads are doing the sequence hid_init() [...] hid_exit()

The first thread to call hid_exit() will release hid_mgr and then the second thread will have problems.

For example I have a crash in hid_enumerate() on line:
CFSetRef device_set = IOHIDManagerCopyDevices(hid_mgr);
because hid_mgr has been reset to NULL.

My workaround is to NOT call hid_exit() so hid_mgr is not released.

A proper solution would be to add a counter of use and really release hid_mgr when no other thread is using HIDAPI anymore.

Hello,

I am starting to play with hidapi on the latest ubuntu 12.04 (64 bit). Great piece of library.

I can enumerate my device correctly, i can print the vid, pid and product string

However, when i try :
handle = hid_open(my_vid, my_pid,NULL);
i get a null pointer (handle = 0)

any idea how can i solve that...?

I have allready added this rule to etc/udev/rules.d/ :

KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="20A0", ATTRS{idProduct}=="4123", MODE="0666"

Thank you very much for your help

On occasion, hid_write fails to return. This happens randomly, and does not seem to be dependent on the message I am sending - I send a nearly identical packet 20k+ times in a row back to back, and it will on occasion lock up at any point in that burst. I believe the root cause to be the device misbehaving.

Can I timeout or abort one of these "stuck" writes?

This is seen on Win 7 x64 running in a 32-bit process. I have not yet tried on Mac or on other Windows versions.

It would be nice to be able to distinguish between a timeout and an actual read error in hid_read_timeout().

In a test application we are continuously doing the following procedure to acquire the required information.

hid_enumerate to find the devices.
Store the device paths for further operations of read write.

once the device is found we open the device handle using hid_open_path(cur-dev->path) after reading/writing the required information we close using hid_close(handle);
then exit using hid_exit();

As and when required we open the device handle using hid_open_path and close the handle and hid_exit.

After performing continuous operations or a lengthy read write operation when we try to close hid_close(handle) the application is crashing. Observed in Mac OS X Mountain lion(10.8.2) especially till now.

Its crashing at hid_close()
CFRunLoopSourceSignal(dev->source);
CFRunLoopWakeUp(dev->run_loop);

repeatedly observed at the above mentioned code.

We are using HIDAPI to work with PS3 controller. The algorithm is very simple. We open the device and it immediately starts sending us packets every 20ms reporting what keys are pressed and joystics status. It works nicely on Linux and Mac, but the same code under Windows 7 does not receive any data.

How can we go about debugging this issue? WHat could be be possibly causing it? Could it be some default initializations window performs? Perhaps something related to endpoint or interface selection?

The calls to setlocale(LC_ALL,""); in functions hid_enumerate() and hid_open_path() seem to be the cause for my application to forget about the locale it sets on start-up.

What is the rationale behind those calls? Could it be done in a way that doesn't interfere with the application's locale setting?

Hi,

First of all, thanks for the HIDAPI. We have been using this api for one of our projects. It's working fine in all windows and different OS versions of Mac OS X but we are getting issues in Mountain Lion (10.8.x).
The issue is with IOHIDManagerCopyDevices() method. First time whenever I launch the application and connect a new HID device, the device list would be updated properly but when I remove the device, the IOHIDManagerCopyDevices() is still giving the same number of devices list and the device is not being removed from the list. From the second time, if we connect and remove the same HID device, the list gets increased and decreased by one with the list still containing the device reference which was connected for the first time.
eg.: At launch before connecting the device,
devices list count = 4;
After connecting the device for the first time,
devices list count = 5;
remove the device, devices list count still remains same.
devices list count = 5;
from now on connect the device once again,
devices list count = 6;
remove the device,
devices list count = 5;

It would be great if someone can check the issue in HIDAPI. The same is working fine if I try create a new Cocoa based application.

It seems like the function register_error() is unused in the libusb, Linux and Mac implementations of hidapi:

.../hidapi% git grep register_error
libusb/hid.c:static void register_error(hid_device *device, const char *op)
linux/hid.c:static void register_error(hid_device *device, const char *op)
mac/hid.c:static void register_error(hid_device *device, const char *op)
windows/hid.c:static void register_error(hid_device *device, const char *op)
windows/hid.c:                  //register_error(dev, "Unable to call SetupDiGetDeviceInterfaceDetail");
windows/hid.c:                  //register_error(dev, "CreateFile");
windows/hid.c:          register_error(dev, "CreateFile");
windows/hid.c:          register_error(dev, "HidD_GetPreparsedData");
windows/hid.c:          register_error(dev, "HidP_GetCaps");    
windows/hid.c:                  register_error(dev, "WriteFile");
windows/hid.c:          register_error(dev, "WriteFile");
windows/hid.c:          register_error(dev, "GetOverlappedResult");
windows/hid.c:          register_error(dev, "HidD_SetFeature");
windows/hid.c:          register_error(dev, "HidD_GetFeature");
windows/hid.c:                  register_error(dev, "Send Feature Report DeviceIoControl");
windows/hid.c:          register_error(dev, "Send Feature Report GetOverLappedResult");
windows/hid.c:          register_error(dev, "HidD_GetManufacturerString");
windows/hid.c:          register_error(dev, "HidD_GetProductString");
windows/hid.c:          register_error(dev, "HidD_GetSerialNumberString");
windows/hid.c:          register_error(dev, "HidD_GetIndexedString");

I would suggest that this function should either be added to hidapi.h (if it's public / to be used by client code) or removed from libusb/hid.c, linux/hid.c, and mac/hid.c - I can provide a trivial patch that removes the functions (right now, it's already "commented out" using the preprocessor directive #if 0...#endif for libusb and Mac, but I still get the compiler warning when building the linux/hidraw variant).

Hello!

I am new to hidapi and tried the sample provided on the signa11 webpage. I'm using the libusb version within a c++ project (included the hid-libusb.c file), in a linux debian wheezy laptop. The enumeration process works perfectly well, but hid_open returns null.
I build the testgui sample and discovered that it behaves the same way, unless I sudo it.
Looks like it's a permission problem, so I read all available docs carefully and added a rules file in my udev configuration, containing the line :
SUBSYSTEM=="usb", ATTRS{idVendor}=="0x00", ATTRS{idProduct}=="0x02", MODE="0666
The vendor ID = 0 comes from the fact my usb device is a home made PIC based usb card.
This does not solve the problem, even after a reboot.
Any help welcome
best regards

When get_device_string() is used on a USB device, the two "goto end" statements can cause memory leaks from failing to free the serial_number_utf8 and product_name_utf8 variables after parse_uevent_info() is called. This fix should take care of it:

stanhu@106ac1f

This is a question regarding my usage of hid.c.

Currently I'm having a thread using hid_enumerate to manage all devices. This thread also performs hid_open/hid_close on all devices.

Independently I have an access thread that performs all read/write functions to the device. I was under the assumption that this works. However studying the hid.c a bit more closely I'm not so sure anymore. It looks like execution of hid_open/close and read/write must be protected by mutex/critical section in case multiple threads are involved.

Is that correct?

Is there a way to make a shared library (.so) for linux. I have it running for windows (it generates a .dll file).

GCC commands how I try to build hidapi:

cc -Wall -g -fPIC -c -I../hidapi pkg-config libusb-1.0 --cflags hid-libusb.c -o hid-libusb.o
gcc -shared -W1,-soname,libHIDAPI.so, -o libHIDAPI.so *.o

But I get:

libHIDAPI.so: undefined symbol: libusb_init

went running my APP (it work prefectly on windows)
I need the shared libraries so that I can interop with mono. Maybe this is a good addition to hidapi. So users don't need to start in C or C++ to write simple hid applications. If you like I want to make the C# bindings opensource.

This should be easy to amend using the hid report descriptor parsing in the libusb implementation

Hi, I've been trying to bypass following issue with Mac OS X 10.5.8 and I have hidapi v 0.7.0 or later. (I remember I have updated some files after finding a issue of not getting device on disconnect and connect.) My issue is similar, but happens when the Mac is placed into sleep.

What I have is:

1. run my program and open the device, I can use the device, I can unplug and replyg the device and my program will reconnect to it.
2. I turn the Mac into sleep.
3. wait abot 5 seconds.
4. press [esc] to bring Mac back into live
   => and the device will show up in hid_enumerate but I can not write into it, write returns -1. Also this device can be connected only after unplug and replug. Closing the application and opening again will not find the device even if trying sleeping while application is closed. It seems that I am hitting kind of osx internal issue.

This will not happen if my application does not run, i.e. the device is not opened. I can sleep the Mac and wake it up and then run the application and connect to device.

Hi Alan,

While testing our app (based on the Microchip HIDBootloader) on 64-bit Linux (Ubuntu 9.04), I was consistently getting segfaults while programming a device. Here is the gdb log (note that my code still periodically polls for devices with hid_enumerate() even when device I/O is in progress):

Sending program data packet with address: 0x3448

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb605397750 (LWP 5747)]
0x00007fb602f1d225 in free () from /lib/libc.so.6
(gdb) bt
#0 0x00007fb602f1d225 in free () from /lib/libc.so.6
#1 0x000000000042a099 in hid_free_enumeration (devs=0x7fb5ec0011b0) at linux/hid-libusb.c:576
…
(gdb) up
#1 0x000000000042a099 in hid_free_enumeration (devs=0x7fb5ec0011b0) at linux/hid-libusb.c:576
576         free(d->manufacturer_string);
(gdb) print *d
$2 = {path = 0x7fb5ec000f60 "0\020", vendor_id = 8279, product_id = 1,
  serial_number = 0x0, release_number = 2, manufacturer_string = 0xffffffffec000b50,
  product_string = 0x0, usage_page = 0, usage = 0, interface_number = 0, next = 0x0}

This is very odd: manufacturer_string is set directly from wcsdup(), and hid_enumerate()/hid_free_enumeration() have run hundreds of times without crashing since the program was started. Either wcsdup() is bad (unlikely), or there's memory corruption somewhere.

I figured I would try cleaning up some compiler warnings, like this one:

linux/hid-libusb.c:364: warning: implicit declaration of function 'wcsdup'
linux/hid-libusb.c:364: warning: assignment makes pointer from integer without cast

After adding #define _GNU_SOURCE and #include <wchar.h> to get rid of that warning I tested again, and it doesn't crash. I've never seen a missing prototype cause such a weird crash but I took a look at the assembly, and it does make a difference. Left side is without wchar.h included, right side is with:

I found this problem when building on 64-bit Ubuntu 9.04, but newer distros like Ubuntu 10.04 (which I did development on) seem to have wchar.h included automatically. This probably explains why no one noticed the bug until now. Here's the change I made:

Index: hid-libusb.c
===================================================================
--- hid-libusb.c    (revision 5169)
+++ hid-libusb.c    (working copy)
@@ -22,6 +22,8 @@
         http://github.com/signal11/hidapi .
 ********************************************************/

+#define _GNU_SOURCE
+
 /* C */
 #include <stdio.h>
 #include <string.h>
@@ -38,6 +40,7 @@
 #include <sys/utsname.h>
 #include <fcntl.h>
 #include <pthread.h>
+#include <wchar.h>

 /* GNU / LibUSB */
 #include "libusb.h"

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
[Switching to process 61712 thread 0x1703]
0x00007fff89770697 in CFSetGetValue ()
(gdb) bt
#0 0x00007fff89770697 in CFSetGetValue ()
#1 0x00007fff8977e5f0 in __CFRunLoopFindMode ()
#2 0x00007fff8978d0f5 in CFRunLoopRemoveSource ()
#3 0x00007fff8d1754f9 in IOHIDDeviceUnscheduleFromRunLoop ()
#4 0x00007fff8d1771bc in __IOHIDManagerDeviceApplier ()
#5 0x00007fff897582d2 in __CFSetApplyFunction_block_invoke_1 ()
#6 0x00007fff89758121 in CFBasicHashApply ()
#7 0x00007fff897580a4 in CFSetApplyFunction ()
#8 0x00007fff8d17739f in IOHIDManagerUnscheduleFromRunLoop ()
#9 0x00007fff8d17740d in IOHIDManagerClose ()
#10 0x000000010002e49b in hid_exit () at hid.c:393

hid_close is called prior to hid_exit. Completely reproducible.

Hey,

This is a great library, and so far I have been using it on windows for my projects at home and it has been working wonders. Thank you very much to the authors!!

But I recently decided to try my hand at running this on linux. I am using Ubuntu 11.10.
I am using Qt as an IDE and mingw/gcc for the compiler. I am using the latest version of HIDAPI.

I have added a rule to udev to give me read and write permission to HIDRAW, so now I can see when the device is plugged in by searching for the correct VID and PID.

Once I know the device is attached I use hid_open(), then use a timer to read from the device at discreet intervals. When ever I get -1 for the amount read, I know the device is unplugged.

This works well on windows, however when I try this in linux, I can see the device and get plugged in, but the I always get 0 characters read from device. Even when it is disconnected.

I read from the device with the 2 following lines of code:

memset(Readbuf, 0, BUF_SIZE);
AmountRead = hid_read(handle, Readbuf, BUF_SIZE);

Is this a known issue, or is this something small that I am missing?

Thank you!

The function get_string_property() calls CFStringGetBytes() with 7th parameter 'maxBufLen' set to 'len' which is the number of characters of the 'buf'.
But according to MAC OS specification :

maxBufLen
The size of buffer and the maximum number of bytes that can be written to it.

see :
https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFStringRef/Reference/reference.html

So maxBufLen should be set to len * sizeof(wchar_t) to indicate properly the real size in bytes of the buffer.

get_string_property() is used by get_serial_number(), get_manufacturer_string() and get_product_string() with a len of 256 (wchar_t) characters.
I suppose that CFStringGetBytes() will truncate or even fail if it cannot fit the buffer, which could happen if there are more than 64 characters to convert (which in that case would require more than 64 * 4 bytes of buffer size for UTF-32 conversion).

Additionally specification says the 8th parameter 'usedBufLen' may be NULL "if you are not interested in this information". I suggest removing the local variable 'used_buf_len' and passing NULL instead.

Hello Allan

I have observed an odd problem on one particular Windows machine where open_device() succeed while enumerating (open_device(..., TRUE)), but fails when opening the the device for access (open_device(..., FALSE) via hid_open_path()).

1. This fails when enumerate is FALSE:
   DWORD share_mode = (enumerate)?
   FILE_SHARE_READ|FILE_SHARE_WRITE:
   FILE_SHARE_READ;

getLastError() yeilds ERROR_SHARING_VIOLATION.

2. This works when enumerate is FALSE:
   DWORD share_mode = (enumerate)?
   FILE_SHARE_READ|FILE_SHARE_WRITE:
   FILE_SHARE_READ|FILE_SHARE_WRITE;

This happens on a Windows 7 Home Premium 64 bit. I have not seen this problem on any other machines running Windows 7 and XP.
All other USB devices work as expected, and when requesting FILE_SHARE_READ|FILE_SHARE_WRITE, my USB device works as expected.

I am mystified as to why I must open a device with more permissions than required, but this is the case.

I can see there is some discussion about access permissions here:
#23
but I am unsure what your conclusion is.

Shall I create a pull request for this change?

Regards
-Nikolaj Løbner Sheller

More of a question actually, for which I could not find the answer in the documentation. Is it safe to do hid_read and hid_write in two different threads?

I have an application that does blocking hid_read calls on one thread to read some status information from the device, and hid_write calls on the other thread to control the device.

It's Windows by the way.

This is similar to Issue #23.

#23

However, I am trying to open a connection with the device after detection of USB connect event.

I directly open a connection without enumeration [as devices are enumerated before opening a connection on hid_open()]. I am an administrator and am able to open a connection for the first time. This problem occurs only when the device is disconnected and is connected again, and i try to open the connection with the device after detecting the (re-)connection event.

Am trying to do this in Windows (Win 7), but eventually will have to do that for other OSes too. Any idea what is happening?

This is related to now closed issue #66. I was able to produce a short program that on occasion makes the PC freeze for 20 sec.
This was tested on 2 different PCs with windows x64 installed. I use Visual C++ 2010 express to compile.

When running keep on connecting and disconnecting the USB device. Usually after about 10 or 20 tries, the PC freezes.
As can be seen, my testcase is very simple. Only using enumerate, open and close in a single thread.

I tried this with 2 different devices, one self-made gadget and a off-the-shelf USB gamepad. Both show the same issue.

I'd appreciate comments as this issue drives my crazy.

// test3.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <stdint.h>
#include <Windows.h>
#include <iostream>
#include <iomanip>
#include <fstream>
using namespace std;

#include "..\splice2\hidapi-0c462aa\hidapi\hidapi.h"
#ifdef _MSC_VER
    #pragma warning(disable:4996)
#endif
#pragma comment (lib, "Setupapi.lib")

int _tmain(int argc, _TCHAR* argv[])
{
    struct hid_device_info  *hid;
    int              is_open = 0;
    int             counter = 0;
    hid_device          *handle;

    while (1) {
// get fresh linked list of all devices attached matching vid/pid
    hid = hid_enumerate(0x10c4, 0x8643);

// walk the list of currently attached devices
    if (hid) {
        if (is_open == 0) {
        if (handle = hid_open_path(hid->path)) {
            is_open = 1;
            cout << "device open\n";
        }
        }
    } else {
        if (is_open == 1) {
        hid_close(handle);
        is_open = 0;
        cout << "device unplugged\n";
        }
    }
// free linked list
    hid_free_enumeration(hid);
// show some activity
    cout << counter << "\n";
    counter++;

    Sleep(100);
    }


    return 0;
}

Hello,

I call devs = hid_enumerate(0x0, 0x0); at the beginning of the application and it works fine.

however, if I recall devs = hid_enumerate(0x0, 0x0); later in the program,
it does not show the new devices that has been plugged since then.
(it shows exactly the same list as at the beginning of the application).

this problem happens in mac, but not in windows.

Any idea?

Many thanks,
David

Hello,
I am trying to use hidtest in VC++ 2010 express to communicate with an Atmel dev kit - set up as a USB HID device.

The first call to CreateFile fails (from hid_open from hid_enumerate).

Any suggestions as to what I am missing ?

Thanks
Brian

On branch master, if you call hid_close() on a opened device and after that you physically remove the device, hid_device_removal_callback() is still called causing a memory corruption.

In hid_close() calling :

IOHIDManagerRegisterDeviceRemovalCallback(hid_mgr, NULL, dev)

has no effect since device removal callback is NOT registered against the hid manager.

It is registered in hid_open_path() using IOHIDDeviceRegisterRemovalCallback(). So to properly unregister it, we should call in hid_close() :

IOHIDDeviceRegisterRemovalCallback(dev->device_handle, NULL, dev).

My device works well on a USB2.0 port, but fails on 1.1. I believe that this is because 1.1 can only support up to 64 bytes per transaction, and I am attempting to send signficantly more than this.

I'd like to be able to report to the user that we do not support USB1.1 ports. How can I know whether or not I am on one?

(I'm on a Ubuntu 12.04, 64bit)
I tried compiling the way the readme describes and I get the following error:

$ cd linux/
$ make
cc -Wall -g -fpic -c -o hid.o hid.c
hid.c:45:20: fatal error: hidapi.h: No such file or directory
compilation terminated.
make: *** [hid.o] Error 1

I am trying to use the latest hidapi with the Qt-based HID Bootloader software written by Microchip (which is included in the latest Microchip Application Library and located at Microchip Solutions v2011-07-14/USB/Device - Bootloaders/HID/Software - Cross Platform/)

This app runs hid_enumerate on a timer (once a second by default), always searching for its given VID and PID. If the device is found, it opens it with hid_open() and starts communicating. However, the next time hid_enumerate() runs, it is unable to open the device (because of the '0' passed for the share value), thus unable to read the VID/PID, and returns a linked list without the device included.
To the app, this means that the device is now disconnected, and it calls hid_close(). Then the device is detected when hid_enumerate() runs, and the loop starts over.

I was able to fix this problem by removing the first (0 share value) CreateFileA call in open_device (so CreateFileA is always called with FILE_SHARE_READ|FILE_SHARE_WRITE).
Is there any better way to solve this problem though? Another way to detect device disconnection maybe, or (even better) a more lightweight or callback-based way to get device connection/disconnection events?

Hi, If somebody is experiencing same: I am struggling memory leak on Mac OS X 10.7. I have application that does use hidapi, software is developed on 10.5 and is running very well (withoyt crashes and leaks). on 10.7 I experience constant memory leak and valgrind point up to IOKIT. If somebody does have ideas or solutions for this it would help a lot.

I'm on Linux (3.4.4, libusb-1.0) and have tried both the hidraw and libusb versions.

Device opening with hid_open or hid_open_path always fails, including in the tests (hidtest-libusb, hidtest-hidraw and testgui). I've tried running as both my normal user and root.

I can open my device using another library (PyUSB).

Sample output:

Device Found
type: 21a1 0001
path: 0002:006e:00
serial_number: (null)
Manufacturer: (null)
Product: (null)
Release: 3
Interface: 0

Device Found
type: 21a1 0001
path: 0002:006e:01
serial_number: (null)
Manufacturer: (null)
Product: (null)
Release: 3
Interface: 1

unable to open device

Any help would be greatly appreciated. Thanks!

I'm using hidapi in non-blocking mode, and I noticed my reads were failing due to EINPROGRESS. I think there is a missing case in hid_read_timeout() for that. Once I added handling for this error, everything worked well:

    bytes_read = read(dev->device_handle, data, length);
    if (bytes_read < 0 && (errno == EAGAIN || errno == EINPROGRESS))
            bytes_read = 0;

I'm going to issue a pull request for this change.

I'm new to this world and running into some problems. I'm getting this when i run HIDtest:

Device Found
type: 14fa 0001
path: USB_14fa_0001_0x7f8899501460
serial_number:
Manufacturer: Wild Divine
Product: ST7 RS232 USB BIOFBK
Release: 4217
Interface: -1

unable to open device
logout

and test gui is throwing this at me in rapid succession:
Received 8 bytes:
07 30 30 20 30 33 44 36

My whole struggle here is to get this data into MAX/MSP. Currently my HID detector object in Max is reporting all of this information as well - but it can't make any sense of it.
I added HIDAPI based off this feed: https://github.com/qdot/liblightstone/tree/hidapi
which provides a Max patch - but the patch isnt reporting a connection to the Lightstone.

If i'm way out of the park here, no worries, don't waste your time on me.

thanks

WINDOWS
I'm having problems when running hid_enumerate and hid_read/hid_write in different threads. I'm not sure if hidapi is supposed to be thread safe and the problem is in fact in my firmware device code, or if this is hidapi that's the problem.

Sooner or later my host code doesn't work anymore as the hid_read/hid_write fail and this only happens while a 2nd thread using hid_enumerate is active.

HI,
I am planning to use this library to communicated(open,read,write,close) with two or more devices at the same time.Is this possible under windows?

I noticed that I wasn't correctly receiving the wchar_t* strings in hid_device_info on the Mac. I believe I'm marshalling them into C# incorrectly, but I wanted to check with you before I go too far down that road.

It looks like these strings are UTF16 on Windows and UTF32 on Macintosh. Is this expected behavior?

I downloaded master and I am using Windows 8 currently. When I try to open a device the handle always returns 0xffff... from CreateFileA. I tried to download 0.7.0 and it seemed to open it properly. So I compared the code and tryed to modify open_device to be the same and that had no effect. It still failed on the newest build.

Any ideas?

When I disconnect two devices at a time and if there is no more devices connected, the function hid_enumerate doesn't return a pointer which is set at NULL.

Minor issue. If hid_open fails the error is obtained, but the device is free'd and null returned so the caller has no way to access the error via hid_error.

For some reason when I plug 2 devices in at the same time to the HUB on my monitor the call to GetSerialNumberString for the second device fails (GetLastError returns 2). The wcscmp in hid_open then crashes because the dev serial_number is null.

Putting a Sleep(100) and retrying the GetSerialNumberString obtains the serial number.

I have a problem on Windows7 where GetOverlappedResult blocks forever. I don't think the problem is HIDAPI, but I'm trying to understand how to use HIDAPI correctly to avoid this. For instance I was surprised that if I pull out the device during a write, but then call write again the WriteFile returns ERROR_IO_PENDING and so the GetOverlappedResult blocks.

Now obviously for the simple case I can not call the write after I get an error, but I believe there is a case where the device is removed just before the write and so I don't get an error and it simply blocks.

How exactly should I be handling this?

I am calling hid_read blocking in one thread, and call hid_close in another thread. I'd expect that hid_read would return, but it continues to block indefinitely.

It looks like it might be stuck in GetOverlappedResult, but I thought CancelIO would have handled that.

Are you able to reproduce this?

I have a Native Instruments Kontrol S4 connected to my Windows 7 64-bit system (http://www.native-instruments.com/#/products/dj/traktor-kontrol-s4/).

When I run the HIDAPI Test Tool I only see:

Microsoft Natural Keyboard Elite
Logitech USB Gaming Mouse
Logitech USB Gaming Mouse
Logitech USB Gaming Mouse

I tried re-scanning but to no avail. My Device Manager shows:

...
Human Interface Devices
  HID-compliant device
  HID-compliant device
  Microsoft USB Natural Keyboard
  USB Input Device
  USB Input Device
...
Universal Serial Bus controllers
  ...
  Traktor Kontrol S4
  ...
...

I'm 100% certain that the Kontrol S4 uses HID, see this review: http://www.djtechtools.com/2010/08/16/traktor-s4-dj-system/

Also it has been mentioned in some official announcements that some functions of both the Kontrol S4 and the Kontrol F1 are only accessible through the HID interface.

Hello,

I've used hidapi in Mac and it works great!
However, when I try it in WinXP, the dev.write operation fails with a "The parameter is incorrect" message.
(it enumerates the devices correctly, it opens my device correctly, but dev.write fails)

I've compiled it with the free version of visualstudio:
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express

and also with MinGW.

Any idea?
What can I look at?

Regards,
David

is it possible to receive a notification when a new device has been plugged or unplugged?

I don't see this option in the API:
http://www.signal11.us/oss/hidapi/hidapi/doxygen/html/group__API.html#ga135931e04d48078a9fb7aebf663676f9

Many thanks,
David

Hi Alan,

My app is now released, and I've gotten two crash reports from users that show the app segfaulting in IOHIDManagerCopyDevices() (called from hid_enumerate()). The reports are from different generation MacBook Pros, both x86_64, one running 10.6.8 and the other 10.7.2. I'm using a slightly older HIDAPI version (before the changes to use threads), but I don't think hid_init() or hid_enumerate() had any changes there.

It appear that when hid_enumerate() calls hid_init(), the initialization fails somewhere, hid_mgr is left as NULL and then is passed into IOHIDManagerCopyDevices() causing the segfault.

The obvious fix is that the return value of hid_init() should always be checked before hid_mgr is used.
But why is hid_init/IOHIDManagerOpen() failing?

This seems like a very rare crash, it hasn't happened in any of my testing, and I haven't been able to reproduce it yet. The only other mention I found online was a crash report from another Qt/HIDAPI app, which is also calling hid_enumerate() in a main window/app constructor. Maybe IOHIDManagerOpen() is failing because the run loop hasn't run yet?

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.apple.framework.IOKit     0x00007fff85391024
IOHIDManagerCopyDevices + 4
1   ...electronics.FirmwareUpdater 0x0000000100017cfb hid_enumerate + 63
2   ...electronics.FirmwareUpdater 0x000000010000eed9
Comm::startUSBPollingTimer() + 25
3   ...electronics.FirmwareUpdater 0x00000001000038f8
MainWindow::MainWindow(QWidget*) + 680
4   ...electronics.FirmwareUpdater 0x000000010000da17 main + 274
5   ...electronics.FirmwareUpdater 0x000000010000362c start + 52

Hi,

I've got serious troubles to make hid_read() running in a separate thread. Basically, what I do:

• set up a new thread
• call hid_open() there
• while( true ) { hid_read(); + writing to a queue }

and in another thread I read this queue (thread safe). But, for some reason, the first hid_read() blocks not only its thread but also the 'source' thread, too! I guess it has something to do with the fact that hidapi uses threads, too. I tried to use the non-blocking flag too but then hid_read() returns null everytime. If I do this sequentially, in one thread, everything works.

My question is then: how am I supposed to poll for random events? Like key presses on a device? I've really tried everything I could think of.