Serial mouse driver error

[TmTFx]

Serial mouse driver compiled from source don't load at boot time syslog says: KERN: AddOnManager::_RegisterAddOn(): InitCheck() in “/boot/home/config/non-packaged/add-ons/input_server/devices/serial_mouse” returned General system error

tested on R1/b3 and hrev55954

[TmTFx]

Complete syslog

[TmTFx]

Tested only on Haiku R1/b3 x86_gcc2 (Athlon64) and hrev55954 x86_gcc2(Via Nano)

[bipolar]

"Nice" to see that code I contributed so long ago is still performing as expected (i.e: buggy as hell :-D)

Too bad I don't have any serial mice left to test.

Upon a quick re-read of that code...

That "returned General system error" basically implies the mouse detection failed (should have returned B_NO_INIT, or similar, I guess... is it there a B_NO_SUCH_DEVICE or similar error code?). It is due to either not being able to properly access the serial port, or my mouse detection code being just a testament of my poor coding skills (I didn't get any better with age :-D).

If your mouse is a Logitech one... It might have never worked anyway. My code was only tested on Mouse Systems, and Microsoft (old/classic, and IntelliMouse/Wheeled-mice) protocols. Did my best regarding the Logitech protocol, but with zero testing.

[bipolar]

TmTFx... Maybe you can recompile it with DEBUG_SERIAL_MOUSE being defined (see ​https://cgit.haiku-os.org/haiku/tree/src/add-ons/input_server/devices/serial_mouse/SerialMouse.cpp#n37), so more info gets to the syslog.

Other than that... can't do much, unless I get another serial mice to test here, sorry! :-(

Edit: bah, nevermind it! That LOG function only "printf"s... I now recall that I used to have a console application loading that code, instead of logging to the syslog :-(

Edit 2: IIRC, the console app that I used, back then, to test the serial_mouse code was based on ​https://cgit.haiku-os.org/haiku/tree/src/tests/kits/game/set_mouse_position_test/test_mouse.cpp.

That way I could use the serial mouse independently from the input_server, and the actually working PS/2 mouse/driver :-D. I'll try to dig it up (assuming it has any value), but it may have been lost to time and failed HDDs.

[TmTFx]

Thanks for the quick response, the tests have been done with a microsoft serial mouse and a logitech one.

[bipolar]

Replying to TmTFx:

Thanks for the quick response, the tests have been done with a microsoft serial mouse and a logitech one.

Man, I'll ask my acquaintances to see if I can get a serial mouse for testing. At least the one using the Microsoft protocol should have a chance of working (I distinctly remember testing 3 really different ones with that protocol).

But... take into account that even when I wrote this code, I was basically the only one still using serial mouses in Haiku (I think I only got feedback from only one person, the dev that committed my code to Haiku's repo: Hey there JackBurton! :-D).

That is to say... I'm really happy that someone tried (at this year!) to use my code, bummed that it didn't work, and really sad that I think I won't be of any help :-(

Maybe some bored dev has a serial mouse in their closet, and it is willing to test it?

For my part, not much more to add, besides a: Greetings from Argentina!

Edit: forgot to add... thanks for the bug report, TmTFx. It is always the right thing to do! (at least that's why I think, as an ex software QC/QA person).

[TmTFx]

Replying to bipolar:

Replying to TmTFx:

Thanks for the quick response, the tests have been done with a microsoft serial mouse and a logitech one.

Man, I'll ask my acquaintances to see if I can get a serial mouse for testing. At least the one using the Microsoft protocol should have a chance of working (I distinctly remember testing 3 really different ones with that protocol).

But... take into account that even when I wrote this code, I was basically the only one still using serial mouses in Haiku (I think I only got feedback from only one person, the dev that committed my code to Haiku's repo: Hey there JackBurton! :-D).

That is to say... I'm really happy that someone tried (at this year!) to use my code, bummed that it didn't work, and really sad that I think I won't be of any help :-(

Maybe some bored dev has a serial mouse in their closet, and it is willing to test it?

For my part, not much more to add, besides a: Greetings from Argentina!

Edit: forgot to add... thanks for the bug report, TmTFx. It is always the right thing to do! (at least that's why I think, as an ex software QC/QA person).

Don't know if related but... Trying to access the serial port within python I get an error like it can't open the device.

\>>> ser = serial.Serial('/dev/ports/pc_serial0') Traceback (most recent call last):

File "<stdin>", line 1, in <module> 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')

[bipolar]

Replying to TmTFx:

Don't know if related but... Trying to access the serial port within python I get an error like it can't open the device.

I never actually used PySerial on Haiku (used it for 6+ years on Linux/Win at work), so not sure if that's "expected" or not.

If that's a PySerial bug... you may want to report it over ​HaikuPorts.

I guess that first we need to know if Haiku's serial port is actually working on your systems...

You may want to try with the ​SerialConnect app, and either hook up two Haiku machines, or hack up some loopback cable and see if SerialConnect shows that whatever you send it reads back? (I'm just "thinking out loud" here)

There is also this small ​SerialIO.cpp test app that I guess you could try.

If with that or with SerialConnect you see errors related to the serial port, I guess you should open a different ticket for that in this issue tracker.

If those seem to work... more reason to blame my poor mouse-detection code :-D

---

I feel that the serial port was in its way out of people's hardware at the time Haiku added support for it, and thus it may be not thoroughly tested.

In any case... I doubt I'll be of any further assistance, I'm sorry! (for lack of skills, not for lack of willingness).

I should let one of the actual Haiku developers (or other contributors) step-in.

[TmTFx]

I realize that with BSerial class in my app and with SerialConnect if I set datarate to 1200 bps to onboard serial port I get no readings (but I get them on usb-to-serial adapter). That datarate is necessary to achieve a mouse reading. Some other speeds give output (but data is not correct obviously)

[bipolar]

​This part of the source code shows two different drivers: one for USB-based serial ports, one for "standard" PC serial ports.

That would explain the differences you're seeing when using the USB<->Serial adapter.

I guess we would need François Revol (mmu_man) to chime in (he's the one who wrote the pc_serial driver code).

And if pc_serial does not works OK, at least on your system, that indeed would explain why my crappy code can't see your mouse.

I originally wrote serial_mouse while using BeOS PE R5. "It worked there!" ™ (using BeOS serial driver, I mean).

That was apparently... 4/5 years before Haiku got its pc_serial port driver. Jebus... how time flies!

I guess this ticket could/should be turned into a "pc_serial driver not working correctly" or similar ticket then.

Any one from the current developers/contributors would like to offer suggestions here?

For my part, and unless, at least, I get a serial mouse, or other serial hardware, to test... can't really help, not even with testing :-(.

Sorry, TmTFx!

[korli]

Well, even without serial mouse or hardware, qemu offers "-serial msmouse" or "-chardev msmouse,id=msmouse -device isa-serial,chardev=msmouse" as an option (untested from me).

[pulkomandy]

I used pc_serial a few times recently and had no problems with it, but I did not try with baudrate this low, and the driver is known to not be 100% reliable indeed.

I still have at least one machine with a serial port (for some reason it was included on a motherboard I bought in 2014) and I also have an ExpressCard adapter that I can use in laptops with ExpressCard ports (very useful when debugging a graphics driver on such a machine).

I have used both and I don't remember getting any problems. But I think there is other hardware where it doesn't work as well.

However I also don't have a serial mouse to test with. I may have a look with qemu indeed, and see if I can find something.

[bipolar]

Replying to korli:

Well, even without serial mouse or hardware, qemu offers "-serial msmouse" or "-chardev msmouse,id=msmouse -device isa-serial,chardev=msmouse" as an option (untested from me).

Ah! Good to know, thanks! I'd never used qemu before :-/

In any case... I managed to find a serial/parallel header that works with my motherboard, and also one of my PS/2 mouse seems to work fine (on Windows at least) while using a PS/2->Serial passive adapter (IntelliMouse protocol).

At the very least, I will be able to test serial_mouse in the near future. Can't promise much else, I'm extremely rusty regarding programming (and I wasn't exactly good to start with :-D).

I'll report back when/if I get any info worth noting.

[bipolar]

Alright, did some basic tests, and found the first bug in serial_mouse. As it is, it will only attempt to open /dev/ports/pc_serial1 (basically meaning that it won't ever work if you have only one serial port).

The dumb code that make this possible is at:

• ​Line 80. It should read fPortsCount = fSerialPort->CountDevices(); (dropping the "-1").

and

• ​Line 113. It should read: for (uint8 i = 0; i < fPortsCount; i++) { instead.

[edit-->]

• ​Line 140 should read: fPortNumber = i + 1; (otherwise IsMousePresent() will return 0/false if using the first port).

[<--edit]

With those changes, it at least it opens /dev/ports/pc_serial0 on one of my Haiku installs on the same machine (beta3, on a more recent nightly I get no devices under /dev/ports/... something else is broken there).

In any case, further testing shows that it consistently hangs on ​Line 186 for me, after reading 3 bytes, the 4th call to fSerialPort->Read(&c, 1) never returns (even while being in non blocking mode, and even after the set 200 ms timeout anyway).

[Edit: just to mention that those 3 bytes I get, almost always contain 0x0, except one time I got 0x7F on the first one of those]

Not really sure what is going on with that. I'll try to write a small test case for that reading issues.

Also, I'll see if I can do anything to clean up serial_mouse, making it log properly at least.

I have much to re-learn regarding programming, so... no promises :-(

[pulkomandy]

beta3, on a more recent nightly I get no devices under /dev/ports/... something else is broken there

In nightlies the first serial port is by default used by the kernel debugger. You have to disable that in the kernel settings file (home/config/settings/system/kernel I think? or something like that) if you want to use it for something else.

I would recommend testing in nightlies, because since beta3 I have fixed some issues in the TTY code that would lead to lockups in some situations.

[bipolar]

Replying to pulkomandy:

In nightlies the first serial port is by default used by the kernel debugger. You have to disable that in the kernel settings file (home/config/settings/system/kernel I think? or something like that) if you want to use it for something else.

Ah! Thanks for the heads up! For reference, that would be serial_debug_output false on the ~/config/settings/kernel/drivers/kernel file.

I would recommend testing in nightlies, because since beta3 I have fixed some issues in the TTY code that would lead to lockups in some situations.

Good to know! I'll see if I get more luck with really fresh ones (and a full re-install), as somewhere around the jumbo frames changes, my ethernet started acting up, and later changes made nightlies less stable than beta3 for me.

FWIW, I tried using a "serial port pass-through" using VirtualBox from Windows (after disabling the Win mouse driver). Ports show up on Haiku OK, pc_serial0 as a debug output, and pc_serial1 being the one I attempted to use for the mouse. Under that situation, only one byte is read, and then it blocks... but that is on beta3 too, so... could be missing your fixes indeed.

[TmTFx]

I'm surely less experienced than you, but as far as I can remember in one of my firsts test I got the 0x0 too... Are you sure serial port speed is set to 1200 bps, 7bits etc.?

[bipolar]

Replying to TmTFx:

I'm surely less experienced than you, but as far as I can remember in one of my firsts test I got the 0x0 too... Are you sure serial port speed is set to 1200 bps, 7bits etc.?

At least as sure as I can be, considering that I was testing the same code from ​SerialMouse.cpp, but compiled as part of a console test application.

SetPortOptions() (​See code here) gets called early in the DetectMouse() function (​Line 169).

It does calls:

    fSerialPort->SetDataRate(B_1200_BPS);
    fSerialPort->SetDataBits(B_DATA_BITS_7);

the first time around (due to fMouseID = kNotSet on the constructor for the SerialMouse object).

So... unless the the BSerialPort class, or the pc_serial, are messing that up... it should be using 1200 bps and 7 bits at that point.

For reference, after toggling the RTS line (​Line 177), the mouse should respond with 'MZ' as the first bytes (at least the mouse I currently have for testing).

I'm tempted to try and install BeOS PE R5 on my old Athlon K7 (where I wrote the code in 2004) and do some testing over there too. If it works on that machine with BeOS, but it doesn't on Haiku... that would most certainly point to problems with either BSerialPort or pc_serial code (I mean... besides the rest of the bugs in serial_mouse :-D).

I'm also toying with the idea of setting up some serial port testing thingy using VirtualBox + com0com (Win) or socat (Lin) + pyserial.

Will report back if/when I find anything (might take me a while to setup everything for testing, thou!).

[bipolar]

Ok, I've tested on hrev56332 (both 32 and 64 bits). I couldn't get serial port to read more than 2 bytes. It then seems to still hang out on a read call.

So... 1200 baud rate is definitively broken in pc_serial.

Part of the problem, at least, is in the divisor value for the baud-rates 1200 and 1800, that are set to zero here:

​https://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/ports/pc_serial/Driver.cpp#n49

when the correct values would seem to be 96 and 64 respectively.

With that change, I manage to read more bytes. Still seem to be reading garbage, but hey, progress!

I'll keep trying to do more tests (hopefully I'll be able to setup a BeOS machine in the next days).

Edit: For the record... using qemu with its msmouse emulation for testing won't help with serial_mouse. The emulated mouse does not sends proper id after toggling the RTS line. See ​this qemu bug, and more directly, the emulated mouse ​sources.

[bipolar]

After testing on BeOS R5 PE (on two different motherboards), I came to the conclusion that indeed the biggest problem is with Haiku's pc_serial.

serial_mouse, compiled with the edits mentioned previously, works ok on BeOS (well, a tiny bit jerky compared to the original driver, and with different acceleration profiles).

Did more tests, outputting to the console the bytes I get after toggling the RTS line (with the mouse perfectly still, and calling BSerialPort.ClearInput() before the final RTS up).

I consistently get 47 bytes that start with MZ, after those 47 bytes, and if I move the mouse or click the buttons, I get proper 4-bytes packages for this IntelliMouse compatible mouse I have.

Back on Haiku (hrev56332), and after modifying pc_serial according to my previous comment (96 as divisor for 1200 baud-rate), what I get is not garbage as I first thought... but incomplete/broken data.

After toggling the RTS line (triggers the mouse to send its ID), instead of 47 bytes... I get a total of 18 + 27.

The first 18 are always equal to each other (but change from test run to test run). Crazy part is that I get those 18 bytes even after calling BSerialPort.ClearInput(), which should not happen because I'm holding RTS down. Edit: I call Read() until it stop returning data here. Did that trying to make sure that the input buffers were really cleared.

After setting RTS up, I get the next 27 bytes, and those are exactly the same as the 27 final bytes I get on BeOS.

I'll do my best to try to find the problem on pc_serial, but... I'm afraid it might be way out of my league :-(

FWIW, TmTFx... while you wait, maybe you could try pkgman install keycursor. It's not perfect, but moving the cursor with the arrow keys is better than no mouse at all :-D (​here are some basic usage instructions. Double click on Tracker does not works on Haiku, it does on BeOS, hmmm. For opening things on tracker, select the element with spacebar/clic, and then press Enter to open it).

[bipolar]

Small test case to try to read the serial mouse ID on multiple platforms.

[bipolar]

Similar test case, but as a Haiku program, because pyserial does not seems to work on Haiku yet.

[bipolar]

A bit more info, before I forget it:

While testing with the attached test cases with strace, it became obvious why I can read the mouse ID with python, but not with BSerialPort...

The strace infro for the reads from pyserial look like this:

[  1655] select(0x5, [3 4], [], [], 0x30d31, (nil)) = 0x1 ([3], [], []) (136748 us)
[  1655] read(0x3, 0xffffffffffffffff, 0xed4d7ffef0, 0x1) = 0x1 () (39 us)
"M" - 77 - 0x4D
[  1655] write(0x1, 0xffffffffffffffff, 0x114eb2bc5550, 0x10) = 0x10 () (40 us)
[  1655] select(0x5, [3 4], [], [], 0x30d38, (nil)) = 0x1 ([3], [], []) (71 us)
[  1655] read(0x3, 0xffffffffffffffff, 0xed4d7fffb0, 0x1) = 0x1 () (29 us)
"Z" - 90 - 0x5A
[  1655] write(0x1, 0xffffffffffffffff, 0x114eb2bc5550, 0x10) = 0x10 () (34 us)

And the ones from BSerialPort look like this:

[  1651] ioctl(0x3, TCWAITEVENT, 0x7f355f3addf8, 0x8) = 0x80000005 Invalid Argument () (32 us)
[  1651] read(0x3, 0xffffffffffffffff, 0x7f355f3adf77, 0x1) = 0x1 () (37 us)
read = '.' (8 d - 8 h)
[  1651] write(0x1, 0xffffffffffffffff, 0x10ebf66ebae0, 0x17) = 0x17 () (36 us)
[  1651] ioctl(0x3, TCWAITEVENT, 0x7f355f3addf8, 0x8) = 0x80000005 Invalid Argument () (31 us)
[  1651] read(0x3, 0xffffffffffffffff, 0x7f355f3adf77, 0x1) = 0x1 () (31 us)
read = '.' (1 d - 1 h)
[  1651] write(0x1, 0xffffffffffffffff, 0x10ebf66ebae0, 0x17) = 0x17 () (37 us)

Those "Invalid Argument" regarding TCWAITEVENT seem to explain why BSerialPort doesn't respects any timeout, hanging indefinitely instead.

Only the tty driver "handles" TCWAITEVENT, and it is a no-op. The tty module (and thus pc_serial) don't know anything about that signal. Google seems to only have results for TCWAITEVENT related to BeOS/Haiku.

Lastly... Regarding the the issue with PySerial: #17861 seems to be the root cause.

[TmTFx]

Replying to bipolar:

Ok, I've tested ... Still seem to be reading garbage

Yes, Actually after writing a simple python-Bethon app, using BSerial, I read the same thing, after 2 bytes of correct readings it seems to collect garbage data.

maybe you could try pkgman install keycursor

Thanks for the advice, but I need a working serial port mouse on a pc which has no USB support at all (so even without keyboard), the ones I use to test the serial mouse driver(/serial port) have an alternative usb mouse connected. Thank you for your support. You went so far investigating the problem!

[bipolar]

Replying to TmTFx:

I need a working serial port mouse on a pc which has no USB support at all (so even without keyboard)

Ouch. ​synergy could be a workaround, if only you had a working LAN in that PC.

You went so far investigating the problem!

:-) What I lack in skills, I have in hypo-mania! (while it last, LOL!)

As you see, there are issues on several different components, some pretty arcane at this point. At least there is a clear picture of what works and what not (and mostly why):

• A couple of issues with termios tcflush()/tcdrain() (making PySerial fail). BSerialPort's ClearInput()/ClearOutput() fail here too, but they do it silently! :-( #17861. Fixed on hrev56354.
• Wrong baudrate divisors on pc_serial (preventing use of 1200 bps). Fixed on hrev56351.
• BSerialPort WaitForInput() doesn't works, as it relies on a ioctl signal that is not supported by pc_serial/tty (PySerial uses select() instead, and work far better). #17867. Fixed on hrev56986.
• BSerialPort doesn't seems to enforce SetBlocking(false), causing Read() to always block. #8789.
• BSerialPort/pc_serial seem to be eating away the first 4 bytes after setting RTS (on my hardware at least). Might be related to the previous ones, or be a separate issue.
• More things that will pop up (or hopefully resolve!) after fixing those.
• Finally... the bugs on serial_mouse proper :-D

Not sure how long it will take to properly fix this ticket. But I'll keep trying, and hopefully we'll have something working before you give up :-D

Thanks for your patience, and thanks to the Haiku devs, on here and on IRC, for helping me try to figure out things!