[jitsi-users] Issues developing plugin for generic USB-HID support


#1

Hi!

I was trying to get a Jabra headset to work with jitsi and found the following threads indicating, that direct Jabra support was not going to be introduced:

http://lists.jitsi.org/pipermail/dev/2013-March/000723.html
http://lists.jitsi.org/pipermail/users/2014-June/007424.html

Now I experimented with the framework hid4java (MIT licensed, https://github.com/gary-rowe/hid4java), which I was able to use to catch button presses on a "Jabra UC Voice 150 Mono" on Linux, WinXP and Win7.

With that framework I was able to capture the button press events of the mentioned device. I'm currently trying to build a plugin/bundle for jitsi.

For simplicity, the plugin currently just waits for a specific HID event and translates it into an AWT key press using java.Robot.
(This can then be used with the global key shortcuts)

Ideally it should eventually directly trigger the answer action directly. Also for now I needs to be configured to work with just one HID device. In fact, a list of supported HID devices could be put in the resources and any attached device could be identified automatically, but that's for the final version.

I added the external libs to the ant build process of the plugin as follows:

         <target name="bundle-plugin-usbhidmapper">
             <jar compress="false" destfile="${bundles.dest}/usbhidmapper.jar"
manifest="${src}/net/java/sip/communicator/plugin/usbhidmapper/usbhidmapper.manifest.mf">
                 <zipfileset dir="${dest}/net/java/sip/communicator/plugin/usbhidmapper"
prefix="net/java/sip/communicator/plugin/usbhidmapper"/>
                 <zipfileset src="${lib.noinst}/hid4java-0.3.1.jar"/>
                 <zipfileset src="${lib.noinst}/jna-4.1.0.jar"/>
             </jar>
         </target>

This results in a 2.5 MB JAR, containing the external java libs, native libs and bundle code. I can add this jar as a plugin to a stable version install.

I'm currently having some issues/questions though:

1.) Is the MIT license "OK" for you, so the plugin could possibly be integrated with Jitsi?
2.) On Linux, the bundle does not get any stop events when shutting down the application. On WinXP it does. (This is an issue, because I need to stop the thread listening on the USB device). It works when I manually deactivate the plugin before quitting jitsi.
3.) On Windows, the external lib does not detect USB devices, when running with jitsi. The plugin and external lib get loaded without errors though. If I use the same created plugin JAR with a simple test program by adding it to the classpath, it works. It might be due to some strange OSGI/felix problem, but I have no clue on where to start looking.

On WinXP I'm using Jitsi 2.8.5426 with java 1.7.0_71 (oracle)
On Linux I'm using Jitsi 2.8.5426 with java 1.8.0_40 x64 (oracle)

Regards,

Peter

PS to the admins:
I wrote a similar mail recently from peter_at_psit.at, which never got sent to the list, but I do receive list mails to that address. Could you check your server, why I can't write to the list from the mentioned address?


#2

Hi!

I was trying to get a Jabra headset to work with jitsi and found the
following threads indicating, that direct Jabra support was not going to
be introduced:

http://lists.jitsi.org/pipermail/dev/2013-March/000723.html
http://lists.jitsi.org/pipermail/users/2014-June/007424.html

Now I experimented with the framework hid4java (MIT licensed,
https://github.com/gary-rowe/hid4java), which I was able to use to catch
button presses on a "Jabra UC Voice 150 Mono" on Linux, WinXP and Win7.

With that framework I was able to capture the button press events of the
mentioned device. I'm currently trying to build a plugin/bundle for jitsi.

For simplicity, the plugin currently just waits for a specific HID event
and translates it into an AWT key press using java.Robot.
(This can then be used with the global key shortcuts)

Interesting idea.

Ideally it should eventually directly trigger the answer action
directly. Also for now I needs to be configured to work with just one
HID device. In fact, a list of supported HID devices could be put in the
resources and any attached device could be identified automatically, but
that's for the final version.

I guess these would all be minor issues if everything else would be solved...

I added the external libs to the ant build process of the plugin as follows:

         <target name="bundle-plugin-usbhidmapper">
             <jar compress="false"
destfile="${bundles.dest}/usbhidmapper.jar"

manifest="${src}/net/java/sip/communicator/plugin/usbhidmapper/usbhidmapp
er.m anifest.mf">
                 <zipfileset
dir="${dest}/net/java/sip/communicator/plugin/usbhidmapper"

prefix="net/java/sip/communicator/plugin/usbhidmapper"/>
                 <zipfileset src="${lib.noinst}/hid4java-0.3.1.jar"/>
                 <zipfileset src="${lib.noinst}/jna-4.1.0.jar"/>
             </jar>
         </target>
This results in a 2.5 MB JAR, containing the external java libs, native
libs and bundle code. I can add this jar as a plugin to a stable version
install.

Ahm, this might work for testing purposes, but if we want to integrate that, these should be separate three jars:
- usbhidmapper (your work)
- jna (we already have that in Jitsi, might need to be updated though)
- hid4java (run "mvn package" to get an OSGi enabled jar)

I'm currently having some issues/questions though:

1.) Is the MIT license "OK" for you, so the plugin could possibly be
integrated with Jitsi?

Yes, but you'd need to sign a contributor agreement [1] as well.

2.) On Linux, the bundle does not get any stop events when shutting down
the application. On WinXP it does. (This is an issue, because I need to
stop the thread listening on the USB device). It works when I manually
deactivate the plugin before quitting jitsi.

