New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 176711 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Feb 2013
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Sign in to add a comment

chrome.serial API fails to set baudrate on linux

Reported by, Feb 17 2013

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.84 Safari/537.22

Steps to reproduce the problem:
1. try to open a port via chrome.serial in linux
2. chrome will join the bus (while ignoring baud rate settings from user)
3. "enjoy faulty data" coming back and forth because of incorrect baud rate (default 9600)

What is the expected behavior?
Serial API should change port baud rate to one parsed inside OpenOptions.

What went wrong?
By default, everything will be running on 9600, only way to "fix" this is to use external utility that will change the port baud rate for you, for example

stty -F /dev/ttyUSB0 38400

I have burned 5 nights in a row tracking this problem (thinking my uC/js code was the problem)

This problem is present in v24 stable, v25 beta and in v27 nightly (183010)

WebStore page: Any APP using chrome.serial is affected

Did this work before? No 

Chrome version: 25.0.1364.84  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)

I think this problem should be marked as high priority (for linux users) as it makes any communication with device using different baud rate then 9600 impossible.
Please switch the OS field from Windows to Linux (i was posting this bug from my windows machine)
Labels: -OS-Windows OS-Linux
Project Member

Comment 3 by, Feb 20 2013

The following revision refers to this bug:

r183543 | | 2013-02-20T15:29:11.628048Z

Changed paths:

Fixing serial baut/bit rate definition on PostOpen for Linux. By "STANDARD" POSIX defines that B9600, B38400 defined types should be used. Linux define it on /usr/include/rpcsvc/rex.h and it uses numeric sequence increment to enumeration, Mac OS X define it as the same number for example #define B38400 38400. So If you're trying to connect on Linux using a bautrate 38400 for example, the cfsetispeed was called using the 38400 int value, that works for MAC but not for Linux. Code was changed to met the STANDART Bxxxxxx.

Mac OS definition:

Contributed by
BUG found by cTn / Shadow6363 @ freenode - Thanks!

BUG= 176439 , 176711 
TEST=Try to open a connection with different bitrates on Linux and see that is working. More information about how to reproduce it on Bug report.

Review URL:

Comment 4 by, Feb 21 2013

Status: Started

Comment 5 by, Feb 21 2013

Status: Fixed
Many thanks for the fixes, guys!
anytime :-)
Project Member

Comment 7 by, Mar 11 2013

Labels: -Feature-Apps Cr-Platform-Apps

Sign in to add a comment