nls-technical
[Top] [All Lists]

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

To: NLS Restoration Technical Discussion <nls-technical@chm.cim3.net>, NLS Restoration Technical Discussion <nls-technical@chm.cim3.net>
Cc: bootstrap-nsf@ws.blueoxen.net
From: Philip Gust <gust@NouveauSystems.com>
Date: Sat, 11 Feb 2006 07:34:19 -0800
Message-id: <7.0.0.16.2.20060211052943.063316b0@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)
<Prev in Thread] Current Thread [Next in Thread>