Ensure both input and output baud rates are set.

QSerialPortPrivate::setBaudRate() wasn't trying to set the output
baud rate for the port after successfully setting the input baud rate.

Also, some devices (such as FTDI chips) on Mac don't respond
properly if you call updateTermios() with mismatched baud rates,
even if you later set them to be the same.

Change-Id: I507fe10cba221bb4e43ded650dc44cc974de2414
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Fix the default constructor test case

Commit 7c737e0edcb93585856c65890ef34e5c5a28ee6b introduced
this regression by changing the default baud rate from 0 to 9600.

Change-Id: If20315eb53c3416646541dda82add0f4fc12d4a3
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Merge remote-tracking branch 'origin/release' into stable

Change-Id: I26db36a638685472296001d9982a157b8a6616b5
Add a unit test to verify flush()

On Windows a test will be skipped since flush() does not work there

Change-Id: Ibda38401aff5f1c50644c6d61f9802217146a4fb
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Merge "Merge remote-tracking branch 'origin/release' into stable" into refs/staging/stable
Use Q_NULLPTR for null pointer purposes with NULL fallback for Qt 4

Change-Id: I5422376a26111f7c8e084791a059215238a16868
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Steven Ceuppens <steven.ceuppens@icloud.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Refactor QSerialPortPrivate::setBaudRate()

Split platform specific functions into their own setCustomBaudRate() methods to
improve readability.

As a side-effect, remove isCustomBaudRateSupported flag.

Change-Id: Ia26d5472219756fbf186c78aa049bba72966d7b5
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
QNX: Enable custom baud rate

Change-Id: Iec4124886514c5bdeae1cf00e3b2e9432a2c75ee
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Return after an error of the async write operation

Tested on Windows 8 using the on-board and the USB serial
ports and using Qt4 and Qt5.

Change-Id: Idd25b81c9b6b2cd0b94e83fe30e6e7dad4dddfd6
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Use QTimer to defer starting of writing on Windows

The Win32 API has not possibility to do same behavior as on *nix to defer
a write operation to next event-loop. In *nix implementation enabling of
the write SocketNotifier guarantees that write operation will begin on the
following cycle of event-loop in case the TxFIFO of the driver is empty.

It give an feature of deferred data transfer where is possible to use chain
of the QSerialPort::write() methods which just accumulate data in
writeBuffer. Also it gives the chance to simple implement of the
waitForBytesWrite() method.

But in Windows implementation the first call of the QSerialPort::write()
leads to startup of data transfer. And the subsequent calls of this
method simply accumulate data while the previous operation won't completed.

It leads to a payload data are transferred by chunks and to increase of
loading of the write notifier. Also it complicates implementation of the
waitForBytesWritten() method which works not in compliance with
documentation.

The decision is use of additional QTimer with a zero interval which
launches data transfer on the following event-loop cycle.

Tested on Windows 8 using the virtual com0com serial ports and set
of the cwriter(a)sync examples with use Qt5.

Change-Id: Iaea404198e440f6cb191f168561c977d18e9f4ca
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Fix the waitForBytesWritten() behavior on Windows

The slot _q_completeAsyncWrite(), which is used inside of
waitForBytesWritten(), returns void. To define the status
of write completion method was used the last error code,
where any value are not equal to NoError was interpreted
as an error.

But this behavior was incorrect because the error code
number could be set by any other previous I/O operation
and remained not cleared. Therefore waitForBytesWritten()
always returns false.

A good solution it is to compare size of the writeBuffer
after completion of each write operation with zero, because
the buffer should be empty.

Tested on Windows 8 with the on-board and the USB serial
ports and the cwritersync example using Qt5.

Task-number: QTBUG-36758
Change-Id: I2cf6f9e08056d2e237211b19cff59990aac53bc1
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>