Re: gpm and X problem investigated
> In the recent past, there have been multiple (bug) reports about the behaviour
> of potato (& woody?) gpm in the presence of X (or vice versa, really). I've
> done some research, with these results:
> 1. On slink and probably before (because I don't remember things being
> differently), gpm did not default to be in repeater mode or even
> ask about that. In the X config, you would mention your real /dev/mouse
> and your real protocol.
> 2. On any->potato upgrades, the config file is not touched, and gpm and X
> continue to behave as before. In an upgraded potato system, X still
> needs your real /dev/mouse and your real protocol.
> 3. On new potato installs, gpm defaults to be in repeater mode, and to
> repeat in the ms3 protocol.
> 4. When gpm is in repeater mode, it does not release the mouse device
> when switching to X, but expects X to read data from /dev/gpmdata.
> So, in the current potato default install, IF you install gpm,
> X config must use /dev/gpmdata and ms protocol always, regardless
> of mouse type.
> 5. In the current potato install, IF you do NOT install gpm, X config
> needs your real /dev/mouse with your real protocol.
> 6. My personal experience shows that, with gpm repeating in the ms3
> protocol, the middle mouse button is very hard to get working in X, if
> at all. Also, movement data of the mouse appears to get lost, resulting
> in erratic and uncomfortable mouse behaviour.
> 7. The solution to the repeating problem in 6. is to default to
> repeating in the "raw" = "untranslated" protocol. Then, X config
> would need /dev/gpmdata always, but your real protocol.
> So, on a potato system, the X configuration may require three different
> settings, dependent on your personal history:
> real /dev/mouse + real protocol when upgraded from slink or before
> OR on new potato install without gpm
> /dev/gpmdata + ms protocol on "unmodified" new potato install w/gpm
> /dev/gpmdata + real protocol on "modified" new potato install w/gpm
> This situation seems highly undesirable to me, if only because this is not
> documented properly anywhere -- and even documenting the current situation in
> a way that is clear to the average user (i.e. M$Win convert) is a daunting
> Apart from changing nothing and leaving our users completely in the dark,
> there seem to be two options:
> a. Let gpm default to repeating in raw mode (to solve 6.), and add a very
> clear notice that X should be (re)configured with /dev/gpmdata but using
> the real protocol -- but when gpm is either stopped or removed/purged, that
> the X config should be changed again (!! I don't know any package that
> requires _another_ package to be _manually_ reconfigured on install/
> b. Let gpm default to not repeating at all, without needing any further
> documentation (AFAIK; I don't remember questions on gpm <-> X behaviour
> in slink).
> Obviously, b. is the right choice (IMHO ;-). Furthermore, a fix to this effect
> seems more than necessary to go into 2.2r1.
> Or... is there a flaw in my logic? Or is there some very important reason for
> gpm's current behaviour?
> Anne Bezemer
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
I had the same problems when using the new defaults (-R ms3 and Intellimouse
Another nasty thing is that if you use the task-selection interface gpm
is not installed by default and there is no way to add it manually to the
So if you configure X for MouseSystem on /dev/gpmdata, as I have always
done on my installations, you have a non working X system. The same happens
if you choose "Logitech Intellimouse or GPM Repeater" in anXious, because
gpm is missing anyway.
I suggest that in the future we choose a third (and better) option:
1) install gpm by default or even better add it to the base system
since it is very useful also in text mode
2) use the default gpm repeater type (msc). It is compatible with
the old behavior of slink and gpm, and works without problems.
The default gpm repeater type is `msc' an not `raw'. Setting it
to raw would force the user to configure it also in XF86config,
while with msc it could be configured automatically (see next
3) in new installlation don't ask for X mouse configuration and
use by default MouseSystem on /dev/gpmdata, after displaying a
note to the user explaining the relationships between gpm and X.
This has the advantage that the user must configure the mouse
only in one place, even if later he wants to change the mouse
model or port. This is a big win expecially for novices, while
the experienced users always know how to change settings.
I have been using this setup for years and I have always got a working X
at the first try, provided I had configured correctly gpm and choosen the
I know that this is a change from previous configuration defaults but if
we document it clearly and handle the transition correctly we will greatly
simplify the X installation in woody.
Massimo Dal Zotto
| Massimo Dal Zotto email: firstname.lastname@example.org |
| Via Marconi, 141 phone: ++39-0461534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: see my www home page |
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org