Date: Mon, 1 Dec 2003 16:27:15 +0200 From: Ion-Mihai Tetcu <itetcu@apropo.ro> To: Laurent Demaret <laurent.demaret@free.fr> Cc: freebsd-newbies@freebsd.org Subject: Re: Console ps2 mouse behavior control (was : Re: test) Message-ID: <20031201162715.44b8288a.itetcu@apropo.ro> In-Reply-To: <02D096B0-2371-11D8-A803-000393A95684@free.fr> References: <20031130153011.3bc2115d.itetcu@apropo.ro> <02D096B0-2371-11D8-A803-000393A95684@free.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Nov 2003 21:08:49 +0100
Laurent Demaret <laurent.demaret@free.fr> wrote:
>=20
> Le dimanche, 30 nov 2003, =E0 14:30 Europe/Paris, Ion-Mihai Tetcu a =E9cr=
it=20
> :
>=20
> > it# cat /var/run/dmesg.boot | grep psm
> No such file in /var/run/ ...
huh ?
> > -i info Print specified information and quit.
> says one argument is missing and print moused --help.
>=20
> Too much newbie to know wich argument is missing, just tried stupid=20
> things like "#moused -i -p psm0" unsuccessfully
>
> Ran the moused with psm0 port and PS/2 protocol : each move of the=20
> mouse inverse video of the text in the console, put it in command line=20
> and hit return (or looks like it did) : exactly the behavior I want to=20
> stop :-((
>=20
> No protocol gived me a quiet mouse, the best I can get I still need to=20
> make very very slow moves otherwise my pointer refuges on the left side=20
> of the screen, put text at command line and validate it.
So:
it# moused -i
moused: option requires an argument -- i
usage: moused [-DRcdfs] [-I file] [-F rate] [-r resolution] [-S baudrate]
[-a X [,Y]] [-C threshold] [-m N=3DM] [-w N] [-z N]
[-t <mousetype>] [-3 [-E timeout]] -p <port>
moused [-d] -i <port|if|type|model|all> -p <port>
The first line tell that the option i requires an argumet. The -
prefixed are options, the things after them untill the next options are
arguments.
The last line tells us the sintax we are looking for.
The squera brackets around -d "[-d]" tells this option is not mandatory
(and in fact stands for debbug). Between the angular bracketsthere is a
list of possible arguments; being separated by the "|" caracter we find
out that they are alternative arguments, e.g. only one can be use at a
time. So lets try:
it# moused -i all -p psm0
moused: unable to open psm0: No such file or directory
Well:
it# pwd
/usr/home/itetcu
so I'm now in my home directory; as psm0 is in the /dev - devices
directory is clear that I should:
it# moused -i all -p /dev/psm0
moused: unable to open /dev/psm0: Device busy
Hmm. I'm in X, I have an working mouse so that is normal, as another
instance of moused has binded to that device.
If I want to use that I should first try to kill moused. One way to do
this is:
it# ps ax | grep moused
499 ?? Ss 0:47.25 /usr/sbin/moused -z 4 -p /dev/psm0 -t auto
9473 p2 R+ 0:00.00 grep moused
ps gives me the processis running. The first colum is the PID - proccess
id. In order to free the psm0 device I do now:
#kill -3 499
which will send a QUIT signal to moused (of course, this will leave me
without a working mouse).
Now the best approch to resolve your problem will be:
1. RTFM - Read The F(endly) Man page by=20
it# man moused
2. Disable all the mouse-related lines in /etc/rc.conf
3. Either reboot or do the ps ... kill sequence
4. Do the moused -i all -p /dev/psm0 - this will tell you how the system
"sees" your mouse.
5. Reread the moused man page.
6. Try to start the moused manually, playing with the options untill you
have a working mouse in the console; first it should work OK - e.g. not
jumping, "autoclicking", etc. in the console, after which you could
start paying with wheel related options. Probably you should try -t
options intellimouse and mousesystems.
The -d option will result in a lot of debbug information (that problably
no one but those who know the code of moused will completly understand -
but it can give you hints of what it is happening). There is on other
option that you can set in the kernel to debug psm, but I don't think
it's the case to use it.
Also note that, if you use 5.1 and you have some AWARD BIOS version and
you boot with ACPI enabled (default) the problem could be commming from
here. Try booting without ACPI first and see if that's the case. There is
an open PR on this issue ( namely:
http://www.freebsd.org/cgi/query-pr.cgi?pr=3Di386/55473 ) and some ongoing
work on it.
--=20
IOnut
Unregistered ;) FreeBSD user
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031201162715.44b8288a.itetcu>