[libhid-discuss] Linux: the device is opened exclusively

[Lux Vampere]

Hi,

I have a problem with a driver that I am porting from Mac OS X to Linux. The idea of the driver is that it should be able to send some reports to a device, and then let the device answer by broadcasting its (key) events to the system.

On Mac OS X, a force open is done, then a set report. The device receives the data and then answers by broadcasting its key events, which is what is wanted. The device is not opened exclusively.

On Linux, the same code does not work: the device receives the data but it does not answer (I have sniffed and the communication is correct). It only answers if an interrupt read is done, and in this case the data is not broadcasted, it is only available in the driver and not outside. It is as if the device was opened exclusively (seized).

Is there a way to tell the library not to seize a device? Or is there a way to solve my problem?

Many thanks,

Kind regards
Lux

[Charles Lepple]

[Please subscribe to the list. Thanks.]

Post by Lux Vampere
Hi,
I have a problem with a driver that I am porting from Mac OS X to
Linux. The idea of the driver is that it should be able to send
some reports to a device, and then let the device answer by
broadcasting its (key) events to the system.

So the device acts like a keyboard?

Post by Lux Vampere
On Mac OS X, a force open is done, then a set report. The device
receives the data and then answers by broadcasting its key events,
which is what is wanted. The device is not opened exclusively.

This may be version-specific - I have seen cases where the system
will not let you send to a device that you haven't opened exclusively.

Post by Lux Vampere
On Linux, the same code does not work: the device receives the data
but it does not answer (I have sniffed and the communication is
correct). It only answers if an interrupt read is done, and in this
case the data is not broadcasted, it is only available in the
driver and not outside. It is as if the device was opened
exclusively (seized).
Is there a way to tell the library not to seize a device? Or is
there a way to solve my problem?

You have the source code - it is certainly possible.

Whether or not it produces the results you are looking for is up in
the air. It probably depends on what the Linux kernel lets you do if
you have not claimed the device.

[Lux Vampere]

Hello,

Thanks for your answer. My device acts like a keyboard.

Post by Charles Lepple
You have the source code - it is certainly possible.
Whether or not it produces the results you are looking for
is up in the air. It probably depends on what the Linux
kernel lets you do if you have not claimed the device.

If I follow this path, should I write my own hid_force_open function, that does not claim the device?

Another way to solve my problem would be to catch the data in the driver, and then broadcast it to the system programmatically. Does this make sense and could there be side effects (like the keys being fired several times in some situations, where the device is not opened exclusively for some reason)? Can this be easily achieved on Linux? Typically, I'll have a key event in the form of an 8 bytes buffer, coming from the USB wire, that I'd like to fire as a system wide key event...

Thanks,

Kind regards
Lux

[Charles Lepple]

Post by Lux Vampere
Another way to solve my problem would be to catch the data in the
driver, and then broadcast it to the system programmatically. Does
this make sense and could there be side effects (like the keys
being fired several times in some situations, where the device is
not opened exclusively for some reason)? Can this be easily
achieved on Linux? Typically, I'll have a key event in the form of
an 8 bytes buffer, coming from the USB wire, that I'd like to fire
as a system wide key event...

This is all pure speculation, since I haven't done much with
generating events, but if you open the device exclusively, then you
shouldn't have to worry about multiple copies of a given event.

(Also, I usually refer to opening the *device* exclusively, where
libhid is really opening an *interface* exclusively. If your device
only has one interface, this may be a moot point.)

I don't know if the Linux input subsystem supports injecting events
from user space, though. Maybe there are some keyboard macro programs
out there that would have examples on how to do that? If you limit
your scope to X11 applications, I am pretty sure that it is possible
to generate fake X key events.

[Lux Vampere]

I just made a quick test: I commented the line with hid_os_force_claim in hid_opening.c, in the hid_force_open function. Unfortunately, it does not seem to have an impact in the behaviour of my driver: the device is still opened exclusively.

This was done on a SUSE Linux Enterprise Server 10 box, Linux Kernel 2.6.16.21.