libserialport incompatibility with glibc version 2.42

[dekay]

(jsm174 is aware of this issue but I'll still put in lots of detail for others that might be hit by this)

The libserialport library breaks on Linux systems running glibc version 2.42 for some devices. For VPX, it affects devices like the Wemos D1 Mini with an onboard USB to Serial converter when run at odd baud rates like the 2MHz value used on it by default. Teensy controllers are not effected as their micro handles USB natively. The bug affects Arch users currently and I think Fedora 43 as well, and it will affect more as other distros update their glibc.

Error messages like these will show in the logs. The killer is that it says the baud rate is initialized but in reality it silently fails.

[INFO]  Initializing ComPort /dev/ttyUSB0 with these settings :
        BaudRate 2000000, Parity 0, DataBits 8, StopBits 1, R/W Timeouts 300ms
        Handshake Timings : Open 300ms, Loop Start/End 100/100ms, DTR enable true
[ERROR] Could not put the controller on com-port '/dev/ttyUSB0' into the commandmode. Will not send data to the controller.

You can verify this by checking the baud rate after vpx runs and seeing that it is still stuck at the default rate of 9600 instead of 2 MHz

[dk@ryzen libdof]$ stty -F /dev/ttyUSB0
speed 9600 baud; line = 0;
-brkint -imaxbel

A pull request to fix this has been rotting in Github since September 2025. Unfortunately, the last commit to this repo was in September of 2024 so libserial appears to be currently unmaintained.

Workaround

• Before running vpinball, set the baud rate manually with stty -F /dev/ttyUSB0 2000000 (or whatever your device shows up as)

Potential fixes

• continue to use the libserialport repo but integrate hpax's attached patches linked above
• switch to the patch author's repo for libserialport that integrates this fix. There would be no real downside at least for now given that the main repo appears unmaintained.
• see if this patch in the very recently released glibc 2.43 fixes it. Even if it does fix it, any distro on 2.42 will be affected until that distro updates to 2.43.

[dekay]

Arch now has glibc 2.43 in the main repo so I updated my system and gave this a shot. I don't have any LEDs connected to the Wemos D1 Mini right now but libdof seems like it is now properly connecting to it without me having to set the baud rate manually first. After installation and reboot, running vpx with the DOF plugin enabled gives me what looks to be a successful connection (though not sure about the Updater thread warning)

2026.02.15 13:10:13.488	Initializing ComPort /dev/ttyUSB0 with these settings :
2026.02.15 13:10:13.488	Have fun! :)
2026.02.15 13:10:13.488		BaudRate 2000000, Parity 0, DataBits 8, StopBits 1, R/W Timeouts 300ms
2026.02.15 13:10:13.488		Handshake Timings : Open 300ms, Loop Start/End 100/100ms, DTR enable true
2026.02.15 13:10:14.396	Resize ledstrip 0 to 512 leds.
2026.02.15 13:10:14.398	Send a test request to the controller
2026.02.15 13:10:16.418	Updater thread connected to WemosD1MPStripController Boognish
2026.02.15 13:10:24.212	Finishing framework
2026.02.15 13:10:24.212	Finishing cabinet
2026.02.15 13:10:24.212	Finishing 2 toys
2026.02.15 13:10:24.212	Finishing LedWizEquivalent: LedWizEquivalent 30 (LedWiz 30)
2026.02.15 13:10:24.212	Finishing output controllers
2026.02.15 13:10:24.334	Updater thread disconnected and will terminate
2026.02.15 13:10:25.220	Warning: Updater thread did not quit within timeout. Thread termination may be forceful.
2026.02.15 13:10:25.221	WemosD1MPStripController Boognish finished and updater thread stopped.
2026.02.15 13:10:25.221	Output controllers finished

And after exiting, I see that the baud rate was indeed properly set

[dk@ryzen vpinball]$ stty -F /dev/ttyUSB0
speed 2000000 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl ixany -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo

The fault really still lies with libserialport because it configures the device in a really hacky way, but the latest glibc lets it get away with it now with improved backward compatibility for the bad behavior. Ideally libdof would use a fork with a proper serial port initialization implementation but I understand the issue this might raise with the Batocera folks and their desire not to use forks. So I guess this should be closed?