Re: [nls-technical] [bootstrap-nsf] Re: six chord keysets

[Philip Gust <gust@NouveauSystems.com>]

See comments inline.

At 12:07 AM 2/11/2006, Jonathan Cheyer wrote:
> Comments inline.
>
> Jonathan
>
>
> Philip Gust wrote:
> > Since Jonathan is managing the keysets, I'd like to ask him to shoot
> > a note to John Secrest and ask him to return the keyset for use by
> > active projects. (Jonathan, if you could do that before you take off
> > tomorrow, it might be available when you and Brian are back in town
> > and able to work on them again).
>
> Done.

Thanks for taking the time out from packing to do this.


> > I'm planning on building a
> Java package to provide keyset input to 
> > applications and applets.  We'll replace the current code in
> the Java 
> > VAT (JVAT) with this package.
>
> Phil, I've already got a KeysetListener interface (patterned after 
> java.awt.event.KeyListener) with the corresponding KeysetEvent class. It
> provides a generic mechanism for interfacing with multiple 
> platform-specific (and keyset-specific) drivers. The idea is that, over
> time, we can build as many specific drivers as is necessary to support
> all the known variants of keysets on the major platforms (Linux, Mac,
> Windows for now), and the Java Augterm program will be completely 
> decoupled from any of the details.
>
> Let's try to sync up on all of this so you can reuse what I've already
> got in place, as you start to add additional drivers.

Definitely.  I never invent where I can leverage.

> Hmm, JVAT, I hadn't heard that
> term before. Howard Palmer (author of the 
> new Java version of the AugTerm), has used "Java AugTerm" I
> believe. We 
> can toss around different names and see what sticks I
> guess.

I didn't know what to call it, so I

> > I'm assuming that this will
> entail a certain amount of native code on 
> > some platforms.  For Linux, we can probably use the game port
> device 
> > that Jonathan is already using without native code.  I'm not
> sure 
> > whether something similar is available on MacOS X.4, but I'll 
> > investigate this before writing native code.  On Windows, we
> can go 
> > one of three ways:
> > 
> > 1. Investigate whether some part of the Cygwin package provides what
> > we need (a long shot)
> > 2. Evaluate one of several existing windows-specific Java "game
> port" 
> > packages (possible)
> > 3. Write new windows-specific code for the keyset (most
> likely)
>
> Yes, in Linux, the way I get around the need to write any native (C,
> C++) code is to rely on reading a generic data stream from the 
> linux-specific /dev/js0 device file that represents the first analog
> gameport on a PC.
>
> There might be a chance that MacOS X has a similar device file 
> representation, since it is based on BSD.

I've found something called USB Overdrive that claims to be a
configurable, shareware MacOS X driver for a variety of USB devices
including joysticks.  Here's a URL:

http://www.versiontracker.com/dyn/moreinfo/macosx/13443&vid=41640.
 

I also found the general Human Interface Device (HID) framework,
including an HID Manager for accessing USB devices such as
joysticks.  Here's a URL:

http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Families_Ref/chapter_11_section_7.html
.
Applications use something called InputSprocket to interact with the HID
Manager.  Here's an article written by the lead InputSprocket
architect with some code samples:

http://www.mactech.com/articles/mactech/Vol.15/15.01/InsideInputSprocket/
. Nouveau Systems is a member of the Apple Developers Network so we can
probably get some advice on this.  

There is also a Java Input API project at java.net that seems to have a
framework with an OSX plugin:

https://jinput.dev.java.net/.

All of these tell me that there probably isn't a regular device similar
to the Linux /dev/input/js* that we can use directly.


> I suspect that Windows does not
> use device files in a UNIX-like way, so 
> that probably means the only way to get access to a device is through
> the usual Microsoft-specific APIs. If that is the case, it is almost
> definite that Microsoft-specific native code will need to be
> written.

Using Cygwin is a pretty long shot, and has the drawback of requiring
Cygwin to be installed (it's pretty big). 

There are several Java packages out there that claim to support joysticks
through JNI interfaces to Windows DLLs.  Several of them are
multi-platform and include Windows. JInput
(
https://jinput.dev.java.net/)  and JavaJoystick
(
http://sourceforge.net/projects/javajoystick/).  Others are are
Windows-only (cf

http://www.cybergarage.org/vr/device/joystick/java/, 
http://www.hardcode.de/jxinput/,

http://www.bigredswitch.co.uk/toolbox/joystick/).

If none of these work out, the JNI code will have to write directly to
Microsoft DirectInput.  Here's a brief article that shows how to
interface a joystick through DirectInput:

http://msdn.microsoft.com/coding4fun/gamedevelopment/beginning4/default.aspx
.


> > Whichever way, I plan on
> doing a decent device-side interface that 
> > will make it simple to plug in native code support.
>
> I don't have any abstraction of the native layer, since currently I've
> only got Java code. That interface will definitely need to be defined.
> As mentioned, the abstraction I've got is at the Java layer, so we're in
> pretty good shape as far as Java is concerned.

JInput looks to be the most promising because it has a platform-specific
plugin architecture with plugins for Win32i, Linux, and OS X.  I'd
consider looking at this first to provide native layer
abstraction.


> > I'm eager to get a keyset
> so that I can get an interface design out 
> > for review and investigate the platform-specific issues.  I
> want to 
> > get the JVAT  to a level where Doug can start using it as soon
> as possible.
>
> Agreed. Eugene, there are a few more things to flesh out with this 
> software before Doug would feel comfortable using it, but would be 
> useful to have Doug try new versions from time to time and give
> feedback.

> > Hopefully, what I produce
> will also be useful to keyset-enable a 
> > future Hyperscope client.
>
> The Java interfaces are very useful for any Java-based client that wants
> to use a keyset. But it is likely that we will need native interfaces
> and drivers in order for other languages (python, ruby, or c) to make
> use of the keyset.

Agreed.  It would be convenient, however, if the same underlying
native libraries could be used for both projects.


> Jonathan

Just one other note.  You mentioned that Radio Shack was no longer
producing the DB-15 to USB PC Gaming Adapter (26-164).  I've found
another source.  It's slightly more expensive, but we could get
enough for all the keysets.  Here's the URL:

http://www.trianglecables.com/usbtojoydbad.html

>  
> _________________________________________________________________
> Message Archives:
>
> http://chm.cim3.net/forum/nls-technical/
> Shared Files:
>
> http://chm.cim3.net/file/work/project/nls-restore/
> Community Portal:
>
> http://www.computerhistory.org/ 
> To Post:
>
> mailto:nls-technical@chm.cim3.net
> Community Wiki:
>
> http://chm.cim3.net/cgi-bin/wiki.pl?NLS_Restoration

Philip Gust
Nouveau Systems, Inc.

phone: +1 650 961-7992
fax:   +1 520 843-7217


mailto: gust@NouveauSystems.com

_________________________________________________________________
Message Archives: http://chm.cim3.net/forum/nls-technical/
Shared Files: http://chm.cim3.net/file/work/project/nls-restore/
Community Portal: http://www.computerhistory.org/  
To Post: mailto:nls-technical@chm.cim3.net
Community Wiki: http://chm.cim3.net/cgi-bin/wiki.pl?NLS_Restoration    (01)