By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,837 Members | 1,842 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,837 IT Pros & Developers. It's quick & easy.

Track keyboard and mouse usage

P: n/a
Hi all,
I have been searching for a keyboard and mouse tracker on linux. I've
read solutions (watch at sourceforge) which look at /proc/interrupts to
check keyboard or mouse activity. I also read one post where "watch"
seems to have difficulty tracking usb keyboards and mice. So, I'm out
of ideas here.

My goal are:
1. Check keyboard activity. I'm not interested in logging which keys
are pressed or record them.
2. Monitor mouse activity. I want to know the pointer position,
left-clicks, right-clicks, middle-mouse button usage.

I know that these things can be done in a GUI environment. I am looking
for some approach that helps me do this system-wide.

Any suggestions would be welcome. Again, I am looking for trackers on
Linux based machines.

Jul 17 '06 #1
Share this Question
Share on Google+
16 Replies


P: n/a
dfaber schrieb:
Hi all,
I have been searching for a keyboard and mouse tracker on linux. I've
read solutions (watch at sourceforge) which look at /proc/interrupts to
check keyboard or mouse activity. I also read one post where "watch"
seems to have difficulty tracking usb keyboards and mice. So, I'm out
of ideas here.

My goal are:
1. Check keyboard activity. I'm not interested in logging which keys
are pressed or record them.
2. Monitor mouse activity. I want to know the pointer position,
left-clicks, right-clicks, middle-mouse button usage.

I know that these things can be done in a GUI environment. I am looking
for some approach that helps me do this system-wide.

Any suggestions would be welcome. Again, I am looking for trackers on
Linux based machines.
You could use the /dev/input/event* devices. The link I had for the docs
is unfortunately dead - I guess lubusb and its python binding might help
you, too.

Diez
Jul 17 '06 #2

P: n/a

DiezYou could use the /dev/input/event* devices.

