Unify of the internal API of asynchronous handling

It makes sense to unify internal methods of asynchronous I/O where to each
method of start of operation corresponds the method of completion of
operation:

* startAsyncCommunication() - it is a new method which has a code relating
to the handling of the WaitCommEvent() function. It implementations is taken
directly by copy/paste with minimal modifications relating with adding of
returns a boolean values.

* _q_completeAsyncCommunication() - it is an existing method which is renamed
from the _q_canCompleteCommunication().

* startAsyncRead() - it is an existing method without modifications.

* _q_completeAsyncRead() - it is an existing method which is renamed from
the _q_canCompleteRead(). Earlier this method contained a subfunction of
the completeAsyncRead(DWORD) which is deleted now, and its code (related with
the policy processing) is moved into body of the _q_completeAsyncRead() with
the minimum modifications which do not change it behavior.

* startAsyncWrite() - it is an existing method without modifications.

* _q_completeAsyncWrite() - it is an existing method which is renamed from
the _q_canCompleteWrite(). Earlier this method contained a subfunction of
the completeAsyncWrite(DWORD) which is deleted now, and its code is moved
into body of the _q_completeAsyncWrite() without modifications.

Also in addition is added the new method emitReadyRead() and the code of
policy emulation is moved into new method emulateErrorPolicy().

Change-Id: I58345e3270d676879a16efc4b7f35f74869894d8
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Optimize access to the write buffer

Earlier for writing in writeBuffer was used the
QSerialPortPrivate::writeToBuffer() method which contained
a similar code for each platform.

Therefore it is reasonable to delete this method, and to move
its common functionality to the QSerialPort::writeData(). Also
all platform-dependent code of start of data transfer move to
the QSerialPortPrivate::startWriting() method.

Change-Id: I1423723fd69c05df974f8ba597e3dd71d5a797dd
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Bump MODULE_VERSION to 5.2.2

Change-Id: Ic1184214f9ce933fc3df47629e0a707e0b8d63f5
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Remove an unnecessary boolean interim variable

This is needless because it is only used once, right after the creation.
Moreover, we would probably need to separate the two calls later into distinct
introspection conditions to give a bit more correct warning whether the sysfs is
present, or it is just not readable for some reason.

It is also consistent with some other places.

It also eliminates the needless indentation level for that relatively long
block.

Change-Id: Ib66e3033c2439315a8034101129cadd2dcdc29d0
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Fix some typos in documentation.

Fix some spelling and grammatical errors in comments that show up in Qt documentation. No changes to code.

Change-Id: I185458e162d115eac25326d239b851b5e14ed5cf
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Handle the ERROR_INVALID_NAME error code

If the user tries to open the serial port with empty
port name, Windows returns this error code.

The error will be exposed as
QSerialPort::DeviceNotFoundError from now.

Tested only on Windows 8 (32 bit) with on-board serial
port as well as an usb dongle (PL2303) using Qt4 and Qt5.

Change-Id: I9a56a7e51dbdab684b6d2a9fdf6398d8d5018e1c
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Optimize of writing sequence algorithm

* The writeSequenceStarted shall be set to true after a successful call
of WriteFile() and to be dropped to false in case of write completion.

* The method startAsyncWrite() shall not call WriteFile() if the
writeBuffer is empty or writing sequence is already started. Also now
there is no sense to check a validity of pointers on data in writeBuffer
before call of WriteFile() because writeBuffer can not be empty.

* It is also expedient to free the writeBuffer in _q_completeAsyncWrite()
method only if numberOfBytesTransferred is not zero.

Tested on Windows 8 with the on-board and the USB (PL2303) serial ports.

Change-Id: Ib70276705fcc3f2396bf7dd6cf6977b62382a64b
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Rewrite the short description of the handle() method

* handle() is duplicated since the description explains that method.

* It is pointless to put the "object" into the sentence.

* It is consistent to start the sentence with the "if".

Here goes a typical example that is worth following with consistency:

"If successful, returns true; otherwise returns false."

Change-Id: I1c7648237c75381b8452b8c47a59445fff58ad34
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Add listing of virtual ports from the "AGG Software"

The current algorithm takes a name of the serial port from
the PortName property which is in the Registry. This value is
filled out by the Ports class installer automatically:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff546514%28v=vs.85%29.aspx

But at using the "AGG Software" software this property is
absent. Therefore the algorithm ignores these serial ports.

The simplest workaround is use of the PortNumber property
which identifies a port number for this software. In this
case a port name defines indirectly, by adding a port number
to the "COM" suffix.

