Serial mouse

[skiwarz]

Hello everyone,
I'm having trouble getting a serial mouse to work. I believe the problem currently lies at the kernel level, but I'm not certain.
Anywho, I'm using an Athlon XP 3200+ machine running the 6.1.28 kernel. I have most of the kernel options I could find enabled. Here's my config: http://0x0.st/HTLY.txt
The serial port is enabled in my BIOS.
Yet, when I run

Code: Select all

tail -f /dev/ttyS0

tail just sits there and doesn't output anything. The other ttyS{1,3} give an Input/Output error. If the kernel were configured correctly, I SHOULD be getting some output here, right?
Anyone have any advice on getting this to work?

[NeddySeagoon]

skiwarz,

Code: Select all

TAIL(1)                          User Commands                         TAIL(1)

NAME
       tail - output the last part of files

SYNOPSIS
       tail [OPTION]... [FILE]...

DESCRIPTION
       Print  the  last  10  lines of each FILE ... 

Tail may never get any newline characters, so would output nothing.
The mouse generates random jibberish.

Code: Select all

cat /dev/ttyS0

is the traditional test as cat works with characters.

Beware that the random "jibberish" can trash your console settings.
Enter the reset command to sort out the mess. Don't look at what is echoed on the screen when you enter reset, it may not be a pretty sight.

[pietinger]

What happens if you enable this in your kernel ?

Code: Select all

# CONFIG_INPUT_MOUSEDEV_PSAUX is not set

(yes, I know, it is a serial mouse and not a ps2-mouse but in some cases it helps)

[skiwarz]

skiwarz,
Tail may never get any newline characters, so would output nothing.
The mouse generates random jibberish.

Code: Select all

cat /dev/ttyS0

is the traditional test as cat works with characters.

I tried this but get the same result. On ONE out of the several dozen attempts so far, I got about 10 characters of jibberish, then nothing. Not sure if that's notable.

What happens if you enable this in your kernel ?

Code: Select all

# CONFIG_INPUT_MOUSEDEV_PSAUX is not set

(yes, I know, it is a serial mouse and not a ps2-mouse but in some cases it helps)

I tried this too but still no change.

For most of the serial drivers, enabling in menuconfig opens up a secondary option for "UART console support." Is that relevant, or is that specifically for attaching a monitor remotely over serial or something? I don't currently have those enabled.

[skiwarz]

I'm still not certain, but I'm beginning to suspect it may either be a BIOS issue or a physical port issue. I booted from a live cd of a *different* distro, and I still get no output. Using the exact same live cd on a different computer (albeit with a 64-bit architecture) yields output from /dev/ttyS0.

[pingtoo]

May be https://wiki.alpinelinux.org/wiki/Serial_mouse have something can help.

[skiwarz]

I bought a "null modem" cable which let me connect two PCs together over serial. The serial port on the machine in question actually works just fine, it turns out. I can cat /dev/ttyS0 and read text that I send from different PC.

Knowing that, and the fact that my serial mouse works on other computers, it points to a configuration issue. But if my two computers are able to communicate with each other, then their serial settings are identical. So how can it be a configuration error??? This is further confounded by the fact that two different OSs (gentoo being one) can't read anything from this mouse.

[wjb]

A serial mouse will need a serial port configured to match it's characteristics - baud rate, stop bits, parity, handshakes. Otherwise the bits from the mouse won't make sense to the serial port. You can usually work out the mouse experimentally by fiddling with the port settings till something sensible emerges.

We used to use serial mice to get pointer input round the back of the operating system, allowing us to have multiple independent pointers on the same window. We painted the fake pointers in the window. Long time ago, though.

[NeddySeagoon]

skiwarz,

Install minicom.and let it control /dev/ttyS0.

There are lots of settings to play with. 9600n1 and no flow control is a good place to start.
In the days when the original serial port was common, 9600 baud was as fast is it it could go without missing characters.
The UART did not have a buffer then.

When you get the post settings right in minicom, you will get more output from moving the mouse that with any other setting.

While this is interesting, it should not be required because whatever drives the port for the serial mouse should get the port setup right anyway.