On the only Linux system I have available (Mojam's CentOS-based web server),
/dev/input/* are readable only by root. That doesn't seem like it would be
very useful to tools like watch unless they were to run suid to root
(creating other problems).

As the author of watch, I'm more than happy to incorporate "drivers" from
other people into the code, however, I have very little access to Linux
these days (and none on the desktop) and no Windows access.

Skip
Jul 17 '06 #3

P: n/a
sk**@pobox.com schrieb:
DiezYou could use the /dev/input/event* devices.

On the only Linux system I have available (Mojam's CentOS-based web server),
/dev/input/* are readable only by root. That doesn't seem like it would be
very useful to tools like watch unless they were to run suid to root
(creating other problems).
You don't need to give it root access. A simple rule for the udev that
looks like this:

KERNEL=="event[0-9]*", NAME="input/%k", MODE="0444"
will make the devices world readable. While I haven't thought about any
security implications that might have (and am not especially
knowledgeable in such things to be honest), I'm convinced it is way less
likely to introduce any exploitable holes than suid root would.

Diez
Jul 17 '06 #4

P: n/a
Hi!

Look PyHook ( http://cheeseshop.python.org/pypi/pyHook/1.4 )

Oooohhhhh!!! Sorry! It's for Windows...
--
MCI


Jul 17 '06 #5

P: n/a
So, how would I access /dev/input/ devices?
Can I just 'cat' them or read in those files?
Diez B. Roggisch wrote:
sk**@pobox.com schrieb:
DiezYou could use the /dev/input/event* devices.

On the only Linux system I have available (Mojam's CentOS-based web server),
/dev/input/* are readable only by root. That doesn't seem like it would be
very useful to tools like watch unless they were to run suid to root
(creating other problems).

You don't need to give it root access. A simple rule for the udev that
looks like this:

KERNEL=="event[0-9]*", NAME="input/%k", MODE="0444"
will make the devices world readable. While I haven't thought about any
security implications that might have (and am not especially
knowledgeable in such things to be honest), I'm convinced it is way less
likely to introduce any exploitable holes than suid root would.

Diez
Jul 17 '06 #6

P: n/a
So, how would I access /dev/input/ devices?
Can I just 'cat' them or read in those files?
Diez B. Roggisch wrote:
sk**@pobox.com schrieb:
DiezYou could use the /dev/input/event* devices.

On the only Linux system I have available (Mojam's CentOS-based web server),
/dev/input/* are readable only by root. That doesn't seem like it would be
very useful to tools like watch unless they were to run suid to root
(creating other problems).

You don't need to give it root access. A simple rule for the udev that
looks like this:

KERNEL=="event[0-9]*", NAME="input/%k", MODE="0444"
will make the devices world readable. While I haven't thought about any
security implications that might have (and am not especially
knowledgeable in such things to be honest), I'm convinced it is way less
likely to introduce any exploitable holes than suid root would.

Diez
Jul 17 '06 #7

P: n/a
dfaber schrieb:
So, how would I access /dev/input/ devices?
Can I just 'cat' them or read in those files?
Yes, just read them. Which is what cat does, btw.

If you cat your keyboard, you should see garbage appearing in the
terminal when you type any key. Same is true for the mouse.

Diez
Jul 17 '06 #8

P: n/a
MCILook PyHook ( http://cheeseshop.python.org/pypi/pyHook/1.4 )

MCIOooohhhhh!!! Sorry! It's for Windows...

That's okay (well, for me anyway). Watch runs on Windows. Perhaps someone
with Windows would like to plug pyHook into watch?

Skip
Jul 18 '06 #9

P: n/a
Is there no clean method of accessing the keyboard device or the mouse
on linux?
It seems that looking at /proc/interrupts might prove to be useful for
keyboard monitoring. What about checking if the left mouse button is
clicked or finding the position of the cursor on the screen?

Jul 18 '06 #10

P: n/a
That IS brain-crushingly complicated. However, thanks for the insight.
I really appreciate it.
Dennis Lee Bieber wrote:
On 17 Jul 2006 21:00:09 -0700, "dfaber" <de*******@gmail.comdeclaimed
the following in comp.lang.python:
Is there no clean method of accessing the keyboard device or the mouse
on linux?
It seems that looking at /proc/interrupts might prove to be useful for
keyboard monitoring. What about checking if the left mouse button is
clicked or finding the position of the cursor on the screen?

For a GUI application, it probably depends upon the interface
supplied by that GUI system... So far as I know, all Linux variants are
using an X-Window clone as the bottom protocol.

Problem: X-Window supports remote displays; you'd need a means of
specifying which display to track (unless you've opened a GUI
application and that application is asking for positions -- but it may
not be able to track outside the application window... Sorry to be so
vague -- I last coded an X interface back in 1990, using xt/DECWindows
calls; didn't even have a GUI designer available*)

I don't think anyone has ported raw X-protocol access to Python.

All those "monitoring" operations you are asking for are "events" to
a windowing environment, and applications have to "register" for the
events they are interested in seeing.

* If working raw xt/DECWindows wasn't bad enough... Add GKS (is that
still around?) on top of it -- I had a DECWindows UI whose main window
was a plain drawing region, and GKS was used to handle the underlying
data. The application was both graphics intensive, and needed a display
list (in scaleable coordinates to handle window resize) for refresh
operations; it used a 32 color "data" field, and four or so single color
"overlays" -- and any one of the five could be enabled/disabled without
requiring a recomputation of the drawing. This mess was because the
DECWindows/GKS application was an emulation (at the API level) of a late
70s/early 80s RAMTEK graphics engine... The "main" application was
really something like 50 specialized programs that all "connected" to
the "graphics engine", drew some data, and exited; allowing other
programs in the suite to draw on the /same/ window -- which is why the
need for GKS; refreshes couldn't ask for the source application to
repaint the screen. {The very oldest version of the software ran on
PDP-11s, hence the modular programs, the control program would collect
user data/parameters, write a "common block file" then invoke the needed
submodule as an overlay.
--
Wulfraed Dennis Lee Bieber KD6MOG
wl*****@ix.netcom.com wu******@bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: we******@bestiaria.com)
HTTP://www.bestiaria.com/
Jul 18 '06 #11

P: n/a

DennisProblem: X-Window supports remote displays; you'd need a means
Dennisof specifying which display to track (unless you've opened a GUI
Dennisapplication and that application is asking for positions ...

Watch does this via server mode (sort of). You run watch on both your local
and remote machines. The remote machine forwards information about mouse
movement to the local machine.

DennisI don't think anyone has ported raw X-protocol access to Python.

There is a (defunct) Xlib wrapper for Python. Nowadays you could probably
redo just the parts you need pretty easily with ctypes.

Dennis* If working raw xt/DECWindows wasn't bad enough... Add GKS
Dennis(is that still around?) on top of it -- I had a DECWindows UI
Denniswhose [... many magical reminiscences elided ;-) ...]

I believe OpenGL pretty much killed the market for stuff like GKS. X
servers have enough features and video boards have enough performance that
for all but the most demanding graphics applications there's no desired to
write bits using something other than OpenGL and no need to expose the raw
framebuffer at the application program level.

Skip

Jul 18 '06 #12

P: n/a
Diez B. Roggisch wrote:
will make the devices world readable. While I haven't thought about any
security implications that might have (and am not especially
knowledgeable in such things to be honest), I'm convinced it is way less
likely to introduce any exploitable holes than suid root would.
Depending on what kind of info these devices produce, couldn't they be
used to spy on someone typing in a password? (I can't check, I'm on
FreeBSD.)
Jul 18 '06 #13

P: n/a
Lars wrote:
Diez B. Roggisch wrote:
>will make the devices world readable. While I haven't thought about any
security implications that might have (and am not especially
knowledgeable in such things to be honest), I'm convinced it is way less
likely to introduce any exploitable holes than suid root would.

Depending on what kind of info these devices produce, couldn't they be
used to spy on someone typing in a password? (I can't check, I'm on
FreeBSD.)
I guess so. Good point.

Diez
Jul 19 '06 #14

P: n/a
Hello dfaber,

I had the same problem not long ago. I tried to use the Xlib since its
obvious the X server has all the events but I couldn't have the mouse
events if my app was out of focus. If you have a way to do that I'm
really interested.

Anyway I found this to be a good introduction to Xlib:
http://users.actcom.co.il/~choo/lupg...g.html#preface

Since I didn't find a way to do it I went down to the source of the
events which are provided by the evdev drivers:
http://en.wikipedia.org/wiki/Evdev

Fortunately you can use Python to access it:
http://svn.navi.cx/misc/trunk/python/evdev/

First you need to know your input devices, search the eventX in
relation to your device here:
cat /proc/bus/input/devices

Then you can do:
sudo python evdev.py /dev/input/eventX # where X is the event number
in relation to your device (kb is usually zero)

It works well but there is two problems with this solution:
- the root access is annoying (but I'll have to try Diez suggestion)
- The X event number of the mouse can change from a PC to another one
(you need to check the PC first with that cat command and search for
your "mouse"

francois

dfaber wrote:
Hi all,
I have been searching for a keyboard and mouse tracker on linux. I've
read solutions (watch at sourceforge) which look at /proc/interrupts to
check keyboard or mouse activity. I also read one post where "watch"
seems to have difficulty tracking usb keyboards and mice. So, I'm out
of ideas here.

My goal are:
1. Check keyboard activity. I'm not interested in logging which keys
are pressed or record them.
2. Monitor mouse activity. I want to know the pointer position,
left-clicks, right-clicks, middle-mouse button usage.

I know that these things can be done in a GUI environment. I am looking
for some approach that helps me do this system-wide.

Any suggestions would be welcome. Again, I am looking for trackers on
Linux based machines.
Jul 21 '06 #15

P: n/a
Hi Francois,
Thank you for providing me the evdev link! That was exactly what I was
looking for. Instead of sudo'ing the script, I changed /dev/input/
directory to be world readable.
After that, I had to change the way a file was accessed in evdev.py to:
Line No: 91 #self.fd = os.open(filename, os.O_RDWR |
os.O_NONBLOCK)
self.fd = os.open(filename, os.O_RDONLY | os.O_NONBLOCK)

Runs great.

Thanks again.

fr**************@gmail.com wrote:
Hello dfaber,

I had the same problem not long ago. I tried to use the Xlib since its
obvious the X server has all the events but I couldn't have the mouse
events if my app was out of focus. If you have a way to do that I'm
really interested.

Anyway I found this to be a good introduction to Xlib:
http://users.actcom.co.il/~choo/lupg...g.html#preface

Since I didn't find a way to do it I went down to the source of the
events which are provided by the evdev drivers:
http://en.wikipedia.org/wiki/Evdev

Fortunately you can use Python to access it:
http://svn.navi.cx/misc/trunk/python/evdev/

First you need to know your input devices, search the eventX in
relation to your device here:
cat /proc/bus/input/devices

Then you can do:
sudo python evdev.py /dev/input/eventX # where X is the event number
in relation to your device (kb is usually zero)

It works well but there is two problems with this solution:
- the root access is annoying (but I'll have to try Diez suggestion)
- The X event number of the mouse can change from a PC to another one
(you need to check the PC first with that cat command and search for
your "mouse"

francois

dfaber wrote:
Hi all,
I have been searching for a keyboard and mouse tracker on linux. I've
read solutions (watch at sourceforge) which look at /proc/interrupts to
check keyboard or mouse activity. I also read one post where "watch"
seems to have difficulty tracking usb keyboards and mice. So, I'm out
of ideas here.

My goal are:
1. Check keyboard activity. I'm not interested in logging which keys
are pressed or record them.
2. Monitor mouse activity. I want to know the pointer position,
left-clicks, right-clicks, middle-mouse button usage.

I know that these things can be done in a GUI environment. I am looking
for some approach that helps me do this system-wide.

Any suggestions would be welcome. Again, I am looking for trackers on
Linux based machines.
Jul 23 '06 #16

P: n/a
Dennis Lee Bieber wrote:
On 17 Jul 2006 21:00:09 -0700, "dfaber" <de*******@gmail.comdeclaimed
the following in comp.lang.python:
Is there no clean method of accessing the keyboard device or the mouse
on linux?
It seems that looking at /proc/interrupts might prove to be useful for
keyboard monitoring. What about checking if the left mouse button is
clicked or finding the position of the cursor on the screen?
....
>
I don't think anyone has ported raw X-protocol access to Python.
Actually someone did. http://python-xlib.sourceforge.net/ It's old
but it works fine. Speaks X protocol in pure python.

HTH,
~Simon

Jul 24 '06 #17

This discussion thread is closed

Replies have been disabled for this discussion.