Hi:

Up to now I had slack 12.0 running with my PS/2 mouse plugged into the PS/2 female connector on the machine rear panel. I now had to use a different mouse, which plugs into one of the COMx (so called under MS-DOS) port connectors. In the rear panel I have only one of these DB9 connectors, and it is directly attached to the motherboard.

First, I guess I should know if the connector is COM1/COM3 or COM2/COM4. In the procedure I followed I assumed it is COM1/COM3. However, previous to any guess work, I thought if I rebooted, the O.S. would automatically rescan the hardware and set things so that I could have the serial mouse up and running. Wrong. This was not the case.

Then I ran pkgtool>Setup and selected Modem-device. It first allows me to choose from ttyS0, ..., ttyS3. I chose ttyS0 to leave room for the serial mouse in ttyS1, however not knowing the mapping between the connectors in the rear panel to the set {ttyS0,...,ttyS3}. But now by pressing Enter, the program does not ask for the mouse (as I know it did when at slack installation time). Instead, it enters a screen with the following options:
(a) Install packages from the current directory.
(b) Install packages from some other directory.
(c) Install packages from floppy disks.
(d) Choose slackware installation scripts to run again.

And this list of options is a new source of perplexity. I could have the slackware disk no. 1 in the CD-ROM drive, already mounted in say, directory /mnt/foo, be already in /mnt/foo when i run pkgtool and use option (a). That is what I did but nothing changed with respect to the mouse: I still had no mouse in the GUI. Another thing: should I use option (d) also?

I must say all this, and specially that list quoted above, is very confusing. But if its I who is introducing confusion here, then I beg you to tell me which is the correct procedure to bring the serial mouse to life after the O.S. got used to the PS/2 mouse.

Also, once and for all, I would like to be proficient in the use of pkgtool>Setup.

kernel 2.6.21.5, slackware 12.0

The Serial DB9 Port from past experiences I've had has anyways been assigned by the BIOS to COM port 3 as a default, though I was strictly using it as a Modem port.

Check your BIOS and see what the settings are and see if perhaps the GPM tool can setup your mouse correctly. I know usually the default /dev/mouse is preset using GPM which runs through a list of supported mice and should setup the port it's at automatically, usually.

Thank you. My BIOS does not have options in connection with the serial ports. I quote from post #1:Even more: the first time I ran pkgtool>Setup, it did enter the window where one can choose among PS/2, Microsoft serial two buttons, on so on. But never more. Why is that?

When you run pkgtool and go to setup you should have the "mouse" option, this will let you run the mouse setup script. You could also run it directly from the command

# /var/log/setup/setup.mouse

If you choose one of the serial mice from the list then you will be asked which COM port your mouse is on.

This script only seems to be installed if you have the gpm package installed though, but the symlink it creates may help programs other than gpm find your mouse.

I ran setup.mouse and, in the case of the PS/2 mouse, it worked. But not so for the serial one. I may be wrong with the COM number. Is there not, in linux, a program of the following type: I run it with the mouse plugged into the first connector, move the mouse and the program may say: "I see you are moving your mouse through ttyS2". I lack DOS which could help.

Couldn't you use dmesg to get more information?

Markus

I thought about that. Yes, it's what I will do as a first step.

`cat /dev/ttySX` should show noise in the terminal if you then move the mouse and have the right device number (for X). In my experience, ttyS0(COM1) is usually the right one -the COM ports may be labled on the case.

I have the both mice (ps2 and serial) plugged in and the ps2 working. Doing
cat /dev/input/mouse1
I get garbage in the screen when moving the ps2. But
cat /dev/input/mouse0
does nothing. I now remember I never used a serial mouse in this machine. Maybe the hardware is broken.

EDIT: anyway, who programs the UART?

Rectification: this machine was perhaps not used with a serial mouse but indeed I made use of the serial port for comunication with certain type of device.

The serial mouse would probably not be detected by /dev/input, so the only way to access it would be through the serial port device which would probably be /dev/ttyS0 if it is the serial port built into the motherboard. Try cat /dev/ttyS0 or cat /dev/ttyS1 to see if you get output from either of them.

1 members found this post helpful.

af7567 is right.

1 members found this post helpful.

I tried with /dev/ttyS0, ttyS1 but I do not get output when moving the mouse. I used the serial port in this machine to communicate with a single board computer, I remember well, and it worked. Maybe its UART was left programed in a way that is wrong for the mouse and the registers are written to disk to program it the same way at boot time.

You could also try /dev/ttyS2 and /dev/ttyS3.. or any other /dev/ttyS?? which can be opened.

# cat /proc/tty/driver/serial

This might show you a list of the detected serial ports on your PC, at least it does for me but I am using slackware 14.

1 members found this post helpful.

Somebody, looking towards the outside world, is seeing an UART at 0x3f8, corresponding to /dev/ttyS0, but I'm afraid the UART does not see the mouse. For me, it's a case of the 16550 UART not been properly initialized.

If only I had my old DOS I could write a very short program to help me diagnose, but I can only install it at tiny hard disks, and mine are >= 10G. To do this kind of tests I've always used assembler. And I would be force to revise the little I learn, time ago, about as and other linux assemblers. Plus, it would have to be inline assembler in a high level language program, or an assembler routine call within the high level program. I prefer trying other ways before meddling with assembler routines.