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