+\f
+/* Some crap for dealing with /proc/interrupts.
+
+ On Linux systems, it's possible to see the hardware interrupt count
+ associated with the keyboard. We can therefore use that as another method
+ of detecting idleness.
+
+ Why is it a good idea to do this? Because it lets us detect keyboard
+ activity that is not associated with X events. For example, if the user
+ has switched to another virtual console, it's good for xscreensaver to not
+ be running graphics hacks on the (non-visible) X display. The common
+ complaint that checking /proc/interrupts addresses is that the user is
+ playing Quake on a non-X console, and the GL hacks are perceptibly slowing
+ the game...
+
+ This is tricky for a number of reasons.
+
+ * First, we must be sure to only do this when running on an X server that
+ is on the local machine (because otherwise, we'd be reacting to the
+ wrong keyboard.) The way we do this is by noting that the $DISPLAY is
+ pointing to display 0 on the local machine. It *could* be that display
+ 1 is also on the local machine (e.g., two X servers, each on a different
+ virtual-terminal) but it's also possible that screen 1 is an X terminal,
+ using this machine as the host. So we can't take that chance.
+
+ * Second, one can only access these interrupt numbers in a completely
+ and utterly brain-damaged way. You would think that one would use an
+ ioctl for this. But no. The ONLY way to get this information is to
+ open the pseudo-file /proc/interrupts AS A FILE, and read the numbers
+ out of it TEXTUALLY. Because this is Unix, and all the world's a file,
+ and the only real data type is the short-line sequence of ASCII bytes.
+
+ Now it's all well and good that the /proc/interrupts pseudo-file
+ exists; that's a clever idea, and a useful API for things that are
+ already textually oriented, like shell scripts, and users doing
+ interactive debugging sessions. But to make a *C PROGRAM* open a file
+ and parse the textual representation of integers out of it is just
+ insane.
+
+ * Third, you can't just hold the file open, and fseek() back to the
+ beginning to get updated data! If you do that, the data never changes.
+ And I don't want to call open() every five seconds, because I don't want
+ to risk going to disk for any inodes. It turns out that if you dup()
+ it early, then each copy gets fresh data, so we can get around that in
+ this way (but for how many releases, one might wonder?)
+
+ * Fourth, the format of the output of the /proc/interrupts file is
+ undocumented, and has changed several times already! In Linux 2.0.33,
+ even on a multiprocessor machine, it looks like this:
+
+ 0: 309453991 timer
+ 1: 4771729 keyboard
+
+ but on later kernels with MP machines, it looks like this:
+
+ CPU0 CPU1
+ 0: 1671450 1672618 IO-APIC-edge timer
+ 1: 13037 13495 IO-APIC-edge keyboard
+
+ Joy! So how are we expected to parse that? Well, this code doesn't
+ parse it: it saves the last line with the string "keyboard" in it, and
+ does a string-comparison to note when it has changed.
+
+ Thanks to Nat Friedman <nat@nat.org> for figuring out all of this crap.
+
+ Note that this only checks for lines with "keyboard" in them. Perhaps we
+ should also be checking for lines with "PS/2 Mouse" in them. But that
+ would obviously fail to work for regular serial mice, and obviously just
+ using COM1 would be bad news (turn off the screensaver because the modem
+ is active, yum.)
+ */
+
+
+#ifdef HAVE_PROC_INTERRUPTS
+
+#define PROC_INTERRUPTS "/proc/interrupts"
+
+Bool
+query_proc_interrupts_available (saver_info *si, const char **why)
+{
+ /* We can use /proc/interrupts if $DISPLAY points to :0, and if the
+ "/proc/interrupts" file exists and is readable.
+ */
+ FILE *f;
+ if (why) *why = 0;
+
+ if (!display_is_on_console_p (si))
+ {
+ if (why) *why = "not on primary console";
+ return False;
+ }
+
+ f = fopen (PROC_INTERRUPTS, "r");
+ if (!f)
+ return False;
+
+ fclose (f);
+ return True;
+}
+
+
+static Bool
+proc_interrupts_activity_p (saver_info *si)
+{
+ static FILE *f0 = 0;
+ FILE *f1 = 0;
+ int fd;
+ static char last_line[255] = { 0, };
+ char new_line[sizeof(last_line)];
+
+ if (!f0)
+ {
+ /* First time -- open the file. */
+ f0 = fopen (PROC_INTERRUPTS, "r");
+ if (!f0)
+ {
+ char buf[255];
+ sprintf(buf, "%s: error opening %s", blurb(), PROC_INTERRUPTS);
+ perror (buf);
+ goto FAIL;
+ }
+ }
+
+ if (f0 == (FILE *) -1) /* means we got an error initializing. */
+ return False;
+
+ fd = dup (fileno (f0));
+ if (fd < 0)
+ {
+ char buf[255];
+ sprintf(buf, "%s: could not dup() the %s fd", blurb(), PROC_INTERRUPTS);
+ perror (buf);
+ goto FAIL;
+ }
+
+ f1 = fdopen (fd, "r");
+ if (!f1)
+ {
+ char buf[255];
+ sprintf(buf, "%s: could not fdopen() the %s fd", blurb(),
+ PROC_INTERRUPTS);
+ perror (buf);
+ goto FAIL;
+ }
+
+ /* Actually, I'm unclear on why this fseek() is necessary, given the timing
+ of the dup() above, but it is. */
+ if (fseek (f1, 0, SEEK_SET) != 0)
+ {
+ char buf[255];
+ sprintf(buf, "%s: error rewinding %s", blurb(), PROC_INTERRUPTS);
+ perror (buf);
+ goto FAIL;
+ }
+
+ /* Now read through the pseudo-file until we find the "keyboard" line. */
+
+ while (fgets (new_line, sizeof(new_line)-1, f1))
+ if (strstr (new_line, "keyboard"))
+ {
+ Bool diff = (*last_line &&
+ !!strcmp (new_line, last_line));
+ strcpy (last_line, new_line); /* save this line for next time */
+ fclose (f1);
+ return diff;
+ }
+
+ /* If we got here, we didn't find a "keyboard" line in the file at all. */
+ fprintf (stderr, "%s: no keyboard data in %s?\n", blurb(), PROC_INTERRUPTS);
+
+ FAIL:
+ if (f1)
+ fclose (f1);
+
+ if (f0 && f0 != (FILE *) -1)
+ fclose (f0);
+
+ f0 = (FILE *) -1;
+ return False;
+}
+
+#endif /* HAVE_PROC_INTERRUPTS */
+
+\f