[skiwarz]

skiwarz,

Install minicom.and let it control /dev/ttyS0.

There are lots of settings to play with. 9600n1 and no flow control is a good place to start.
In the days when the original serial port was common, 9600 baud was as fast is it it could go without missing characters.
The UART did not have a buffer then.

When you get the post settings right in minicom, you will get more output from moving the mouse that with any other setting.

While this is interesting, it should not be required because whatever drives the port for the serial mouse should get the port setup right anyway.

Thanks! I'll give that a shot. I managed to get it working last night, but shut down and went to bed before I figured out exactly what the issue was. There was a driver for an I/O chip I didn't have, among other things. I'll post the solution probably later today in case others stumble on this...

[skiwarz]

I did two things to fix this:
1. Added (built-in) the kernel driver for a "Super I/O" chip my motherboard has. In my case the CONFIG_W83627HF_WDT and CONFIG_SENSORS_W83627HF. I don't know if this actually mattered, but it matched the chip soldered to my motherboard.
2. Ran the following command:

Code: Select all

stty -F /dev/ttyS0 1200 cs7 -ignbrk ignpar -icrnl -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

I stumbled across this through trial-and-error. I'm still hazy on the details, but the way I understand it, "setserial" will configure the actual UART, while "stty" will configure the terminal/console interpretation of the symbols (aka give you readable output). So, it's very likely I was actually getting perfectly usable data from my mouse despite not reading anything from

Code: Select all

cat /dev/ttyS0

I'll know for sure once I get X to actually use my mouse.

Speaking of which, the three options that I was able to find for getting a serial mouse to work on X are:
1. Libinput, which I don't think actually supports serial mice at all.
2. evdev, which according to the arch wiki and the link pingtoo posted requires the "inputattach" program. I'll have to find that somewhere and give it a shot.
3. xf86-input-mouse, which isn't in the portage tree anymore (I assume it was historically).

Creating the following in xorg.conf

Code: Select all

Section "InputDevice"
	Identifier "serialmouse"
	Driver "evdev"
	Option "Protocol" "MouseMan"
	Option "Device" "/dev/ttyS0"
	Option "CorePointer"
	Option "ZAxisMapping" "4 5"
	EndSection

just gives this in my Xorg.0.log:

Code: Select all

(II) Using input driver "evdev" for "serialmouse"
(EE) systemd-logind: failed to take device /dev/ttyS0: No such device
(**) Option "CorePointer" "on"
(**) serialmouse: always reports core events
(**) evdev: serialmouse: Device: "/dev/ttyS0"
(EE) evdev: serialmouse: Unable to query fd: Inappropriate ioctl for device
(EE) PreInit returned 2 for "serialmouse"
(III) UnloadModule: "evdev"

[skiwarz]

