Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!bloom-beacon!usc!apple!sun-barr!newstop!texsun!texbell!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.std.misc
Subject: Re: User Interface Standards -- *Keyboards!*
Keywords: keyboards,standardize,plug-n-play,freedom,ADB
Message-ID: <5039@ficc.uu.net>
Date: 17 Jul 89 16:58:18 GMT
References: <115518@sun.Eng.Sun.COM> <13@ark1.nswc.navy.mil> <440@arc.UUCP> <17@ark1.nswc.navy.mil>
Organization: Xenix Support, FICC
Lines: 24

In article <17@ark1.nswc.navy.mil>, dsill@ark1.nswc.navy.mil (Dave Sill) writes:
> I don't care what you call it.  I don't see how you can run a mouse
> over a PC keyboard connection and have it work like one of the common
> PC mice such as Microsoft or Logitech.  Am I missing something?

I don't see why not... the standard PC mice generate a set of 5-byte serial
packets: [buttons] [delta x] [delta y] [delta x] [delta y]. What's wrong
with including these packets in the input stream?

The [buttons] only uses codes 0xF8 through 0xFF. That leaves 0x00 through
0xF7 for scancodes. If you want button-up/button-down you can always use
0xF7 followed by a scancode byte, and use the rest of the codes for other
devices. We're not talking super-high baud rates here.

Or even send the keyboard's idea of the (7-bit) ascii code followed by the
scancode, with 0xF7 for non-ascii data. That way a stupid device (like a
cheap terminal) can ignore every other byte (either way) and still work.

Am I missing something?
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: peter@ficc.uu.net, +1 713 274 5180. | Multiprocessors are just a
Personal: peter@sugar.hackercorp.com.   `-_-' | way of using up excess memory
Quote: Have you hugged your wolf today?  'U`  | bandwidth. - mark@mips.com