Track keyboard and mouse usage

Discussion in 'Python' started by dfaber, Jul 17, 2006.

  1. dfaber

    dfaber Guest

    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.
     
    dfaber, Jul 17, 2006
    #1
    1. Advertising

  2. 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
     
    Diez B. Roggisch, Jul 17, 2006
    #2
    1. Advertising

  3. dfaber

    Guest

    Diez> You 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, 2006
    #3
  4. schrieb:
    > Diez> You 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
     
    Diez B. Roggisch, Jul 17, 2006
    #4
  5. dfaber

    Méta-MCI Guest

    Méta-MCI, Jul 17, 2006
    #5
  6. dfaber

    dfaber Guest

    So, how would I access /dev/input/ devices?
    Can I just 'cat' them or read in those files?


    Diez B. Roggisch wrote:
    > schrieb:
    > > Diez> You 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
     
    dfaber, Jul 17, 2006
    #6
  7. dfaber

    dfaber Guest

    So, how would I access /dev/input/ devices?
    Can I just 'cat' them or read in those files?


    Diez B. Roggisch wrote:
    > schrieb:
    > > Diez> You 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
     
    dfaber, Jul 17, 2006
    #7
  8. 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
     
    Diez B. Roggisch, Jul 17, 2006
    #8
  9. dfaber

    Guest

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

    MCI> Oooohhhhh!!! 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, 2006
    #9
  10. dfaber

    dfaber Guest

    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?
     
    dfaber, Jul 18, 2006
    #10
  11. On 17 Jul 2006 21:00:09 -0700, "dfaber" <> declaimed
    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

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
     
    Dennis Lee Bieber, Jul 18, 2006
    #11
  12. dfaber

    dfaber Guest

    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" <> declaimed
    > 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
    >
    > HTTP://wlfraed.home.netcom.com/
    > (Bestiaria Support Staff: )
    > HTTP://www.bestiaria.com/
     
    dfaber, Jul 18, 2006
    #12
  13. On 17 Jul 2006 23:26:38 -0700, "dfaber" <> declaimed
    the following in comp.lang.python:

    > That IS brain-crushingly complicated. However, thanks for the insight.
    > I really appreciate it.
    >

    I think the Amiga had a simple call to catch that data -- but on the
    other hand, the Amiga OS did not have an standard "event loop". Every
    application had to code an event loop/dispatcher. {On the third hand,
    the Amiga also had a very simple call to insert "events" into the
    handler stream and could, thereby, "control" other programs by "playing
    back" mouse/keyboard movements... The Amiga IDCMP system handled mouse,
    keyboard, and other events like floppy disk swaps [the OS did dynamic
    scanning for disks, not on demand, and could notify applications when a
    disk was inserted and/or removed -- injecting events was useful to hit
    the easter eggs: one used
    <left-shift><left-amiga><right-shift><right-amiga>[hold those four
    keys]<eject><insert> to display OS credits].

    The tricky part is being able to "register" for events /before/ they
    are filtered for "the focus window" -- that is, you want events
    regardless of what program is "active/on top" [The Amiga was good for
    that because it had a "push to back" capability, the active window did
    NOT have to be on top -- you could push it to the back while retaining
    focus, and type into the window even while it was covered]
    --
    Wulfraed Dennis Lee Bieber KD6MOG

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
     
    Dennis Lee Bieber, Jul 18, 2006
    #13
  14. On Tue, 18 Jul 2006 07:35:57 GMT, Dennis Lee Bieber
    <> declaimed the following in comp.lang.python:

    <snip>

    Talking to myself?

    I just wish to emphasize that my understanding IS filtered through
    15 year old usage... And a book titled "The Viewport Technician", which
    tried to explain how to design code portable between Amiga, Atari ST,
    Mac, Apple II GS, and Windows 3.x... IE, something that predates KDE,
    GTK, wx, etc.

    --
    Wulfraed Dennis Lee Bieber KD6MOG

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
     
    Dennis Lee Bieber, Jul 18, 2006
    #14
  15. dfaber

    Guest

    Dennis> Problem: X-Window supports remote displays; you'd need a means
    Dennis> of specifying which display to track (unless you've opened a GUI
    Dennis> application 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.

    Dennis> I 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
    Dennis> whose [... 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, 2006
    #15
  16. On Tue, 18 Jul 2006 06:12:38 -0500, declaimed the
    following in comp.lang.python:


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

    Guess I should find a text book on OpenGL then, just so I have some
    idea of the capabilities.
    --
    Wulfraed Dennis Lee Bieber KD6MOG

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
     
    Dennis Lee Bieber, Jul 18, 2006
    #16
  17. dfaber

    Lars Guest

    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.)
     
    Lars, Jul 19, 2006
    #17
  18. 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
     
    Diez B. Roggisch, Jul 19, 2006
    #18
  19. dfaber

    Guest

    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/tutorials/xlib-programming/xlib-programming.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, 2006
    #19
  20. dfaber

    dfaber Guest

    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.

    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/tutorials/xlib-programming/xlib-programming.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.
     
    dfaber, Jul 23, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fabian Braennstroem

    track cpu usage of linux application

    Fabian Braennstroem, May 14, 2007, in forum: Python
    Replies:
    2
    Views:
    344
    Fabian Braennstroem
    May 15, 2007
  2. Replies:
    7
    Views:
    2,595
    Hendrik Schober
    Oct 1, 2008
  3. Alex Vincent

    how to track webservice usage?

    Alex Vincent, Jul 21, 2003, in forum: ASP .Net Web Services
    Replies:
    3
    Views:
    231
    Roman Kiss
    Jul 25, 2003
  4. Adrian

    How to track memory usage?

    Adrian, Feb 27, 2006, in forum: Javascript
    Replies:
    8
    Views:
    145
    Richard Cornford
    Mar 1, 2006
  5. Replies:
    4
    Views:
    124
Loading...

Share This Page