| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This regression was caused by 7c737e0edcb93585856c65890ef34e5c5a28ee6b.
The initialization of the (current) serial port info was removed in that commit.
Tested on Linux x86_64 with Qt 5.1.1 and 4.8.6.
Task-number: QTBUG-38961
Change-Id: Idd3c5dc7eb37093848f33387563ff14567ac54fe
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
Commit bc0a65234440b6a08d862840a48ebae0d3421fbc incorrectly
marked this api as deprecated since 5.2
Change-Id: Ia4ea3d7a394376a16511a3bf2ad8ba6e051bc24d
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, flushing is not flushing the buffer to the device because
it is calling the wrong function.
Before flush() is invoked startAsyncWrite, but this did not flush the buffer
when it was not empty. The only possible way to fix this is by invoking the
function completeAsyncWrite, it first checks for pending information in the
buffer for sending and then invokes startAsyncWrite if necessary.
The following change caused the regression: 21f5049
Test Environment: Qt 5.3.0-beta1 and Qt 4.8.2.
S.O.: 3.12.6-2kali1 i686 GNU/Linux.
Fiscal Machine: SRP350 Bixolon.
USB Adapter Serial Port: CH341
Task-number: QTBUG-38339
Change-Id: I5159b48f073d537a396b65484fcc2c3d37e4908c
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Correct example install path is required for the example
manifest file to contain valid paths to the .pro files.
Task-number: QTBUG-38359
Change-Id: Ibfe98ed4f3402f2e1534b578d0caecf3676a6f36
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Laszlo Papp <lpapp@kde.org>
|
|
|
|
|
|
|
|
|
|
|
| |
"LIBS -= -framework QtSerialPort" removes all occurrences of -framework
which breaks the build if you use a framework together with QtSerialPort.
To avoid this we skip the call to qtAddLibrary under Mac.
Task-number: QTBUG-37989
Change-Id: I53b71ad433e93c8c59d17c526ef2424db47bca15
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Laszlo Papp <lpapp@kde.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If anything, this should be made clear in a different way, like proper variable
names, inline convenience functions for naming, example documentation extension,
and so on.
This is also consistent with the other examples not using "water can" comments.
However, these comments mostly add noise to the code without much benefit as far
as I can tell.
Change-Id: I9c4121d91ca2671d44c08cf986232422f136a785
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Fix warnings:
qtserialport/src/serialport/qt4support/src/qlockfile.cpp:57: warning: Overrides a previous doc
qtbase/src/corelib/io/qlockfile.h:53: warning: (The previous doc is here)
Change-Id: I75c93fd6dbd9bebfa506b2f606aeb8511a892305
Reviewed-by: Laszlo Papp <lpapp@kde.org>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-37578
Change-Id: I9e9146a1f7339a88c63cb320a47f63f069a6120e
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
| |
Change-Id: I946a3f1d3a64a9b8c0d901347aa8ff5959ebc601
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Added check for Q_OS_ANDROID. If connected to Android, look for a valid TTY_USB id.
Task-number: QTBUG-36296
Change-Id: Ic99b0ddd7afc6621e795e2f6cf2952cae6634fb0
Reviewed-by: Luke Andrew <codereview@lukeandrew.com>
Reviewed-by: Laszlo Papp <lpapp@kde.org>
|
|
|
|
|
|
|
|
|
| |
Now that the settings detection is removed, it would be better to make this API
deprecate because it does not make much sense anymore. It was a bad idea to add
this, but we cannot remove it for now, hence the obsoletion.
Change-Id: I5e02959cb54281995b911ff0f64bd2fa36b80060
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
It seems they were accidentally misplaced, and it was not caught by anyone while
testing and using this example. Although, I have seen users doing this mistake
on Stack Overflow, so I was wondering where they would get the idea from. It is
possible they have done such mistakes due to a copy/paste operation from this
old example.
Change-Id: Iaa25ae47c5f161856930801611a3dc7ff0aa3b0a
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also changes the behavior of the open method. We do not use port
detection anymore for good. It has been a broken concept, and it is very
unlikely that anyone has ever relied on it. If anyone had done that, they would
be in trouble anyway, getting noisy warnings needlessly and all that.
The other option was also considered to keep this behavior optionally as the
default, but that would complicate the API too much without not much gain.
The default port settings are now also the sane 9600,8,N,1, and no flow control.
Also please note that the serial port is closed automatically in the open method
if any of the settings fails.
Several subsequent changes can follow this one, namely:
* Changing the examples to show this usage.
* Add a QSerialPortSettings data structure as it seems to be common currently in
client codes.
* Add the QML plugin with only thin wrapper declarative classes and all that.
* Deprecate the restore settings on close API.
* Remove the internal current and restored data representations.
* Add further error values to the API for the fine tuning of the error reporting
when there are setting errors on open.
* Add proper test coverage.
In short, this change opens the gate up for many interesting subsequent changes
that would be useful for the module overall.
In general, this change makes it possible to reach the feature parity with
QextSerialPort so that we are not much worse anymore. We could do the same that
QextSerialPort could do many years ago, already.
Task-number: QTBUG-33774
Change-Id: I8527672f8b0bb2581fa7054ccffda66ab7fa4a85
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
|
|
|
| |
It was done like that for consistency with QFile, probably, but it is not a good
style in Qt overall.
Change-Id: I5233a7f0f03cab947b061520fe2ec64585632920
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks go to Massimo Callegari for the initial patch and the request to remind
us again. Thanks also go to Denis and Sergey for working on the windows serial
number parser.
Task-number: QTBUG-31981
Change-Id: I60d882280f481eb99d275e0a9c81da50292b1c61
Reviewed-by: Massimo Callegari <massimocallegari@yahoo.it>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
| |
Change-Id: I2a73e9dc19e93c678d803d4aaf2e03c19e7613fb
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
| |
Change-Id: Ida3c4ff049f21bd96fd64b41c66787b3961ada5e
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added two types of tests: the constructing tests and the opening tests.
The construction tests are checking of the getters to return of default values.
Also are checking a correctness work of the constructor of class with different
types of a port name.
The opening tests are checking the open() method with the valid/invalid open
modes and with the valid/invalid port names. The results are compared with the
expected behavior (with the error codes and the return values).
Change-Id: I503adf629cf613844bf9b96d8704ff017ea5fcdb
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-35781
Change-Id: I24b5ec010525da2c1f1be63996193ac31dcd3808
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|\
| |
| |
| | |
Change-Id: Ifff35473fe07ee5d94f9fb4f0125ee125c109c76
|
| |
| |
| |
| |
| |
| | |
Change-Id: I58cf61540bc53e314988753a252cbc71003ce581
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Even though this has been introduced in 5.1, officially, we can rely on it in
the previous versions even if private API that it was.
* Global variables are better avoided.
* Q_GLOBAL_STATIC is thread-safe in Qt 5.
* QLibrary depends on QCoreApplication and we need to make sure that is
initialized afterwards, respectively.
The instantiation is now moved into the corresponding source file so that if it
is included at more than one place, it will not be instantiated each time it is
used in a new source file including this header.
Task-number: QTBUG-36870
Change-Id: I96de1257e5836b69d0c48b717d7c2e708d6b0fee
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes the operation thread-safe. It also helps with preventing the leaks
for child processes. Also, there is now some protection against EINTR when the
system call has to be restarted.
Thanks go to Thiago Macieira for providing the original patches.
Task-number: QTBUG-36824
Change-Id: I90cac87c5e1c55a57e5ba6c20313446c43c6d242
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-36865
Change-Id: I332901ad0118f1176b0d3b8e45c8000f0dfb59ee
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
|
|\ \
| |/
| |
| | |
Change-Id: I111ca7fd67979152329f290d45bd5b47551a404a
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The serial port very slow device therefore the system
call write() doesn't guarantee that data were transferred
completely to the device. It guarantee only that data were
sent to the driver from the user space.
Thus it is wrong to emit the bytesWritten() signal at once
after successful writing.
The correct solution is to store the number of transferred
data in some variable (e.g. pendingBytesWritten in this
case) and to wait for the next notification from the
WriteNotifier that the write FIFO of device is empty (i.e.
when all data were really transferred) and ready to
transmission of the next portion of data.
Also good decision is to divide a data transfer operation
into two methods: startAsyncWrite() and completeAsyncWrite(),
similar with the Windows implementation.
Where the startAsyncWrite() invokes the write() system
call, and the completeAsyncWrite() is invoked by a
writeNotifier to complete writing operation or start a new
startAsyncWrite() operation.
Tested on Arch Linux 64 bit with the on-board and the USB
(PL2303) serial ports with use Qt4 and then Qt5.
Change-Id: I1c274b2052a9bd54811586c6f1cfdf080b400263
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Revert "Open file descriptors thread-safely on Unix and don't leak them"
This reverts commit 691212d9e492b12590d5b7f4e2b24921911d4b17.
Revert "Protect against EINTR in Unix non-atomic I/O calls"
This reverts commit a8597cbae47076e33b638c2e593f852c8c0a02d5.
Change-Id: I6d931ae6d3b4bee9be019fdf4a08ecc5a41a2b0f
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
|\ \
| |/
| |
| | |
Change-Id: I10b71332b0ec3afc50d11bcc95adb94c6343f6b1
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The device registry property of the SPDRP_HARDWAREID is not
used any more. This property was used earlier for parsing of
the VID/PID and had the type of the REG_MULTI_SZ which was
interpreted as QStringList, see commit:
d8dc10efb1714dcfafa6a08e107fd31fc1e3ce0e
The current code is using only string based concept, hence
changing the interface to QString.
Tested on Windows 8 with on-board and virtual com0com serial
ports using the cenumerator example.
Change-Id: I31e4f85f1b145021c1b34b81ba890553604a0531
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
read(), write() and close() may return EINTR, indicating the system call
should be restarted. The qt_safe_xxx versions of those functions do it.
Change-Id: Ifef3b98131a7e24a5defea3e3af9345a505ad733
Reviewed-by: Laszlo Papp <lpapp@kde.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
::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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/serialport/qserialport_win.cpp
Change-Id: Ib00a645c6660a3c81dbc9e159110f7bfc392ea36
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
They are not much of use due to the low-level OS limitations as of now, hence
the obsolete proposal. It can be brought back to life at any point when we have
a more clear idea what to do with this API.
"faking" this signal as RealTterm probably does it, is not a nice impression
for the end users. That would be more like a software "signal" (which we
already have in place) rather than a real pinout hardware signal.
It is interesting why Windows, Linux, etc do not provide an option for this.
There must be some strong reason for it.
Change-Id: Ia065e2ee9226d16e724f5e2690b25b954329d78e
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The documentation contains broken links due to this, and it is also inconsistent
with the rest. Properties should be referred to as properties, not individual
methods like setter, getter, notified signal, etc.
The change is tested with "make docs" and the broken links are history.
Change-Id: Id94cba1f88503754318c865793229e3d3947bec6
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change eliminates the following warnings when using "make docs":
/home/lpapp/Projects/qt/qt5/qtserialport/examples/serialport/doc/creaderasync.qdoc:28:
warning: Cannot find file 'creader/creader.pro' or 'creader/creader.qmlproject'
/home/lpapp/Projects/qt/qt5/qtserialport/examples/serialport/doc/creaderasync.qdoc:28:
warning: EXAMPLE PATH DOES NOT EXIST: creader
It is also visible that the example is unreachable on the following
documentation page:
http://qt-project.org/doc/qt-5/examples.html
Change-Id: I09f1532fcff6b1f7bfc5c4857bd14252aceb2eb3
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is likely to be happening due to the mismatching function signature include
the return type between the header and source file. Two things are being fixed:
1) Dropped scope for the Handle just like with the winId case in QWidget.
2) "const" qualifier is now added for the method.
Here you can see the documentation that it is empty:
http://qt-project.org/doc/qt-5/qserialport.html#handle
Change-Id: I5e9e0732cfd746a863de523fe90e58eafa42c081
Reviewed-by: Alex Henrie <alexhenrie24@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is necessary to compare size of the readBuffer before and after
completion of each read operation. If size of readBuffer are equal
it means that are no more data available for reading. In this case
the method should returns true if an initial size of readBuffer is
not equal to the current size of readBuffer. Otherwise in all other
cases should be continue waiting until timeout has been expired.
Also must not to do check for the NoError code and to hope for valid
value of this code inside waitForReadyRead(). Because a last error
code do not clears automatically. It lead to false returns of this
method in case the error number is not equal to NoError (for example
it error remained after failed of any previous method). This check
should be implemented in a different way in case of need. But at
present this check is unnecessary because result of the waitAnyEvent()
cover it.
Task-number: QTBUG-33987
Change-Id: Ic8d8e3806fd4863c2720ffb83d5c19eae54d57f0
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Laszlo Papp <lpapp@kde.org>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 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>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Change-Id: Iafab6ccc376da7a856b409017bbc42c36c016253
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Change-Id: If8dee1819d493fa4b27eba99de611c61bfdfe7a3
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Change-Id: Ie6b17d95b83ad751130305a6d44cdead3cd46da6
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 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>
|