Running multitouch utilities in Lion

[DanT]

Lion won't run Powerpc apps and the multitouch utilities are a java program that is kickstarted by a PowerPC app wrapper. I pulled the necessary java command into a script file and now it runs fine as a Intel (64-bit) app. The board won't accept .sh files so do the following:

• Grab the source from https://gist.github.com/1096642
• Save the source as mtu_run.sh under /Applications/Fingerworks
• chmod u+x /Applications/Fingerworks/mtu_run.sh
• run the script from /Applications/Fingerworks/

This should make it work in Lion, but I'm still downloading so let me know if it needs more tweaking.

[TorbenGB]

Wow Dan, that's quite a cool way to start out here. Welcome, and thank you!

I'm not on Mac myself but I am sure that other users will be *very* grateful for this tip. It was a big disappointment when the FW utils didn't run on newer OS'es, but you've shown a way forward. It's making me think that when this works on Mac OS which is essentially Unix then there is also hope that it could work on Linux variants with very few changes. Now we just need to find someone with more Linux skills (and time) than me

Cheers,
Torben

[The00Dustin]

Torben, when he says "the board won't accept .sh files" he means he can't upload the file here. A .sh file is like a .bat file, so that may be a built in safety thing, or it may be something you should fix. Regardless, having only read this post, it sounds like he's just loading the same old .jar file into (a potentially newer version of) java from a script. Not only should this be possible in Linux with little to no customization, it could even work on Win 7 with a (potentially slightly customized per install) .bat, .pif, or .lnk file. This seems too good to be true, but I plan to dig a little deeper at some point.

[TorbenGB]

"the board won't accept .sh files" he means he can't upload the file here.

Oh! I thought he was talking about updating his device I would have to check the settings, but it's very likely a security precaution. I recommend uploading the file in a compressed format.

[The00Dustin]

I know nothing about Java other than Windows sucks at it (or Sun sucked at Windows, depending on how you look at it, realistically, I'm sure Microsoft and Sun should share the blame on the fact that the language runs horribly in Windows). However, I was able to get this method working in Windows (XP). It took much longer than it should have if I had any clue what I was doing, but hey!

Anyway, I don't have a Win7 x64 machine with a FW device to test this with, so I'll leave that to someone else if anyone is willing.

Here's what needs done:

1) Get a copy of the FingerWorks folder from a Windows install and place it wherever you wish (in my case it's actually installed in C:\Program Files\Fingerworks, so I'll use that in my example)
2) Create a shortcut to java.exe (default path is %windir%\system32\java.exe, used in my example)
3) Get into the shortcut's properties and, in the "Target:" field, put this:

Code: Select all

%windir%\system32\java.exe -classpath lib\jusb\jusb.jar;lib\FW_defaults.jar;lib\upgredit.jar;lib\jh.jar;lib\utility_help.jar;lib\jdom\xerces.jar;lib\jdom\jdom.jar;lax.jar fingerworks.firmup.UtilityLauncher

*Everything in the code box will technically be on one line, but the space lead to a line break due to the length of the command
4) In the "Start in:" field put this:

Code: Select all

"C:\Program Files\FingerWorks"

*Quotes aren't necessary if no spaces are included in the path to your copy of the FingerWorks install directory
5) [Optional] Change the "Run:" field from "Normal window" to "Minimized" [This is going to be a command prompt running Java, not the multitouch utilities]
6) [Optional] Change the icon to the MultiTouch_Utilities.ico file in your copy of the Fingerworks install directory
7) [Optional] Rename the shortcut to "FingerWorks MultiTouch Utilities Java Launcher"

Note that I didn't set any of the environment variables listed in Dan's post. It might be wise to set them, but then you have to have a batch file or integrate them into your system configuration. They may only be necessary for Lion. Dan, do you care if I copy your source from github into the forum so there is another record of the variables involved?

I tested this in Windows XP using Java 6 Update 21 which returns this when given the -version parameter:

Code: Select all

java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)

I confirmed that the configuration editor would pop up and the diagnostics would run. I did not test upgrading. When FingerWorks existed, they made us run a specific version of java. The version distributed with the FingerWorks drivers returns this when given the -version parameter:

Code: Select all

java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode)

because others "weren't supported." Technically, none are supported now, but running a different version is at your own risk. This was installed, os well, but not in the add/remove programs list, so I doubt it was called. However, I also had this old version installed:
(J2SE Runtime Environment5.0 Update 13)

Code: Select all

java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode)

This did show up in add/remove programs and might have been automatically called somehow, in which case that could de another roadblock, but that's assuming that 1.5 would be more compatible with 1.4 than 1.6 for some reason.

Assuming an old version wasn't called, if you have both installed and want to use the original one, or some other older one more tweaking would be necessary, but I'm not sure how much. For instance, there is a -version:<value> parameter that might call up the old version if it is actually installed. That might allow you to leave the shortcut mostly the same and just call the version you want. Otherwise, it would be necessary to use the start in path of the old version of java and modify the "Target:" field to include absolute paths to each jar file, which may also involve using quotes on the -classpath option.

