linux dies after sending a control transfer.

[ulao]

OK, just wanted to be sure you understood that the host assigns one driver to the HID interface, typically the HID driver, and you can't use two drivers/APIs to access the same device at the same time.

Well that is not true depending on how you read it. In windows I can use HIDAPI to talk to a device that is also in use by the OS. On top of that I can use HIDAPI to poll interrupts transfers + control transfers + let a another DirectX application game poll for data all at the same time. So if you mean, that you can not have too application usb HIDAPI at the sometime I'd agree. Although one can use HIDAPI and another (HIDUSB?). I can provide proof.



I think I'm learning that in the case of linux its all done with one driver. Sort of a poor design but still not %100 sure I understand this.

Linux has a gamepad 'object' that can use the linux event system. Although to use it with any software you need to use sdl. sdl apparently uses linusb. So using a usb device in any way on linux at all, you are going to need to use libusb and there are no other ways. So you can never use two methods to talk to a device like you can in windows.

Second, I though a USB device was designed to have multiple end points. So you should be able to communicate with ENP0 with libusb and ENP1 with libusb in another instance, no? Or is the limitation the fact only one application can use libusb at a time.

further I was pretty sure you can also talk to a USB device via control transfers at the same time its polling bulk or interrupt date? This comment in the libusb interface I have suggest just that.

/* Continue anyway, even if we could not claim the interface. Control transfers
 * should still work.
 */

[ulao]

Here is a screen shot of 3 application using the same driver.

1 Native windows, polling the game  controller interrupt transfer.
2 My own app using Control transfers and interrupt transfers via HIDAPI.
3 Dolphin using Direct X using control transfers to set up the PID force feedback engine and polling interrupt transfers for inputs.

When you press buttons or move the stick, all of these windows show movement.

[Jan Axelson]

The host uses information retrieved during enumeration to assign a low-level driver to a device or interface. Unless an application has exclusive access, multiple applications can access the same device. But they all need to communicate with the driver assigned to the device, for example HID or libusb. Yes, a HID can perform periodic interrupt transfers and HID-class control transfers. 

[ulao]

Sure, and this is what I figured. My entire point is that Linux seems rather "picky" in this case.

In windows I can run 2 DirectX application at the same time. Do that in Linux (two LibUSB apps) and you fail.  Also LibUSB should have some type of a read only mode or something.  I mean If you want to use a device with something like jstest, there really is no need to take full control of it.  Its just a test app, why take exclusive control.

Though ok, lets settle to agree that you can only run one instance of LibUSB. The what else can I use to communicate with the driver simultaneously? See with linux there is only one option, LibUSB.


Linux should be thinking more open about its devices and one app (maybe SDL) should expose an API. So that many application can use it, or maybe libusb should do this. As it is, its useless accept for 1 case. Expose the device, don't own it.... And I mean that from the OS level. Seems Linux has no way to use a USB  gamepad other then libUSB . So it only seems reasonable that libUSB should allow some type of API once it takes exclusive writes of a device.


I just learned that libusb is not the only option.
 yigityuce / HidApi
seem to show a way to access a device without libusb. I may give that a try.

[bpaddock]

yigityuce / HidApi

That is a five year old fork of HIDAPI.

The libusb people took over HIDAPI and
is keeping it up to date.  Updated three days ago.

They have fixed long standing bugs and addressed issues that
the original author refused to fix, that needed fixed.

Find it here:

https://github.com/libusb/hidapi


While multiple 'things' may be able to access a device at the same time, it is not always a good idea.
I run a HIDAPI based program and my colleague developed for the same device in Delphi.
Running my HIDAPI based program causes his Delphi program to crash if I forget to shut it down.
The device itself doesn't care.