Bug#740098: librxtx-java: setting speed to 38400 doesn't work on some (many?) USB-serial-adapters

Jan Niehusmann jan at gondor.com
Tue Feb 25 17:36:56 UTC 2014


Package: librxtx-java
Version: 2.2pre2-11
Severity: normal

Hi,

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
adapters:

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
setserial(8)."

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:
http://ubuntuforums.org/showthread.php?t=1206637

So to set the custom speed, one calls TIOCGSERIAL, sets custom_divisor
to baud_base / (desired speed), flags t0 ASYNC_SPD_CUST and calls
TIOCSSERIAL.

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
2.2pre2.

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 :-)

Regards,
Jan

-- 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 mailing list