Thanks for the comprehensive reply. To sum up: out of the box, the Linux HTCondor startd will try to detect keyboard usage on a machine by stat'ing various files in /dev, and looking at their most recent modification times. For virtual terminals (pty's), this works well, but that assumes that users are typing in some kind of shell that runs in a pty. It doesn't detect mouse movements, and it can't detect typing that doesn't happen inside of a pty (for example, in the email client I'm currently using). It does detect remotely ssh'd typing, though.
To detect the rest, condor needs to talk to the X windows server. It uses a separate program to do this, the ill-named keyboard daemon (condor_kbdd). Unfortunately, the kbdd needs permission to talk to the X server, which is why it usually runs as root, started by the master. However, if your home directories are mounted from NFS, this may be a problem which Michael cleverly fixes below, otherwise, the keyboard daemon should work out of the box, and that's what we'd recommend.
This is all on Linux -- on Windows, the condor keyboard daemon alone detects keyboard activity.
Independently of the above, there is a configuration knob in condor, SLOTS_CONNECTED_TO_KEYBOARD, which can allow some number of condor slots to continue to be used by remote condor jobs, even when the local user is working at the machine. The idea here is maybe you have an eight core desktop, and you are willing to let one or two cores be used by condor at all times. The default for this knob should be all of the slots, so that when a local user is working at a machine, no condor jobs can run. Unfortunately, there was a bug in condor 8.2.8 and earlier that set this default incorrectly, and would allow all but one slot to say running forever. You can fix this by upgrading to 8.2.9, or by setting SLOTS_CONNECTED_TO_KEYBOARD to some large number.
I will leave as an exercise for the reader how to detect keyboard and mouse activity for any Linux systems which have completely switched from X to Wayland...
I'm running Red Hat Enteprise Linux 6 here, and had a similar issue with our workstations. I had tried running the kbdd as root, but since home directories are on a root-squashed NFS filesystem, it wasn't able to read the cookies for the users, and thus was unable to connect to the display to monitor activity. I'm not sure if it'll be exactly what you need, but hopefully it'll at least get you closer.