If I do not move the mouse, but click from time to time, xscreensaver engages and blanks. This is very easy to do if you have a laptop with a touchpad, not so easy to do with a real mouse. One scenario where I hit it was that I did homework for a language class which required listening with a lot of pausing and writing. So, I put cursor over a "pause" button in Rythmbox and paused/resumed play without moving the cursor. Eventually, xscreensaver blanked the screen, even though obviously the system was active. xscreensaver-4.14-5 kernel-2.6.7-1.494.2.2 xorg-x11-6.7.0-5
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