Bug 62955 - X doesn't wake up on mouse movement
X doesn't wake up on mouse movement
Product: Red Hat Public Beta
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-04-08 08:14 EDT by Thomas M Steenholdt
Modified: 2007-04-18 12:41 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-14 14:38:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thomas M Steenholdt 2002-04-08 08:15:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9) Gecko/20020311

Description of problem:
The default X installation configuration does not resume from powersaving mode
when moving the mouse. Keyboard must be activated before the session resumes.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Default RH installation
2. Boot and wait for X to suspend the monitor
3. Move the mouse

Actual Results:  Nothing

Expected Results:  X Should have woken up

Additional info:

My Video adapter is a 3DBlaster GeForce2MX
Comment 1 Mike A. Harris 2002-04-08 18:34:03 EDT
I'm not sure if this could be due to a kernel bug, X bug, APM bug, or
just configuration.

Make sure you are running the latest BIOS update for your machine, as they
often solve problems like this related to APM.

Arjan, any thoughts?
Comment 2 Thomas M Steenholdt 2002-04-09 04:41:04 EDT
My system BIOS is up-to-date.

I should probably mention, that this was not a problem when my system was
running RH 7.2.
Comment 3 Arjan van de Ven 2002-04-09 05:29:30 EDT
Ok simple test: can you install the 2.4.9-31 kernel from the 7.2 updates and
test that. If that works then it's a kernel change, if that still doesn't work
it's an XFree thing, maybe. A third thing to try is to downgrade the "gpm" rpm
to the 7.2 one.
Comment 4 Thomas M Steenholdt 2002-04-10 02:10:09 EDT
OK, to successfully install, and boot from 2.4.9-31, I had to move my only
harddisk from hde(Promise Ultra133-TX2 controller) to hda, as the promise
controller was not supported in the 2.4.9-31 version of the kernel. So I moved
the device and started the system, still using the 2.4.18 kernel shipped with
skipjack. I wanted to make sure that the problem was still there, before
conducting the actual proposed test. And guess what... It works just fine now!?!
The Promise Controller is still installed in the computer and there is a DVD
drive attached to it, but it does NOT install it's BIOS on boot, as there is no
supported bootable devices attached to the controller. Could this be it?
Other that that I changed the kernel command line a bit... of course changing
the root from /dev/hde2 to /dev/hda2 but I also removed two options of ide-scsi.
One for my cd-rw drive which was completely removed in the new test
configuration and one for the DVD drive attached to the promise controller.
Comment 5 Thomas M Steenholdt 2002-04-14 07:42:51 EDT
I did some further testing, as I was suspecting the Promise controller might
have something to do with the problem. I have also been tracking a problem,
where mouse controls(clicks) does not seem to work correctly after having run an
apm -s from X/GNOME... So I removed the promise controller completely - same
problem(the problem descriped right here - I will continue with tests with the
2.4.9-31 kernel and I will try to reproduce the problem, that this bugreport is
about. The reason i mention the strange mouse behaviour in this report, is that
whenI do an apm -s, the system does not wake up at mouse movement. (should i
create another bugreport on tat one or should we see where this goes before
Comment 6 Arjan van de Ven 2002-04-14 08:02:34 EDT
resuming from apm -s is 100% a bios thing (most bioses have settings that
control what makes the machine wake up).....
Comment 7 Thomas M Steenholdt 2002-04-15 01:46:34 EDT
OK - Then I suppose that the X wake up problem, is probably caused by the
promise controller BIOS and/or some conflicts with my PC BIOS. I've written to
Promise support, to get their idea on the matter, but haven't got anything back
yet. The X wake up on mouse movement problem is non-existant, if the Promise
controller BIOS is not installed. The other problem i have mentioned here will
be reported in a new bugreport in a few moments.
Comment 8 Thomas M Steenholdt 2002-04-16 01:12:44 EDT
Here is the answer I got from Promise 

The reason that your experiencing this is due to driver problem. The
card currently has not Linux driver to truly support the OS and any
function it has. Promise is currently working on the driver and there is
no ETA on when it will be release yet.

I don't know for sure, but I thought plenty of people was using the Promise
Ultra133TX2 in their linux boxes... Do You guys have another oppinion on this
Comment 9 Arjan van de Ven 2002-04-16 14:11:56 EDT
Promise is just saying stuff... I can't explain why having their card in makes a
difference (I'm sure you're not using the binary only drivers) though....
Comment 10 Thomas M Steenholdt 2002-04-17 03:02:28 EDT
It seems to work under Windows Xp, though. Do You have any idea what I could
try, in order to close in on the problem and/or a fix - I thought of compiling
and installing a 2.4.19-pre-latest to see if that could make a differende. I
won't be able to do this until tonight at the earliest!
Comment 11 Thomas M Steenholdt 2002-04-18 02:47:36 EDT
2.4.19-pre7 does not show any changes inthis behaviour... At least not when
compiling using a near-similar-to-kernel-2.4.18-0.13.i686.config for configuration.

Any ideas to what I could try to change, in order to change behaviour on this issue?
Comment 12 Thomas M Steenholdt 2002-05-08 06:46:33 EDT
Nothing changed, in relation to this bug, in RH 7.3
Comment 13 Mike A. Harris 2002-05-21 04:50:01 EDT
This problem is still totally up in the air as to wether it is a hardware issue,
local configuration issue, kernel issue, or XFree86 issue.  I'd suggest doing
some troubleshooting of this problem on mailing lists such as xpert@xfree86.org,
linux-kernel, and possibly others to see if anyone else has suggestions as
to what to try - either to fix the problem, or to find more details as to what
is causing the problem.

Quite honestly, if we can't easily reproduce a problem with available hardware,
then it is next to impossible to try to fix.  Problems with APM tend to vary
wildly as to what the problem is, and quite often end up being hardware issues.

Considering the difficulty in troubleshooting this sort of issue, I need
to be honest and tell you that it would be very low priority to look into
further without a lot more detail.

If you can gather up sufficient detail to show that it is a kernel issue,
or that it definitely is not a hardware issue, or some other such detail
to narrow the problem down, it could help greatly to find either a proper
solution, or at least a workaround.

Sorry, I can't be of more assistance currently.
Comment 14 Thomas M Steenholdt 2002-05-21 13:34:18 EDT
I think, that the error is actually caused by either

a) An oversimplified BIOS - My system is an IBM PC and the BIOS setup utility is
geared towards "normal" people. I can't ask it to monitor additional IRQ's for
Activity in the APM dialog, but only "Hard Disk Controller", "Serial Ports" etc.
This means that activity on my add-on Promise controller is not considered to be
worth keeping my system alive for and so, after a while the system may be going
in to an even deeper state of power-saving that what i usually experience. My
on-board controller is monitored for activity just fine.

b) Power Savings is aparrently a complete stranger to the people over at
promise. They have informed me that the adapter does not support any kind of
power saving, whatsoever. However i'm told that they are in fact working on this
for the Ultra 133-TX3 device at the moment, but cannot tell when the next
firmware upgrade will be ready.

