Bug#740098: librxtx-java: setting speed to 38400 doesn't work on some (many?) USB-serial-adapters
jan at gondor.com
Tue Feb 25 17:36:56 UTC 2014
I got an issue with 2.2pre2-11 not working, while 2.1.7r2-4 does.
(And it's been this way since I upgraded the host from lenny to squeeze.
Didn't have time to investigate back then, but now, while upgrading to
wheezy, I had a look at it, again.)
Some debugging showed that there is some bad interaction with a bugfix
introduced in 2.2pre2 and missing capabilities of the USB-serial
Let me start by giving some explanation why the 38400 speed is special:
Usually, one sets the speed of a serial line by calling cfsetispeed /
cfsetospeed. The speed parameter must come from a fixed list of
predefined constants, for example B38400 for 38400 bps.
However, as not all possible speeds are covered by these constants,
there is a second mechanism: The constant B38400 is overloaded. The
manual page of cfsetispeed says:
"The actual bit rate corresponding to B38400 may be altered with
Of course, that rate can not only be set with setserial, but there is a
C API, as well, albeit badly documented. I found a short code sample here:
So to set the custom speed, one calls TIOCGSERIAL, sets custom_divisor
to baud_base / (desired speed), flags t0 ASYNC_SPD_CUST and calls
Now, selecting B38400 actually selects a different speed.
Of course, if one really wants to set 38400 bps, one has to be careful:
Maybe the last selected speed was such a custom one, so just selecting
B38400 wouldn't give the expected result, but instead select the custom
speed, again. Therefore, when switching back to B38400, one has to undo
the custom-speed-selection done before.
The mechanism to reset to 'real' B38400 was, AFAIKT, implemented in
Unfortunately, the way it was implemented, it just assumes that the
TIOCGSERIAL and TIOCSSERIAL are always available. This is probably true
for conventional serial ports, often based on the 16550 UART.
But for USB adapters, I already saw two different failure modes: In one
case, TIOCGSERIAL was not implemented, in the other, it was, but
TIOCSSERIAL was not.
In both cases, rxtx 2.2pre2-11 fails to set B38400.
To fix this issue, when selecting B38400, it's necessary to handle the
failure of TIOCGSERIAL and/or TIOCSSERIAL.
I'm already working on a patch, and as this bug is several years old,
there is probably no need for immediate action :-)
-- System Information:
Debian Release: 7.4
APT prefers stable
APT policy: (989, 'stable'), (500, 'oldstable'), (99, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13.5-smapi-x61s-amd64-00006-g962aefc (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages librxtx-java depends on:
ii libc6 2.13-38+deb7u1
librxtx-java recommends no packages.
librxtx-java suggests no packages.
-- no debconf information
More information about the pkg-java-maintainers