| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
|
|
|
|
|
|
|
|
| |
replace explicit pkg-config uses with the results of configure tests,
for consistency.
Change-Id: I3587db6085798ea7a49f8871fc6838eb687a6391
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Use the new qtConfig macro in all pro/pri files.
This required adding some feature entries, and adding
{private,public}Feature to every referenced already existing entry.
Change-Id: I164214dad1154df6ad84e86d99ed14994ef97cf4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
|
|
|
|
|
|
|
|
| |
this migrates the cases where the build system already made (some) use
of variables (possibly) set by configure.
Change-Id: I43a08caed481d5f887a3a40821e71a4797760e7e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parse the touchDevice property from the KMS/DRM config file. When all
outputs have an explicitly specified index in the virtual desktop, we
can set up a mapping between the device node and the screen index. It
is somewhat fragile (device nodes may change, requires explicit
virtualIndex properties for all outputs, etc.) but better than
nothing.
For example, having the screen on DisplayPort as primary and the
touchscreen on HDMI as the secondary screen breaks by default because
touching the second screen generates touch (and synthesized mouse)
events for the first screen. Assuming the touchscreen is
/dev/input/event5, the issue can now be fixed by setting
QT_QPA_EGLFS_KMS_CONFIG with a configuration like the following:
{
"device": "drm-nvdc",
"outputs": [
{
"name": "HDMI1",
"touchDevice": "/dev/input/event5",
"virtualIndex": 1
},
{
"name": "DP1",
"virtualIndex": 0
}
]
}
Task-number: QTBUG-54151
Change-Id: If97fa18a65599ccfe64ce408ea43086ec3863682
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Follow the exact same structure as evdevmouse and keyboard.
We must do monitoring via device discovery just like we do for keyboards and mice.
Otherwise the usage of touchscreens that connect via USB or can be turned on/off
independently from the board becomes troublesome.
Change-Id: I2de3b519e8d617b0612e5df486e481bbc09b9c8c
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
| |
If it's detected, we have "mtdev" in QT_CONFIG, not in CONFIG. With
the bad test, libQt5PlatformSupport.prl would not get -lmtdev and, in
turn, the evdevtouch generic plugin would fail to link.
Change-Id: I5dab57b648e66943f98a22527717a20be35f02a4
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
|
|
|
|
|
|
|
|
|
| |
This coincidentally fixes a case of accidental BIC in qevdevtouch_p.h, where not
all users would necessarily define USE_MTDEV: having it centralized inside Qt
makes this now, blessedly, impossible.
Change-Id: I196a8f21742830705759aa917a823afdc94ba2b5
Done-with: Michael Brasser <michael.brasser@jollamobile.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
| |
Change-Id: Ie8eaa71bee87654c21218a23efd7e9d65b71f022
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
| |
Change-Id: Ic93c8dc5aaad3973e4d4fc6bb3b70ad7c0a632b0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
|
Also wraps various string literals with QLatin1String.
Change-Id: Ia0681bfae00006d9e9ad51f05d0e0d0f45cf2cec
Reviewed-by: Laszlo Agocs <laszlo.p.agocs@nokia.com>
Reviewed-by: Donald Carr <donald.carr@nokia.com>
|