Xref: utzoo comp.lang.c:12337 comp.unix.questions:9086
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!nrl-cmf!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sm.unisys.com!ism780c!mikep
From: mikep@ism780c.isc.com (Michael A. Petonic)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: HOw do you monitor keyboard and mouse input?
Keywords: keystroke, keynote, keycode,...
Message-ID: <14987@ism780c.isc.com>
Date: 1 Sep 88 23:46:37 GMT
References: <2181@ssc-vax.UUCP> <14651@ism780c.isc.com> <1277@mcgill-vision.UUCP>
Reply-To: mikep@ism780c.UUCP (Michael A. Petonic)
Organization: Interactive Systems Corp., Santa Monica CA
Lines: 36

In article <1277@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
 >In article <14651@ism780c.isc.com>, mikep@ism780c.isc.com (Michael A. Petonic) writes:
 >> In article <2181@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes:
 >>> I need to write a program which will sit in the background and watch
 >>> the keyboard and mouse for input.  Of course, I don't want to
 >>> "disturb" the input, just "sit" in the food chain and observe.
 >(PLEASE say what sort of system you have, particularly for
 >system-specific things like this!  The system I'm using at the moment
 >doesn't even *have* a mouse (unless you count me :-).)
 >> Well, if you are using a system with PTY's, you can write a program
 >> that opens both devices, fork another process (to actually read and
 >> disturb the input :-), and dup the file descriptors comming off of
 >> the PTY to whatever the new process will expect, and then exec the
 >> new program.
 >
 >This is probably not much good.  First of all, this sort of thing is
 >verrry system-dependent.  What works on one system will often not work
 >on the next, even if they are supposedly compatible with one another.

Agreed.  I gave a general solution to what could be used on
a VAX running BSD, with a serial mouse.

 >I suspect what the original poster wanted is impossible without kernel
 >hacks, unless a half-solution is good enough, in which case it may be
 >possible to patch some libraries.  Patching libraries won't be able to
 >catch all uses of (say) the mouse, but it may be able to come close
 >enough; it depends on the application.

Well, not quite true.  I just wrote a Microsoft Bus Mouse STREAMS Driver
(386 AT Bus) that allowed you to peek at what was there.  Of course, it
all depends on the driver does.

-MikeP
-- 
Michael A. Petonic				mikep@ism780c.isc.com

       ``Living in the pools, they soon forget about the sea.''