-
Notifications
You must be signed in to change notification settings - Fork 72
Troubleshooting
The following are known issues and their solutions or workarounds.
You may find some of the following commands useful during your debugging process:
To see a complete list of USB devices attached to your system on Linux: Linux:
lsusb -v
OS X:
ioreg -p IOUSB
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.
If you're seeing this then you should update hid4java
to the latest version.
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
KERNEL=="hidraw*", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="abcd", MODE="0666", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl"
(The TAG entries are there for compatibility with systemd)
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!
This appears to be an issue with fwupd
on Ubuntu 16.0. As the it is fixed in Ubuntu 18.0+ it is probably worth upgrading to that version.
However, if you cannot upgrade then a workaround is available in issue #97.
Thanks to @Lavindur for his investigation.
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 = true
Setting this parameter will enable libusb
libraries (which have slightly different behaviour) when executing on a Linux platform.