At 09:03 AM 5/10/2006, Jonathan Cheyer wrote:
>Hi John,
>
>Comments inline.
>
>Jonathan
>
>
>John Sechrest wrote:
>> I think that it will be good to have the external switch, so that the
>> keyboard knows which mode to come up in as a default. And it can be
>> programatically converted between them. (01)
I agree that coming up initially in the non-Augment mode is the best
option. We should give each of these modes a standard name moving
forward. Maybe something like "keyboard mode" and "keyset mode", or
"non-Augment mode" and "Augment mode". Any suggestions? (02)
>The default mode should definitely be the standard keyset mode (5
>bit), since most applications are not Augment-enabled and would
>require the standard (non-Augment) behavior of the mouse when left-
>or right-clicking on things.
>
>If you are able to find a way to programmatically switch between the
>two modes, then I would suggest skipping the state switch
>altogether, since the default state will be the standard keyset
>mode. It would also simplify the hardware a little and keep the user
>interface simpler for the end-user (no extra switches to deal with). (03)
I still think there are some advantages to having a state switch,
unless we plan to have only AugTerm use the Augment mode and we build
a focus-based keyset mode switch into the program. Is that what you
were thinking, Jonathan? Do you anticipate that Hyperscope will
respond the the same commands as Augment, and will work with the
keysets in Augment mode? If so, without a mode switch you'll need a
way for Hyperscope to send a mode switch command to the keyset from
either Java Script or more likely from a supporting applet. There is
also a "marketing" reason to have it, if we want people to actually
see that it can work in both modes by noticing the switch. (04)
If we decide to have a physical switch, we need to think through the
issue of what kind of switch. A toggle switch will work if there is
no way to send a mode switch command from the host to the
keyset. However, it won't work if we allow this. When the mode it
switched by the host, the rocker will be in the wrong position. My
Panasonic digital camera has this problem with its on/off
switch. When the camera automatically turns itself off, the on/off
switch is still in the "on" position. To turn my camera back on, I
have to turn it to the "off" position and then back to the "on"
position. With my camera, it's obvious what state it's actually
in. With the keyset, that won't be the case unless you have a
separate indicator LED that shows its actual mode. An alternative is
a spring loaded button with a built-in indicator LED that is
controlled by keyset controller. That way, the switch is never in
the wrong position relative to the state. (05)
We should think this one through and reach a decision, since it will
impact the design and costs. John, how late can we make this
decision without jeopardizing an early September manufacture date? (06)
>> It is not a power switch. It is mislabled in the drawings. it is
>> a state switch for the mode of the mouse/keyboard. In one state
>> the mouse and keyboard are seperate. In the other mode,
>> the three buttons of the mouse and the 5 buttons of the keypad
>> are mapped into an 8 bit key code. (Augment mode)
>
>Ah, thanks for the clarification.
>
>> One of the USB connectors is for the PC connection
>> One of the USB connectors is for the Mouse
>> One of the USB connectors is for a USB Fob
>> I have assummed that the cable to the PC is just a
>> seperate cable. And that one of the USB connectors would be
>> labled as the upstream connector.
>
>Ok, this sounds fine.
>
>> The circuit board will do the key processing. And it will programatically
>> support the two modes that you describe. To do that it will need
>> to operate as a psuedo USB hub. As the key codes pass thru the usb hub,
>> it will transform the keycodes based on the switch. To do this makes
>> the board more complex. But it makes the Augment mode possible.
>> And it makes the keyboard transparent to the PC system, so that
>> it will not need any driver on the host.
>> At least that is the goal.
>
>If you think you would be able to support a programmatic switching
>of modes, that would be really great! This is essentially our
>"ideal" version of the chord keyset.
>
>Yes, avoiding the need for a driver on the host is a really useful
>proposition, because that would allow us to have the keyset be used
>(in 5-bit mode) for all traditional applications on the major
>platforms (Windows, Linux, MacOS) without any software work. (07)
On the issue of being able to send a mode command from host to
keyset, we'll need to define the command and ensure that it is
consistent with the other host to keyboard commands available on a
PS/2 keyboard. (08)
Philip Gust
Nouveau Systems, Inc.
3120 De La Cruz Blvd., Suite 120
Santa Clara, CA 95054 (09)
phone: +1 650 961-7992
fax: +1 520 843-7217 (010)
mailto: gust@NouveauSystems.com (011)
Nouveau Systems products seamlessly integrate collaboration,
information management, processes automation, and capture of
mission-critical knowledge. To learn how Nouveau Systems products
can help your organization drive innovation, visit:
http://www.NouveauSystems.com (012)
_________________________________________________________________
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 (013)
|