Bug 76713 - RFE: Configure two mouses (e.g., USB+laptop internal ps/2) for gpm
Summary: RFE: Configure two mouses (e.g., USB+laptop internal ps/2) for gpm
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-mouse
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
URL:
Whiteboard:
Depends On: 84310
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-25 09:46 UTC by diego.santacruz
Modified: 2008-05-01 15:38 UTC (History)
0 users

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


Attachments (Terms of Use)

Description diego.santacruz 2002-10-25 09:46:57 UTC
Description of Problem:

The RedHat 8.0 installer will always configure the USB mouse for X, so that if
one is plugged it becomes immediately available. However this is not done for
gpm, and one has to poke around config files so that gpm is capable of accessing
the USB and PS/2 internal mouse of a laptop.

redhat-config-mouse should provide a checkbox "Configure seconday USB mouse", or
something of the like, that will add a USB mouse to XFree and gpm configurations.

I had to configure the secondary USB mouse by adding the line

OPTIONS="-t imps2 -m /dev/input/mice -M"

to /etc/sysconfig/mouse so that both the redhat-mouse-config configured mouse
(PS/2 in my case) and the USB mouse are available in gpm.

Version-Release number of selected component (if applicable):
redhat-config-mouse-1.0.1-2
gpm-1.19.3-23

Comment 1 diego.santacruz 2002-10-28 07:59:08 UTC
Actually, configuring two mice with gpm does not work correctly with X:
the ps2 mouse (laptop internal) was jumping all over the place in X, stopping
gpm corrected the problem. I suspect that the problem is that gpm activates
the repeater feature when the -M option is used to configure more than one
mouse and thus it does not leave the mouse alone when under X, as it does
normally.

Why does (according to man page) the -M option automatically activate
the repeater feature?

Comment 2 Brent Fox 2002-10-30 22:04:03 UTC
That must be a hardware specific problem.  I've done some work to
redhat-config-mouse set up /etc/sysconfig/mouse like you suggested and both mice
now work with gpm.  X now works fine for me with USB and ps/2 mice at the same
time even with gpm running at the same time.

Incidentally, I've also fixed it where serial mice and USB mice work at the same
time too.  I don't know what would happen if you had ps/2 and serial, but not
USB, nor do I know what would happend if you had all three, but that seems a
little strange.  Mostly I'm interested in the laptop situation where you have
the built in ps/2 mouse and then a USB mouse.  I think the latest version of
redhat-config-mouse should make this work now, but it could use some testing.

redhat-config-mouse-1.0.2-1 should appear in Rawhide in the next day or so. 
Thanks for your report.

Comment 3 diego.santacruz 2002-11-01 11:08:51 UTC
I just upgraded to redhat-config-mouse-1.0.2-1 from rawhide and nothing seems to
be changed. Same interface, no option to config secondary USB mouse. The written
/etc/sysconfig/mouse does not include a second mouse for gpm. Are you sure the
changes you say are included in 1.0.2-1 ?

Besides that, I confirm that when I configure an external USB mouse (Logitech
Mouseman wheel) and the laptop's internal PS/2 (pointing stick + touchpad,
configured as simple PS/2 device in BIOS), the PS/2 device goes all crazy under
X. If I stop gpm it is OK again. However, in console mode both pointing devices
work as expected.

Comment 4 Brent Fox 2003-02-13 20:34:27 UTC
Yes, running gpm and X at the same time can cause the mouse to go bonkers in X
sometimes.

The line to allow the USB mouse in /etc/sysconfig/mouse is:
OPTIONS="-t imps2 -m /dev/input/mice -M"

The XF86Config file should be configured to allow a USB mouse to work if you
just plug it in.  What you want to do is select the PS/2 mouse in
redhat-config-mouse and that should allow both mice to work in X.  Does that not
work for you?  

You might want to upgrade to redhat-config-mouse-1.0.4-4 in Rawhide.

Comment 5 diego.santacruz 2003-02-14 09:30:35 UTC
The problem is not the X11 config. The problem is the gpm config, and that can
be summarized as follows:

1) mouse-config should not only configure the USB mouse under X in addition to
whatever mouse is selected, but also configure the USB as an additional mouse in
gpm, provided the below problem with gpm is solved.

2) When multiple mice are configured in gpm (using the -M option) gpm's repeater
mode (-R option) is automatically activated. This should not be so. When the
repeater mode is enabled gpm will continue to read mouse activity even when in
graphical mode (i.e., X active). Thus X and gpm compete for mouse access,
causing the mouse to go bonkers. In short gpm should be modified so that -M does
not imply -R.

Comment 6 Brent Fox 2003-02-18 21:46:35 UTC
Ok, due to problems while using gpm in repeater mode and running X at the same
time, I'm taking out the code in redhat-config-mouse that writes 'OPTIONS="-t
imps2 -m /dev/input/mice -M"' to /etc/sysconfig/mouse.

This means that only one mouse at a time will work in console mode, yet both
mice should work in X.  I agree that this isn't perfect, but I'm willing to be
that the number of people who want multiple mice configured for console mode is
pretty small.  This change will be in redhat-config-mouse-1.0.5-1.

If you like, please file a separate bug against gpm about the repeater mode. 
Maybe there is a way for gpm to handle multiple mice without having to use
repeater mode.



Comment 7 diego.santacruz 2003-02-19 13:12:08 UTC
I already reported the bug against gpm, just after I made the previous comment,
and marked as a dependency of this one. bug #84310

Comment 8 Brent Fox 2003-05-25 14:29:34 UTC
There is a stack of 64 bugs that have been in Modified state for a long period
of time.  I am closing these as Rawhide now.  If you find that the issue is not
fixed, please reopen this report.


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