On Sat, Jul 20, 2002 at 11:08:58AM -0500, Jamin W. Collins wrote:
| On Sat, 20 Jul 2002 10:51:12 -0500
| Derrick 'dman' Hudson <dman@dman.ddts.net> wrote:
|
| > The procedure involves knowing what the user wants. Step 1 of the
| > procedure is to determine which device node the mouse is hooked into.
| > Step 2 is to determine what protocol the mouse uses. Step 3 is to
| > determine whether or not to run gpm. It goes like this :
| >
| > 1) point gpm at the mouse device (eg /dev/psaux but depends on
| > your hardware)
| > 2) tell gpm the correct protocol to use
| > 3) set it up in "raw" repeat mode (this _should_ be the default,
| > but I don't know if it is)
|
| This is not necessary. It is but _one_ way to solve the problem. It is
| possible to have gpm and X both natively controlling the mouse so long as
| you tell gpm _not_ to repeat. Perhaps this would be a safer default.
You can't have 2 applications reading from a device file. Trying to
do that creates a race condition and each application only gets part
of the data stream. Exactly which part and how much each application
gets is undefined (the results of a race condition are always
undefined).
A while ago I created a daemon to read SMDR log data (from a Lucent
phone switch) from the serial port. When I was testing the
functionality of the system (as we deployed it) I used the mouse to
verify that my program was actually receiving data from the port.
However I had to start gpm to initialize the mouse before I would get
any data. I then turned off gpm and we hooked in the real data source
and everything was cool. Then one day it stopped working correctly.
Whenever the daemon would get data that didn't match the format it was
expecting it would record that in syslog. The problem was that the
beginning of every line was missing. It turned out that the system
was rebooted one day, and I/we had totally forgotten about gpm. It
started during the init process, and then it stole some of the data
from my daemon. Stopping gpm solved the problem. (I then changed the
config so it couldn't do that again)
| > | The problem is that it's not just that. There are a whole series of
| > | things that don't work unless you know the "tricks". Tricks
| > | like:
| >
| > | Edit source list by hand
| >
| > This is only necessary if you don't want "stable". (eg when
| > installing a non-stable branch, which isn't a default anyways)
|
| Not quite true. The testing branch up until it was frozen would create a
| sources.list file with testing references.
Testing didn't _have_ an installer, until it was time to test it, and
that definitely wasn't "stable". You don't test a new installer
unless you _really_ know what you are doing (and _really_ plan on
taking careful notes and submitting proper bug reports).
| For some reason, when testing
| was frozen (or just before), it started creating sources.list files that
| referenced stable instead.
As it should, since if it is frozen then the release is imminent and
the release is "stable".
| Thus, introducing a somewhat confusing bug that no one saw a need to
| fix.
Actually, I think everyone saw a need to fix it. However the fix was
to make that imminent release actually occur.
-D
--
Do not pay attention to every word people say,
or you may hear your servant cursing you --
for you know in your heart
that many times you yourself have cursed others.
Ecclesiastes 7:21-22
http://dman.ddts.net/~dman/
Attachment:
pgpIGx9eS_tHu.pgp
Description: PGP signature