This does not influence other serial ports which are defined
through PortName property.

Tested on Windows XP and Windows 8 with the cenumerator example.

Task-number: QTBUG-32774
Change-Id: I8cda3ed992ff80742511a2952d3fb7e8ac6edc81
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Use the ternary operator meant for this purpose rather than two returns

Change-Id: Ie6b17d95b83ad751130305a6d44cdead3cd46da6
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Add enumeration through the SERIALCOMM registry entry

When using some software that provide an virtual serial
ports functionality is impossible to use the Win32 SetupAPI
feature to enumerate these serial ports.

For example, such software is "Virtual Serial Ports Emulator"
from Eterlogic: http://www.eterlogic.com/Products.VSPE.html

The only possible simple way to detect these serial ports
it to read the registry key HARDWARE\\DEVICEMAP\\SERIALCOMM:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff546502%28v=vs.85%29.aspx

In this case it is possible to get only a name of the serial
port without any additional information.

This method is simply addition to the main SetupAPI functionality.

Task-number: QTBUG-36526
Change-Id: Ib505aee66b74b6a8ebe16cf88c3060c8267397a0
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Add error handling to some missing functions

Change-Id: If8dee1819d493fa4b27eba99de611c61bfdfe7a3
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Remove the unused SystemIn/OutputQueue size methods

Change-Id: Iafab6ccc376da7a856b409017bbc42c36c016253
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Rename the "descriptor" to handle on Windows

* Windows uses the term handle instead of descriptor.

* It is also consistent with the rest how Qt manages it.

Conflicts:
	src/serialport/qserialport_win.cpp

Change-Id: I68a672ea2d8e88e26ad5d822b157ccab79a3d2d9
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Rename the writeSequenceStarted variable to writeStarted

Conflicts:
	src/serialport/qserialport_win.cpp

Change-Id: I786879a485e78e3637d8cb474f86e3bd406bd237
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Initialize the DCB structure before using it

Please refer to the MSDN documentation for details:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363214%28v=vs.85%29.aspx

and

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363201%28v=vs.85%29.aspx

Change-Id: Id60f6d1b4a9237c2ae74063ac52221f42761b004
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Keep the DTR line state at changing of DCB properties

Updating of the DCB structure (in case of setup of some
properties through setXX() methods) leads to reset of a
status of the DTR line to an initial state.

For example, after opening of port the DTR state was "high",
further the call of method setDataTerminalReady(false)
will drop the DTR to "low" state. But if now to change any
properties of the device (e.g. to setup a new baud rate),
the DTR will again be set to "high".

The reason of this behavior is the fDtrControl flag of
DCB structure:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363214%28v=vs.85%29.aspx

To control of DTR is used the EscapeCommFunction() function
which has no relation to the DCB structure. Therefore any
re-initialization of the DCB discard the results of the
EscapeCommFunction() function in case a state of the
fDtrControl flag not equal to the real DTR state.

Solution is change of a fDtrControl flag after successfully
call of the EscapeCommFunction() function. Then further change
of any property will be with a correct DCB.

Besides, it is necessary to drop the flag DTR_CONTROL_HANDSHAKE
at opening of device. Because in this mode the manual control
of the DTR line is forbidden.

Thanks to Dr. Alexander W. Lenhardt
Task-number: QTBUG-36490

Change-Id: I14b040761f7e28108db87e667eb76f559be436cb
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Merge remote-tracking branch 'origin/release' into stable

Conflicts:
	src/serialport/qserialport_win.cpp

Change-Id: Ib00a645c6660a3c81dbc9e159110f7bfc392ea36
Don't use cfmakeraw on SunOS

The cfmakeraw() function is an extension to POSIX and thus not fully
portable. It doesn't exist on Solaris and Illumos.
Source: http://www.perkin.org.uk/posts/solaris-portability-cfmakeraw.html

Change-Id: Icf514fe32c01e85baff2a0d49321e45a320703b7
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Open file descriptors thread-safely on Unix and don't leak them

::open directly is not thread-safe. You need to pass O_CLOEXEC if the OS
supports it. That's the only thread-safe way to open files. qt_safe_open
does that for you.

This patch also implicitly makes all serial devices be opened with
CLOEXEC on all systems, which prevents the file descriptors from leaking
to child processes.

Change-Id: I83a2657fa8d9ccca1b42182bcd83416091066045
Reviewed-by: Laszlo Papp <lpapp@kde.org>