[comp.lang.c] HOw do you monitor keyboard and mouse input?

dmg@ssc-vax.UUCP (David Geary) (08/25/88)

  I've got a question to which I'm hoping that there is 
a pretty simple answer.  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.
Do I need to write a daemon?  Help.  I have to get
this done three weeks ago.  Thanks ;-)

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ David Geary, Boeing Aerospace,               ~ 
~ Seattle - "THE DRIZZLE CAPITAL OF THE WORLD" ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mikep@ism780c.isc.com (Michael A. Petonic) (08/27/88)

In article <2181@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes:
 >  I've got a question to which I'm hoping that there is 
 >a pretty simple answer.  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.
 >Do I need to write a daemon?  Help.  I have to get
 >this done three weeks ago.  Thanks ;-)

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.

Then, in your parent process (the one that originally opened the
PTY), you could sit in a loop, getting input from the mouse
and keyboard and passing the data along the apropriate PTY.

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

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

mouse@mcgill-vision.UUCP (der Mouse) (09/01/88)

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

mikep@ism780c.isc.com (Michael A. Petonic) (09/02/88)

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.''