c) all of the above

For the moment, I've moved my system Hard Drive onto the on-board controller,
which effectively eliminates the problem. The Promise Controller is still
installed in the computer(for when i am going to test the new firmware for
changes in this behaviour) but it's BIOS won't be installed, as there are no
drives attached.

I think that this is where the problem probably lies - Unfortunately I have no
clone pc with more tunable/generic BIOS possibilities to try on, so i'm having
trouble, deciding on either one of the described possible problem sources.

The reason I never experienced this problem on 7.2 is most likely due to the
fact, that the promise controller was first supported in 7.3, and I have always
used my on-board controller on RHL versions prior to 7.3.
Comment 15 Thomas M Steenholdt 2002-08-14 14:37:55 EDT
Doing it all over again with RH7.3 and a 2.4.19 kernel, this is no longer an issue.
It seems that the older promise driver versions had a problem with telling the
system about disk activity on this device, making the system think that nothing
was being used, and thus brought to a complete Standby! I suppose a Resume from
Standby requires more than mouse movement, and that's what was happening...

With the 2.4.19 kernel I have yet to see a Standby situation - I strongly
believe that my problem has simply been corrected in the kernel
Comment 16 Thomas M Steenholdt 2002-08-14 14:40:13 EDT
My hope now is that the 2.4.19 kernel makes it into limbo(or at least the
promise driver)

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