Solved Detect recent keypress

[Bill Evans at Mariposa]

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.

 

[freethread]

The only way I know is the usual way (no ncurses) look at http://stackoverflow.com/questions/9429138/non-blocking-keyboard-read-c-c (not tested, the code looks ok) or ncurses(). I'm not sure this solve your problem (at skin).

 

[tobik@]

But I don't want to do that if I'm actively typing in one or another virtual terminal.

You can temporarily disable VT switching globally with vidcontrol -S off. Turn it back on with vidcontrol -S on.

 

[Bill Evans at Mariposa]

The only way I know is the usual way

What I'm looking for is to avoid switching virtual terminals if there has been typing on any virtual terminal within the most recent few seconds.

 

[Bill Evans at Mariposa]

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.

 

[Juha Nurmela]

hopo $ vmstat -i
interrupt  total  rate
irq1: atkbd0  7648  0

Could you keep an eye on irq1 count?

Juha

 

[Bill Evans at Mariposa]

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?)

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.

 

[Juha Nurmela]

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

 

[Bill Evans at Mariposa]

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.

 

[Juha Nurmela]

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

 

[Bill Evans at Mariposa]

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.