Bug 130330 - xscreenserver ignores mouse clicks and blanks
Summary: xscreenserver ignores mouse clicks and blanks
Alias: None
Product: Fedora
Classification: Fedora
Component: xscreensaver   
(Show other bugs)
Version: 2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-19 07:45 UTC by Pete Zaitcev
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-03 19:11:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Pete Zaitcev 2004-08-19 07:45:52 UTC
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.


Comment 1 Jamie Zawinski 2005-02-28 03:29:44 UTC
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

Comment 2 Pete Zaitcev 2005-02-28 06:02:46 UTC
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
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.

Comment 3 Jamie Zawinski 2005-02-28 06:35:35 UTC
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:

                   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.

Comment 4 Matthew Miller 2005-04-26 15:56:12 UTC
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.

Comment 5 Pete Zaitcev 2005-05-03 19:11:11 UTC
Fixed in FC4T2

Note You need to log in before you can comment on or make changes to this bug.