Xref: utzoo comp.lang.c:12286 comp.unix.questions:9052
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: HOw do you monitor keyboard and mouse input?
Keywords: keystroke, keynote, keycode,...
Message-ID: <1277@mcgill-vision.UUCP>
Date: 1 Sep 88 09:22:02 GMT
References: <2181@ssc-vax.UUCP> <14651@ism780c.isc.com>
Organization: McGill University, Montreal
Lines: 43

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.

Second, the program being executed probably does not expect the
keyboard and mouse on specific file descriptors; more likely, it
expects to open them with known names (eg, /dev/mouse and /dev/kbd).
Or perhaps it expects the keyboard on stdin and the mouse via
/dev/mouse.  That's assuming we have file descriptors at all, but all
systems on which one can "open both devices, fork [...], and dup [...],
and then exec [...]" will be UNIX (or close enough so no matter).

Third, even if it did, this technique might not help.  To pick a
specific example, on a Sun-3 running release 3.5 (ie, one of our Suns),
mouse input is read from /dev/mouse and each read() returns a
three-byte packet which is interpreted in a specific way.  But there's
no way to get this three-byte-at-a-time packet-style read behavior on
the slave side of a pty.

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.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu