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
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
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…
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)
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/serialutil.py”, line 244, in init
self.open()
File “/packages/python-2.7.18-2/.self/non-packaged/lib/python2.7/site-packages/serial/serialposix.py”, line 344, in open
self._reset_input_buffer()
File “/packages/python-2.7.18-2/.self/non-packaged/lib/python2.7/site-packages/serial/serialposix.py”, 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.
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