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
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?
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com