There's a timeout in the shutdown until the process gets killed. You might run into that on Linux. What's the problem when you don't manually stop that thread? After all, the application is killed. Would that leaves some native pointers/handles to the device open?

3.) On Windows, the external lib does not detect USB devices, when
running with jitsi. The plugin and external lib get loaded without
errors though. If I use the same created plugin JAR with a simple test
program by adding it to the classpath, it works. It might be due to some
strange OSGI/felix problem, but I have no clue on where to start looking.

What do you mean by "gets loaded"? Can you obtain at least some information from hid4java? There could also be a problem from the two jna libraries, although that is not very likely due to the OSGi isolation.

On WinXP I'm using Jitsi 2.8.5426 with java 1.7.0_71 (oracle)
On Linux I'm using Jitsi 2.8.5426 with java 1.8.0_40 x64 (oracle)

Is your source somewhere public to take a look at?

Regards,
Peter

Ingo

[1] http://bluejimp.com/bca.pdf


#3

For simplicity, the plugin currently just waits for a specific HID event
and translates it into an AWT key press using java.Robot.
(This can then be used with the global key shortcuts)

Interesting idea.

Thanks. This is far from optimal, but enough for a proof of concept.

Ideally it should eventually directly trigger the answer action
directly. Also for now I needs to be configured to work with just one
HID device. In fact, a list of supported HID devices could be put in the
resources and any attached device could be identified automatically, but
that's for the final version.

I guess these would all be minor issues if everything else would be solved...

A little help would be appreciated, how to trigger a "pick-up"/"hang-up" action.
I already found some other plugin that uses a seperate XML config file - I would use that trick as well for build in supported devices. Possibly adding an additional user generated file that could be submitted to the devs for integration, when another working device has been found by some user. but anyway...

I added the external libs to the ant build process of the plugin as follows:

          <target name="bundle-plugin-usbhidmapper">
              <jar compress="false"
destfile="${bundles.dest}/usbhidmapper.jar"

manifest="${src}/net/java/sip/communicator/plugin/usbhidmapper/usbhidmapp
er.m anifest.mf">
                  <zipfileset
dir="${dest}/net/java/sip/communicator/plugin/usbhidmapper"

prefix="net/java/sip/communicator/plugin/usbhidmapper"/>
                  <zipfileset src="${lib.noinst}/hid4java-0.3.1.jar"/>
                  <zipfileset src="${lib.noinst}/jna-4.1.0.jar"/>
              </jar>
          </target>
This results in a 2.5 MB JAR, containing the external java libs, native
libs and bundle code. I can add this jar as a plugin to a stable version
install.

Ahm, this might work for testing purposes, but if we want to integrate that, these should be separate three jars:
- usbhidmapper (your work)
- jna (we already have that in Jitsi, might need to be updated though)
- hid4java (run "mvn package" to get an OSGi enabled jar)

How would I configure that then?
1. where to put the external jars
2. how to reference them
3. I used some mvn assembly configuration to get the hid4java-0.3.1.jar

There are 2 lib jars in the jitsi source tree. But the bundle ant target creates a single jar with dependencies (as I would expect for a plugin).

I'm currently having some issues/questions though:

1.) Is the MIT license "OK" for you, so the plugin could possibly be
integrated with Jitsi?

Yes, but you'd need to sign a contributor agreement [1] as well.

We can do that, when it's stable enough.

2.) On Linux, the bundle does not get any stop events when shutting down
the application. On WinXP it does. (This is an issue, because I need to
stop the thread listening on the USB device). It works when I manually
deactivate the plugin before quitting jitsi.

There's a timeout in the shutdown until the process gets killed. You might run into that on Linux. What's the problem when you don't manually stop that thread? After all, the application is killed. Would that leaves some native pointers/handles to the device open?

It looks like some processes of the hid4java lib are blocking the shutdown. The lib echos the stderr that it's unloading and the listening thread keeps running. It won't interrupt. I think that the listening thread blocks the shutdown process. I need to "kill -9" the jitsi process (a simple kill is not sufficient).
Can I somehow intercept the shutdown request to manually clean up "my" things, i case the bundles stop() method is not called? Or is there any service i can query for the applications status? Then the listening thread itself could check whether it should terminate, without beeing interrupted.

3.) On Windows, the external lib does not detect USB devices, when
running with jitsi. The plugin and external lib get loaded without
errors though. If I use the same created plugin JAR with a simple test
program by adding it to the classpath, it works. It might be due to some
strange OSGI/felix problem, but I have no clue on where to start looking.

What do you mean by "gets loaded"? Can you obtain at least some information from hid4java? There could also be a problem from the two jna libraries, although that is not very likely due to the OSGi isolation.

The library does not complain about anything missing. It just does not detect any HID devices (I have a Wingman Extreme attached as well to test device detection). Using the same lib (i.e. the plugin jar including the external libs) with a simple test program works.

On WinXP I'm using Jitsi 2.8.5426 with java 1.7.0_71 (oracle)
On Linux I'm using Jitsi 2.8.5426 with java 1.8.0_40 x64 (oracle)

Is your source somewhere public to take a look at?

I'm currently rebasing/merging to your current master branch. I will send you a patch and the test program to demonstrate the issues.

···

On 2015-04-08 15:55, Ingo Bauersachs wrote:

Regards,
Peter

Ingo

[1] http://bluejimp.com/bca.pdf

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users