-
Notifications
You must be signed in to change notification settings - Fork 72
Troubleshooting
The following are known issues and their solutions or workarounds.
On startup hid4java will search the classpath looking for a library that matches the machine OS and architecture (e.g. Windows running on AMD64). It uses the JNA naming conventions to do this and will report the expected path if it fails. You can add your own entry under src/main/resources and it should get picked up. Ideally you should raise an issue on the hid4java repo so that the proper library can be put into the project so that others can avoid this problem.
Check that the usage page is not 0x06 which is reserved for keyboards and mice.
Windows opens these devices for its exclusive use and thus hid4java cannot establish its own connection to them.
You will most likely need to use the lower level usb4java library for this.
This shouldn't occur unless you've been changing the code.
You have probably got the getFieldOrder list wrong. Use the field list from Class.getFields() to get a suitable order.
Another cause is if a Structure has not been initialised and is being deferenced, perhaps in a toString() method.
There is also the possibility that using the built-in HidDeviceManager code can cause problems in some applications.
You have probably terminated the JVM using a kill -9 rather than a clean shutdown. This will have left the HidApi process lock on the DLL still in force and Windows will continuously check to see if it can share it with a new instance.
Just detach and re-attach the device to clear it.
Another explanation is that another process has grabbed the USB HID and has not released it. Check your task manager.
This was a device enumeration bug in early versions of hid4java. Use version 0.3.1 or higher.
There is a special case on Windows for report ID 0x00 which can cause a misalignment during a hidapi write().
To compensate for this, hid4java will detect when it is running on Windows with a report ID of 0x00 and simply copy
the data unmodified to the write buffer. In all other cases it will prepend the report ID to the data before submitting
it to hidapi.
If you're seeing this then it may be that your code is attempting to second guess hid4java.
Different flavours of Linux require different settings:
Out of the box Ubuntu classifies HID devices as belonging to root. You can override this rule by creating your own under /etc/udev/rules.d:
sudo gedit /etc/udev/rules.d/99-myhid.rules
Make the content of this file as below (using your own discovered hex values for idProduct and idVendor in lowercase):
# My HID device
ATTRS{idProduct}=="0001", ATTRS{idVendor}=="abcd", MODE="0660", GROUP="plugdev"
Save and exit from root, then unplug and replug your device. The rules should take effect immediately. If they're still not running it may that you're not a member of the plugdev group. You can fix this as follows (assuming that plugdev is not present on your system):
sudo addgroup plugdev
sudo addgroup yourusername plugdev
Edit the USB udev rules /etc/udev/rules.d as follows:
MODE="0666", GROUP="dialout"
Running on ARM machines you may encounter problems due to a missing library. This is just a naming issue for the udev library and can be resolved using the following command (or equivalent for your system):
sudo ln -sf /lib/arm-linux-gnueabihf/libudev.so.1 /lib/arm-linux-gnueabihf/libudev.so.0
Thanks to @MaxRoma for that one!
The hidapi support library is available in two variants: libusb and hidraw. In general the hidraw variant is the
most flexible and it allows Bluetooth interfaces to be addressed. However, you can force the use of the older libusb as follows:
HidApi.useLibUsbVariant = trueSetting this parameter will enable libusb libraries (which have slightly different behaviour) when executing on a Linux platform.