+\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 in Linux 2.2 and 2.4 kernels with MP machines, it looks like this:
+
+ CPU0 CPU1
+ 0: 1671450 1672618 IO-APIC-edge timer
+ 1: 13037 13495 IO-APIC-edge keyboard
+
+ and in Linux 2.6, it's gotten even goofier: now there are two lines
+ labelled "i8042". One of them is the keyboard, and one of them is
+ the PS/2 mouse -- and of course, you can't tell them apart, except
+ by wiggling the mouse and noting which one changes:
+
+ CPU0 CPU1
+ 1: 32051 30864 IO-APIC-edge i8042
+ 12: 476577 479913 IO-APIC-edge i8042
+
+ Joy! So how are we expected to parse that? Well, this code doesn't
+ parse it: it saves the first line with the string "keyboard" (or
+ "i8042") in it, and does a string-comparison to note when it has
+ changed. If there are two "i8042" lines, we assume the first is
+ the keyboard and the second is the mouse (doesn't matter which is
+ which, really, as long as we don't compare them against each other.)
+
+ Thanks to Nat Friedman <nat@nat.org> for figuring out most of this crap.
+
+ Note that if you have a serial or USB mouse, or a USB keyboard, it won't
+ detect it. That's because there's no way to tell the difference between a
+ serial mouse and a general serial port, and all USB devices look the same
+ from here. It would be somewhat unfortunate to have the screensaver turn
+ off when the modem on COM1 burped, or when a USB disk was accessed.
+ */
+
+
+#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)
+ {
+ if (why) *why = "does not exist";
+ return False;
+ }
+
+ fclose (f);
+ return True;