All of that having been said, has anyone tried XP mode on Win7 for this? I don't know whether or not that limits what kind of devices XP mode applications have access to when they are run in the 6.1 environment (instead of in the virtual machine where only certain devices can be passed through).

Finally, for the record, I don't know if the JAR files are any different for the various operating systems. It might be possible to copy the Windows files into Linux and do this just as easily. If not, it should still be possible to do this just as easily in Linux using a copy of whatever comes from the linux install package. I imagine Linux would use : instead of ; much like Unix (mac), though. I also imagine it would be easy to set the environment variables right on the command line too, meaning a shortcut or a shell-script would be a viable option for launching this stuff.

This ALL assumes Java can still access devices the same way, if an OS upgrade prevents that, bypassing the compiled executables and launching directly from Java won't be helpful.

EDIT: I had version info wrong above and have updated it (good news is I can now uninstall an old version of java I thought I left just for FingerWorks and my computer will be a bit more secure). Also, Dan has posted again to note a patch necessary to jusb in Unix(mac), something similar is likely necessary in Linux and Windows given that previous workarounds have required specific kernel versions or virtualization scenarios. Finally, the aforementioned environment variables are no longer listed as necessary in Dan's environment.

[TorbenGB]

Technically, your answer is no longer on-topic as it's not about Lion but Windows. I'd say we need a Windows thread with your content, plus a Linux thread with something in it too. But I'm too lazy to do that right now.

[The00Dustin]

Technically, your answer is no longer on-topic as it's not about Lion but Windows. I'd say we need a Windows thread with your content, plus a Linux thread with something in it too. But I'm too lazy to do that right now.

I know. You're not the only one who is lazy. Technically this thread could have been called launching multitouch utilites directly from java and my post would be on topic. The utilities work fine in XP without this, and my procedure hasn't been tested on Win7, so I don't where my post would even belong.

[nomaded]

IIRC, I don't think the problem was with running the configurator. The problem was doing the upload because of the java usb driver. I think. It's been a while since I've been motivated enough to change my keyboard configurations .

[DanT]

Well unfortunately I have some more Lion specific info so I think it will have to stay a Lion thread

Now that I have it installed I've seen there are a few more hiccups. I needed to update my libjusb settings in order to get the linked library to work. Following along viewtopic.php?t=337 I needed to update the patch file and recompile libjusb. I've attached the new patch file to the gist.

I also updated the script file to load the linked library properly. My keyboards are at the office, so I can't test just yet but it seems to be working much better. Will let you know once its tested.

[DanT]

Also on windows I think you'll need to pass in the same -Djava.library.path=..... to your jusb/lib folder. Not sure about XP/Win7 but you may need to recompile jusb with a new native library as well

[The00Dustin]

Dan,
What kind of hiccups did you see? I am interested in testing this with the latest version of Java a bit more (at least on XP, however irrelevant that testing might be). I don't have any compilation experience in Windows, but I'd at least like to know what to look for in case I ever cut over to Linux. Thanks,
Dustin

[DanT]

The utility ran but it couldn't find my touch stream when I connected to it. After recompiling jusb, I still get some interesting things in the log, but everything seems to be working fine.

I'd think on the linux side you might have to do something similar and recompile. I'm guessing the location of the jdk has changed since they last committed to the cvs repo. If you get stuck feel free to send me a note and I'll try and help.

[TorbenGB]

I recently switched to Linux (and I'm still a noob) so 'd like to test setting it up there... once I find time for it :-/

[DanT]

I put it all together in a blog post:

http://blog.119labs.com/2011/07/fingerw ... lity-lion/

Might be easier to follow if you're having trouble.

[TorbenGB]

I haven't forgotten this, it's still on my to-do list. I just haven't taken the time needed yet. When I do, I will report back - hopefully with a nice little success story

[humblehacker]

I've used this info and Platypus to create an application you can just drop in your Applications directory.

Fingerworks MultiTouch Utilities

[buserror]

I managed to get jusb installed in the lib/ directory, and multitouch utilities launches and recognize the keyboard (self test passes etc), however I can't upload my changes:

Code: Select all

new  idDevice: 0x160, idProduct: 0x90b,  idVendor: 0xe97
USB DFU suffix appended to: /Volumes/Users/michel/Documents/MyGestures/custom4f0040stealth34.U.byt
	MTS_config Binary /Volumes/Users/michel/Documents/MyGestures/custom4f0040stealth34.U.byt ready for transfer! 
Created Progress Panel, starting thread...
	existing  idDevice: 0x160	 idProduct: 0x90b	 idVendor: 0xe97
Java computed firmware image CRC32 0x37665e04 on 34249 bytes
Exception in thread "Thread-8" java.lang.NoClassDefFoundError: usb/linux/DeviceImpl
	at fingerworks.firmup.USBupgrader.a(Unknown Source)
	at fingerworks.firmup.USBupgrader.downloadFirmwareFile(Unknown Source)
	at fingerworks.firmup.USBupgrader.send2GestureProcessor(Unknown Source)
	at fingerworks.firmup.a.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.ClassNotFoundException: usb.linux.DeviceImpl
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 5 more

Any idea nyone ?