Solved Detect recent keypress

If I'm running a FreeBSD system without X, but with several virtual terminals doing various things, under certain circumstances I will use vidcontrol() to switch to a particular virtual terminal in case of an alarm event. But I don't want to do that if I'm actively typing in one or another virtual terminal.

So before doing the virtual terminal switch, I wish to see whether a keypress has happened within, say, three seconds. If so, I won't switch; if not, I'll switch.

How do I determine, in a background process (possibly as root), how long ago the most recent keypress has occurred? If it's necessary to run a different process just to keep track of each keypress event (non-X) and put that in a file somewhere, I'm willing to do that.
 
You can temporarily disable VT switching globally
This provides a method for a sort of manual kludge, and is intriguing. What I was hoping for was something that didn't require extra manual effort at the time of keyboard entry.

The only way I can think of to do this automatically is for each VT to feed everything from the keyboard to a pty (and output from the pty back to the screen), and use a timer, shared memory, and a shared semaphore between the same pty-using application running on all virtual terminals, allowing virtual terminal switching only when the number of VTs with recent keystrokes reaches zero. I was hoping for something a little simpler.
 
Code:
hopo $ vmstat -i
interrupt  total  rate
irq1: atkbd0  7648  0
Could you keep an eye on irq1 count?
Sounds good! Which of these is the keyboard? (And where would I go to find the answer to that myself?)
Code:
home:~$ vmstat -i
interrupt  total  rate
irq18: ehci0 uhci5  4  0
irq19: uhci2 uhci4*  90585  4
irq21: uhci1  11481  0
cpu0:timer  446896  23
irq256: em0  33758  1
irq257: hdac0  92  0
cpu1:timer  181709  9
irq258: vgapci0  6391  0
Total  770916  40
home:~$
EDIT: I'm using the vt driver, if that makes a difference.
 
Oh? atkbd0 is missing. USB peripherals shoot this solution down. Damn progress...

Function dointr() in /usr/src/usr.bin/vmstat/vmstat.c would have been an example,
basically sysctl -o hw.intrcnt.

There's sysctl kern.tty_nin which counts terminal input characters, but if you have network logins, ppp, ... it fails too.

Check kbdmux driver if there is a nice upcall routine. It could increment a variable of your invention from any keypress. There are no existing statistics in vt or kbdmux, it seems. Using sysctl mechanism might be least fuss.

Ah! Just remembered. snp(4) is our voyeristic friend! Just immediately bzero everything you get, so a mishap and a coredump won't leave sensitive data laying around :)
watch(8)

Juha
 
Bingo.

There's sysctl kern.tty_nin which counts terminal input characters, but if you have network logins, ppp, ... it fails too.

In this case, all relevant activity is local. The only goal is to prevent the local screen from disappearing out from under a keyboarding guy for the purpose of showing the alarm screen.
 
Beware innocent looking programs that use pseudo ttys for some reason.

There's also usbdump(8). I don't have a keyboard to test with, but
usbdump -i usbus1 -f 3.129 produces output whenever mouse is wiggled.
(The mouse happens to be at ugen1.3 today. Painful "##%% to determine which usb device is which.)

Juha
 
I don't have a keyboard to test with, but
usbdump -i usbus1 -f 3.129 produces output whenever mouse is wiggled.
(The mouse happens to be at ugen1.3 today. Painful "##%% to determine which usb device is which.)

Fortunately, all I have to deal with is the keyboard on virtual consoles. No mouse, no relevant network activity, no ppp.

Beware innocent looking programs that use pseudo ttys for some reason.

The only program to use ptys would be one that I would write, to keep track of keyboard activity on each virtual console. So it would be as innocent as I would want to make it. But that would be part of a plan which is more complex than it needs to be, because I can go simple, thanks to your kern.tty_nin trick.
 
Back
Top