Serial mouse driver

You’re right. It’s also in the file kernel in /boot/home/config/settings/kernel/drivers directory.
I’d think that the option was disabled by default but it’s not. Good catch!

#serial_debug_output false
	# Disables serial debug output, which is enabled by default

So, yes better disable it before testing.


Thanks to all of you, I’ll try again when I return to my old home. I’ll let you know!

It is disabled by default only in releases. In nightly builds a lot of debugging helps are enabled at the cost of making the system slower. Don’t use nightly builds unless you really need to :slight_smile:

Actually IIRC it won’t be published by the driver if it’s used for serial debugging, I recall I added checks in the driver for the kernel and boot settings.

Maybe it could publish all the serial devices but have them disabled by default, so people would only need to enable the correct one in the input prefs?
And then after all input devices have been probed, only try to find a serial mouse if no other device is found…

1 Like

So I managed to go home this morning for 10 minutes, I disabled the serial debug option in /boot/home/config/settings/kernel/drivers and rebooted, but it seems it doesn’t work. Later today I’ll try on the second machine. (I forgot to mention that obviously serial port is enabled in bios settings)

So, I tried on a legacy pc, the syslog still say

KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/ports/usb_serial
KERN: e[32mpc_serial:e[0m Generic 16550 Serial Port added
KERN: e[32mpc_serial:e[0m scanning PCI bus (alt)…
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/ports/pc_serial
KERN: AddOnManager::_RegisterAddOn(): InitCheck() in “/boot/home/config/non-packaged/add-ons/input_server/devices/serial_mouse” returned General system error
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/input/wacom
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/input/usb_hid

serial mouse don’t work in haiku.
I’ll open a ticket

Following an idea presented me by “bipolar” on the bug tracker, I decided to try writing a simple app in python which uses the serial port, but when I try to open /dev/ports/pc_serial0 python collapse:

>>> import serial
>>> ser = serial.Serial(’/dev/ports/pc_serial0’)
Traceback (most recent call last):
File “”, line 1, in
File “/packages/python-2.7.18-2/.self/non-packaged/lib/python2.7/site-packages/serial/”, line 244, in init
File “/packages/python-2.7.18-2/.self/non-packaged/lib/python2.7/site-packages/serial/”, line 344, in open
File “/packages/python-2.7.18-2/.self/non-packaged/lib/python2.7/site-packages/serial/”, line 677, in _reset_input_buffer
termios.tcflush(self.fd, termios.TCIFLUSH)
termios.error: (-2147478783, ‘Bad address’)

is it normal?
the serial debug option in kernel configuration is disabled and I remove the serial_mouse driver from addons
Am I missing something?

Fist, to check the small things : do you have a real serial port in this computer, or it is through that usb-serial adapter ? In the later case, the name maybe would no be serial0 .

If that was the case, the code would fail earlier.

I think the serial driver just doesn’t support the TCIFLUSH command. That should not be a problem, the worst that can happen is you get a few bytes in your first read of the serial port that may be old and stuck in a hardware buffer for a while because no one was reading the serial port.

But Python (or rather pyserial) seems very unhappy about that for some reason.

It does, at least the code supports it. Could it be it tries to read the userspace buffer without copying and a not-so-recent change forbids this?

Ok then, I installed a linux in this machine, wrote a python script to read the serial mouse data and it works. You had to set datarate to 1200bps, 7 databits, stopbits 1, No parity and HW flow control. As soon as I read from the port I get 0x4d that identifies a Microsoft compatible mouse and relative data. Fine! So I tried then to write a serial app with Bethon’s BSerial class. But it seems that at 1200bps I get no input at all. I tried then to read the input with Haiku’s app SerialConnect, but it doesn’t show any input as well. At lower bps data is represented (wrong data obviously). The only thing I can imagine is that 1200 bps datarate is blocked or denied…
Any advice?

Last try, I connected a usb-to-serial adapter and connected the mice there.
At 1200bps it seems they send correct data (or at least the first byte aka button status byte, but maybe this is my app not working properly), so maybe the problem lies on the onboard serial driver(?), as in linux it works and with the same params the software works with usb-to-serial adapter

I haven’t touched the pc_serial driver for years, maybe it never worked for less than 8bits or something. I’d have to dig the hardware and test it.

The driver definitely seems to set the LCR register for 7bits, but maybe there’s some more handling to do somewhere.