Bug 161284 - PS/2 mouse not detected upon X startup
Summary: PS/2 mouse not detected upon X startup
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-22 00:41 UTC by Phil Staub
Modified: 2015-01-04 22:20 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-05-05 01:14:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Phil Staub 2005-06-22 00:41:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
Following an upgrade from FC3 to FC4, my PS/2 wheel mouse is no longer detected when starting X. The mouse is a Logitech model M-BJ58, which has a USB connector and a PS/2 adapter. 

During the upgrade, anaconda did not find a mouse, so I selected "Generic wheel mouse (PS2)", but the mouse pointer still did not respond to mouse movement when the X installer started. I was only able to continue with the graphical installation by plugging the mouse into the USB input (which isn't acceptable permanently; I use a PS/2 KVM switch), and THEN it was reported as a PS/2 Generic wheel mouse. I finished the installation, then put the mouse back on the PS/2 port when rebooting into the new installation. Now, the only way I can use the mouse is by plugging it into USB. 

/etc/sysconfig/mouse contains: 

FULLNAME="Generic - Wheel Mouse (PS/2)"
MOUSETYPE="imps2"
XEMU3="no"
XMOUSETYPE="IMPS/2"
DEVICE=/dev/input/mice


The InputDevice section of /etc/X11/xorg.conf contains:

Section "InputDevice"
      Identifier  "Mouse0"
      Driver      "mouse"
      Option      "Protocol" "IMPS/2"
      Option      "Device" "/dev/input/mice"
      Option      "ZAxisMapping" "4 5"
      Option      "Emulate3Buttons" "no"
EndSection


Finally, by booting the FC3 installation disk the mouse is properly identified when plugged into the PS/2 connector

Version-Release number of selected component (if applicable):
xorg-x11-6.8.2-31

How reproducible:
Always

Steps to Reproduce:
1. Plug mouse into PS/2 port
2. Boot FC4 into runlevel 5
3. Observe that mouse pointer does not move with mouse movement.
4. Plug mouse into USB port
5. Observe that mouse pointer moves with mouse movement.
  

Actual Results:  Normal operation only when mouse is plugged into USB port

Expected Results:  Mouse should operate when plugged into PS/2 port.

Additional info:

Comment 1 Nadeem 2005-07-15 01:08:07 UTC
I upgraded from FC2 to FC4, and have nearly the exact same problem. The mouse
wheel refuses to work when the mouse is pluggedi nto the PS/2 port, but works
fine when its in the USB port. Same mouse.

Comment 2 Phil Staub 2005-07-15 15:17:50 UTC
I suspect a hardware dependency somewhere in the chipset driver. Installing FC4
on my laptop works fine with the same mouse (in PS/2 mode). Also, I tried buying
a PS/2 to USB adapter to convert the mouse output of my KVM switch to USB to
plug into the problematic tower, and in that configuration even plugging it into
the USB port doesn't work. The only thing I've found that works is to plug the
USB connector of the mouse directly into the tower's USB input.

In the event that the specific chipset is significant, my mainboard is an Intel
D845GEBV2. At one time I knew what the chipset was, but I can't recall any more.

For the time being, I've switched back to FC3. 8-(

Comment 3 Mitch Smith 2005-11-27 01:56:20 UTC
I have a similar problem. Just upgraded a Dell Optiplex GX1 (500Mz) from FC2 to
FC4. Everything went smoothly with the 2.6.11-1.1369_FC4 kernel and the PC
operated just fine. 

However, when yum upgraded to 2.6.14-1.1367_FC4 the mouse disappeared and the
keyboard became very sluggish. The mouse is PS2 and a standard keyboard behind a
KVM switch. The mouse seems to be absent prior to X starting. However, sometimes
the mouse will appear on boot or can be made to start but only works for short
periods of time. Rebooting with the 2.6.11-1.1369 kernel brings everything back
into operation.

Comment 4 Mitch Smith 2005-11-27 02:00:00 UTC
(In reply to comment #3)
> I have a similar problem. Just upgraded a Dell Optiplex GX1 (500Mz) from FC2 to
> FC4. Everything went smoothly with the 2.6.11-1.1369_FC4 kernel and the PC
> operated just fine. 
> 
> However, when yum upgraded to 2.6.14-1.1637_FC4 the mouse disappeared and the
> keyboard became very sluggish. The mouse is PS2 and a standard keyboard behind a
> KVM switch. The mouse seems to be absent prior to X starting. However, sometimes
> the mouse will appear on boot or can be made to start but only works for short
> periods of time. Rebooting with the 2.6.11-1.1369 kernel brings everything back
> into operation.



Comment 5 Mitch Smith 2005-11-27 04:41:05 UTC
Sorry about the repeat of comment #4. Was just trying to make a correction and
got the whole thing again. 

However, some additional information. First I noticed that when booting with the
14-1.1637 kernel, the led of the optical mouse begins flashing consistently
during the kernel initialization process. This is well before X starts.
(Normally the led will only come on when the mouse is moved.) It is as if the
14-1 kernel is constantly polling the mouse. 

Second, I forced the installation of the 13-1.1532 kernel and booted with that.
It seems to work just fine so far. Will let it run overnight to be sure. 

Interestingly, the 14-1.1637 kernel seems to run just fine on my IBM T-21 laptop.

Comment 6 Paul Nasrat 2005-11-28 19:33:25 UTC
Are there any serio/input/mouse layer messages in dmesg after booting, or after
experiencing mouse loss?

What does cat /proc/bus/input/devices show

Comment 7 Dave Jones 2006-02-03 06:28:48 UTC
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.


Comment 8 John Thacker 2006-05-05 01:14:25 UTC
Closing per previous comment.


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