Bug 62687 - IMPS/2 mouse works correctly in X only if gpm is running...
Summary: IMPS/2 mouse works correctly in X only if gpm is running...
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: XFree86
Version: skipjack-beta1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
Blocks: 61901
TreeView+ depends on / blocked
Reported: 2002-04-04 14:37 UTC by Marco Pratesi
Modified: 2007-04-18 16:41 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2002-04-22 19:21:33 UTC

Attachments (Terms of Use)

Description Marco Pratesi 2002-04-04 14:37:55 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020311

Description of problem:
I have an IMPS/2 Logitech mouse. I have disabled gpm as in some cases, on some
distros, it conflicts with the mouse in X,
and because I had some error messages from GPM on the console.
I have then eliminated GPM from startup services through ntsysv,
then I have rebooted; after the reboot and startx, mouse behaves
very strangely, with the pointer jumping here and there and clicking
by its own; some other times, all freezed and a hardware reset
was needed.
Things work correctly only now that I have reenabled
the gpm service...this seems strange to me, conflicts should
be normal when gpm is turned on, not when it's turned off :(

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

How reproducible:
Didn't try

Steps to Reproduce:
1.configure the IMPS/2 mouse through mouseconfig and let the XFree86 config
files to be accordingly updated
2.eliminate gpm from the startup services through ntsysv and reboot
3.startx, use the mouse

Expected Results:  IMPS/2 mouse correctly working in X with gpm turned off.

Additional info:

Comment 1 Bernhard Rosenkraenzer 2002-04-04 15:01:23 UTC
Absence of gpm triggering a problem can hardly be considered a gpm bug ;)

Comment 2 Marco Pratesi 2002-04-04 15:09:41 UTC
I agree... but I need to submit the bug... and I don't know which is the component
to be fixed... I was not able to understand this, sorry :(
I can only say you that the problem manifests itself only if gpm is off,
while it does not manifest if gpm is on.
If you need further infos about the computer hardware and conf files,
please ask me, I am at your disposal.

Comment 3 Bill Nottingham 2002-04-09 19:31:03 UTC
Out of curiousity, what happens if you disable the kudzu service on startup?

Comment 4 Marco Pratesi 2002-04-10 09:38:30 UTC
It is already disabled... it is among the first things I disable
after a Red Hat installation, also to speed up the OS startup;
I launch it only from a root shell when really needed.
If you need further info, please ask me.

Comment 5 Mike A. Harris 2002-04-14 16:11:44 UTC
When mouse problems occur after configuration, it can be due to various
different issues.  One major issue which comes up, is a user not really
knowing how to properly configure the mouse in the first place, and then
guessing different settings until the right one is found.  While this
sometimes works for some mice, with other mice what happens is choosing
the wrong protocol, can end up confusing the actual hardware itself.
Further configuration even using the correct protocol, can end up not
working due to the hardware being messed up.

I have all logitech mice here, and all of them work perfectly with X when
configured properly.  I can use the mouseman protocol, however I use the
IMPS/2 protocol as it is pretty much the defacto standard protocol in use
now, and it works great with all my mice.

I've yet to run into any problems with mice that were not able to be
resolved by changing mouse protocols and physically rebooting and thus
hardware resetting the mouse hardware.

I consider this to be misconfiguration issue, and not an XFree86 mouse
driver bug.  Even though bugzilla is not a technical support forum, I
will offer the following suggestions:

Number one - disable GPM entirely.  XFree86 does not need GPM, and GPM
can in fact cause conflicts with XFree86.  Removing GPM out of the equation
allows X to use the mouse unhindered.  Once X is working, then one can
fiddle with GPM if one desires to use GPM.  If X works without GPM, and
does not work when GPM is used, it is NOT an X bug.

Configure your mouse as follows in /etc/X11/XF86Config-4

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Device" "/dev/mouse"
        Option      "Protocol" "IMPS/2"
        Option      "ZAxisMapping" "4 5"

Save the file, and physically reboot the computer.  This configuration
should work with almost all modern PS/2 and serial mice that are compatible
with the IMPS/2 protocol, which includes all modern Logitech devices. It
also should work I believe with most if not all USB pointing devices, only
the device line needs to be changed to point to the USB device, or else the
/dev/mouse symlink needs to be changed to point to the USB device.

It is very important after disabling GPM via ntsysv so it does not start
at boot, that you reboot the machine to ensure 100% that the hardware
is physically reset.

If it does not work after this, I strongly recommend trying each mouse
protocol one at a time, and rebooting the computer in between each attempt
to ensure the hardware is reset properly.

Comment 6 Marco Pratesi 2002-04-22 19:16:06 UTC
This mouse is driving me crazy!!!
The same mouse, with the same mouse configuration, works correcly
and lovely well on other two computers with RH 7.2 and RH 7.2.93,
both with and without gpm, and I remark that on the computer with RH 7.2
I am also using just the same video card!!!
Moreover, on the computer where it does not want to work,
I have no problems with an old, non Logitech mouse providing a wheel.
I should try on the same computer with other mouses, but I'm getting
convinced that this is a very weird problem and that it would be *very*
difficult to understand the causes; I'm becoming convinced that this problem
is really specific of *this* computer with *this* mouse... ARGH!!!

Comment 7 Mike A. Harris 2002-05-28 06:09:03 UTC
Closing bug WONTFIX as it seems hardware related.  Even if it turns out to
be a software bug, which I am doubting highly at this point, there is
practically zero chance that anyone can even look into it at all without
being able to reproduce it.

Your best bet at this point, is to join the xpert@xfree86.org mailing list,
and ask for help with this problem there.  Perhaps someone there knows what
the problem is, and if it is indeed a hardware problem, perhaps there is
a workaround you can use.

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