Bug 130330

There is currently no way to fix this, if you have a non-PS/2 mouse.
See FAQ: http://www.jwz.org/xscreensaver/faq.html#mouse-idle

If the X server ever gains support for the XIdle extension, then this
problem will go away: https://bugs.freedesktop.org/show_bug.cgi?id=1419

I understand now. Kernel 2.6 uses a different driver for IRQ12 if it is
not used by /dev/psaux, but is used by the input framework and serio instead:

[zaitcev@lembas ksrc]$ cat /proc/interrupts
           CPU0
  0:  129072796          XT-PIC  timer
  1:      84195          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:     139509          XT-PIC  Intel 82801DB-ICH4
  9:          5          XT-PIC  acpi
 11:    9256387          XT-PIC  ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd, yenta,
yenta, eth0, radeon@pci:0000:01:00.0
 12:    1479745          XT-PIC  i8042
 14:      97783          XT-PIC  ide0
 15:    1187030          XT-PIC  ide1
NMI:          0
ERR:          0
[zaitcev@lembas ksrc]$

So, xscreensaver thinks that IRQ12 is not used for a mouse.
I should have read the FAQ.

Ray, I won't have a problem if you wontfix this bug.

Actually, I didn't notice that this report was about 4.14.
I think that it should work ok if you are running 4.19 or later
(I think (hope!) that "i8042" always means "kbd or mouse".)

More detail (from xscreensaver/driver/timers.c):


/* 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. [...]  This is tricky for a number of reasons.

     * First,  [...irrelevant...]

     * 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, [...irritating, but irrelevant...]

     * 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.)

   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.
 */

Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Fixed in FC4T2
xscreensaver-base-4.21-1