I downloaded the source for the linuxconsole package (https://sourceforge.net/projects/linuxconsole/) which contains that inputattach program. Built and ran it. It basically made an "input-layer" device node in /dev/input/ which I then used in my xorg.conf instead of /dev/ttyS0. Now the mouse works.

Is there a gentoo-organic way to make input-layer devices like that? I hate using out-of-tree packages, and it seems like such a simple thing to do. Mknod comes to mind, but as far as I know that just makes a file for a major:minor device description, which I wouldn't have in this case.

edit: After further analysis, the inputattach command takes care of all the configuration stty did from my earlier post. Libinput can also now handle the mouse in xorg, once inputattach is running. So, after a fresh reboot, all I need to do is run inputattach and start X (just using the default xorg.conf)

[logrusx]

I downloaded the source for the linuxconsole package (https://sourceforge.net/projects/linuxconsole/) which contains that inputattach program. Built and ran it. It basically made an "input-layer" device node in /dev/input/ which I then used in my xorg.conf instead of /dev/ttyS0. Now the mouse works.

Is there a gentoo-organic way to make input-layer devices like that? I hate using out-of-tree packages, and it seems like such a simple thing to do. Mknod comes to mind, but as far as I know that just makes a file for a major:minor device description, which I wouldn't have in this case.

Package seems pretty simple, should be straight forward to write an ebuild. I may write one for you later today.

Best Regards,
Georgi

[wjb]

For the earlier part of this thread, this is a nice description of the serial mouse interface: serial-mice

[logrusx]

This is the Gentoo way:

sys-apps/linuxconsoletools/linuxconsoletools-1.8.1.ebuild

Code: Select all

# Copyright 2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=8

DESCRIPTION="Utilities to test and configure joysticks, connect legacy devices to the kernel's input subsystem"
HOMEPAGE="https://sourceforge.net/projects/linuxconsole"
SRC_URI="mirror://sourceforge/${PN}-${PV}.tar.bz2"

LICENSE=""
SLOT="0"
KEYWORDS="~amd64"

DEPEND="media-libs/libsdl
        || (    sys-devel/gcc
                sys-devel/clang )"
RDEPEND="${DEPEND}"
BDEPEND=""

src_compile() {
    emake SYSTEMD_SUPPORT=1
}

src_install() {
    emake install PREFIX=${EPREFIX}/usr DESTDIR=${D}
}

I'm curious if this works on an OpenRC system. I fi doesn't, simply remove src_compile function.

Best Regards,
Georgi

[NeddySeagoon]

skiwarz,

Being old and cynical ... with a long memory, I still use

3. xf86-input-mouse,

because my system has a static /dev and no autoblackmagic at all.
I even have a real xorg.conf.

It you dig xf86-input-mouse out of the git history, you will end up with something like xf86-input-mouse-1.9.3-r1.ebuild

I shouldn't encourage you :)

[stefan11111]

I am surprised that serial is still a thing. I haven't seen a serial port for quite some time and have never seen anything that plugs into one.

skiwarz,

Being old and cynical ... with a long memory, I still use

3. xf86-input-mouse,

because my system has a static /dev and no autoblackmagic at all.
I even have a real xorg.conf.

It you dig xf86-input-mouse out of the git history, you will end up with something like xf86-input-mouse-1.9.3-r1.ebuild

I shouldn't encourage you

The difference between your "old" way and the "new" systemd way is that yours works and doesn't break.

[skiwarz]

skiwarz,

Being old and cynical ... with a long memory, I still use

3. xf86-input-mouse,

because my system has a static /dev and no autoblackmagic at all.
I even have a real xorg.conf.

It you dig xf86-input-mouse out of the git history, you will end up with something like xf86-input-mouse-1.9.3-r1.ebuild

I shouldn't encourage you

Being still relatively young and optimistic, I have a couple questions...
1. From where does your ebuild get the distfiles? The newest I see in the portage tree is 1.2.3
2. With a static /dev, how do you handle something like plugging in a usb drive?
As time goes on, I'm finding bloat and automation more and more distasteful...

I am surprised that serial is still a thing. I haven't seen a serial port for quite some time and have never seen anything that plugs into one.

I was feeling nostalgic and recently bought an old mid-90s PC. Then I figured a serial mouse would match nicely with it and ought one of those too. Then I started thinking "what else can I connect this to?" and now I'm here

[skiwarz]

I'm curious if this works on an OpenRC system. I fi doesn't, simply remove src_compile function.

Had to make a few modifications, but the src_compile works on openrc.

Code: Select all

# Copyright 2023 Gentoo Authors 
# Distributed under the terms of the GNU General Public License v2 

EAPI=8 

DESCRIPTION="Utilities to test and configure joysticks, connect legacy devices to the kernel's input subsystem" 
HOMEPAGE="https://sourceforge.net/projects/linuxconsole" 
SRC_URI="mirror://sourceforge/${PN}-${PV}.tar.bz2" 

LICENSE="" 
SLOT="0" 
KEYWORDS="~amd64 x86" 

DEPEND="media-libs/libsdl2 
        || (    sys-devel/gcc 
                sys-devel/clang )" 
RDEPEND="${DEPEND}" 
BDEPEND="" 

src_compile() { 
    emake SYSTEMD_SUPPORT=1 
} 

src_install() { 
	default
#    emake install PREFIX=${EPREFIX}/usr DESTDIR=${D} 
} 

[stefan11111]

Being still relatively young and optimistic, I have a couple questions...

I would also call myself young. Optimistic, not so much. I have eyes and see where things are headed.

1. From where does your ebuild get the distfiles? The newest I see in the portage tree is 1.2.3

Neddy keeps old distfiles here:
http://bloodnoc.org/~roy/olde-distfiles/

2. With a static /dev, how do you handle something like plugging in a usb drive?
As time goes on, I'm finding bloat and automation more and more distasteful...

You have all /dev/sd* nodes you can use always there.
If you plug in a usb drive, you use it as normal.
One benefit is that on systems like mine with more that 1 internal drive, /dev/sda is always the same drive.

[NeddySeagoon]

skiwarz,

1. From where does your ebuild get the distfiles? The newest I see in the portage tree is 1.2.3

All my distfiles since mid 2006, about 370G, are online.
I have another 21 months worth to upload too. Its updated sporadically, to discourage its everyday use as a distfiles mirror.

There is a smattering of older distfiles to suppprt Historical Gentoo too.

2. With a static /dev, how do you handle something like plugging in a usb drive?

You use mknod to populate /dev. /dev is on the root filesystem, not provided by DEVTMPFS in the kernel. Being on root, nodes do not come and go.

Code: Select all

$ ls /dev/sda* -l
brw-rw---- 1 root disk 8, 0 Sep 30  2021 /dev/sda
brw-rw---- 1 root disk 8, 1 Sep 12  2021 /dev/sda1
brw-rw---- 1 root disk 8, 2 Sep 12  2021 /dev/sda2
brw-rw---- 1 root disk 8, 3 Sep 30  2021 /dev/sda3

The system was new about Sep 12 2021, but its been rebooted a few times since.

This 10 year old wiki page provides an outline.
Static /dev and no autoblackmagic has got more difficult over the years but it works for me on my main desktop.

I support it, post in Unsupported Software, and I'm aware of a few users too.

[NeddySeagoon]

stefan11111,

One benefit is that on systems like mine with more that 1 internal drive, /dev/sda is always the same drive.

That's not correct. /dev entries are a lookup table betwen the device names and the kernel major,minor device numbers.

Code: Select all

$ ls /dev/sda* -l
brw-rw---- 1 root disk 8, 0 Sep 30  2021 /dev/sda 

There is no hard and fast logic behind what userspace calls /dev/sda and the kernel calls 8,0

The first SCSI drive enumerated will be 8,0 to the kernel and /dev/sda to userspace. It's always been that way.

[stefan11111]

There is no hard and fast logic behind what userspace calls /dev/sda and the kernel calls 8,0

The first SCSI drive enumerated will be 8,0 to the kernel and /dev/sda to userspace. It's always been that way.

Back when I was using udev, /dev/sda and /dev/sdb would get swapped every couple boots.
About 4/5 time /dev/sda would be my ssd and 1/5 times it would be my hdd. Who knows what might have happened if I added more drives.
No idea if it was udev's fault, the kernel's fault or something else, but I've never had to deal with that again since I started using a static /dev.

[eccerr0r]

plug and pray serial (rs232) mice are not...they have to be probed.

The ultimate hardware compatibility test is still "cat /dev/ttyS0" which should return characters as you push buttons or move the mouse. IIRC common mice are only running at 1200 baud and of two dominant protocols ("microsoft" or "pc-systems" again IIRC, remember there are a lot of standards to choose from!) - and there really isn't a perfect way to probe the protocol without someone moving the mouse.

I threw all my serial mice away pretty much. USB is so much better, not because of the complexity but due to the higher update rate/accuracy of movement... Much more responsive. Also I don't know of any optical RS232 mice, they were all optomechanical mice using rotary encoders?

[logrusx]

Had to make a few modifications

That modification to src_install you've made is not correct. This way it installs in /usr/local, which is not the right location for something system managed. AFAR, /usr/local is for things put manually by the sysadmin.

Another thing is it's totally unnecessary to have this function if you just call default. It's called by default, that's why it's called default

Best Regards,
Georgi