This introduces a dependency on ts_get_eventpath(), which is only
available in tslib 1.15 and newer. This raises the required version to
an unneeded level, so just drop the debug message if the API is not
available.

Change-Id: I4a1cd7abec8d139e70555506d9d21edacf0f4d71
Fixes: QTBUG-78867
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Fabian Vogt <fabian@ritter-vogt.de>

Fixes: QTBUG-57909
Change-Id: I3ffe8ad25b97c6d29ea925707a3878d0e47ec9ac
Reviewed-by: BogDan Vatra <bogdan@kdab.com>

Android 5 doesn't extract the files from libs folder unless they are prefixed with "lib".
This patch sets a proper name for the plugin which will make gdb happy and it will also
avoid any name clashes.
If we rename the plugins when we copy them, gdb won't find them, therefore it can't load their
symbols.
On Android all the libs are in a single folder, so to make sure we don't have any name clashes,
we are prefixing the plugin name with it's relative path to qt folder (we replace / with _).

Fixes: QTBUG-78616
Change-Id: I7e0e67d65448532769d69f46b1856c029e2cf5cb
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>

Task-number: QTBUG-78862
Change-Id: If278bd55530081cbbdbab8dd6e14d86e28da558e
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

Forcing users to go through a QVector, when in practice they almost
always want to source the data from an initializer list, a QVarLengthArray,
or a plain C array, is not ideal. Especially since we can reason about
the maximum number of elements in the vast majority of use cases for all
the affected lists. QRhiResource is also not copyable so we do not need
the usual machinery offered by containers. So switch to a
QVarLengthArray.

Note that a resource is not a container. The only operations we are
interested in is to be able to source data either via an initializer
list or by iterating on something, and to be able to extract the data,
in case a user wishes to set up another resource based on the existing
one.

In some cases a QVector overload is kept for source compatibility with
other modules (Qt Quick). These may be removed in the future.

Also do a similar QVector->QVarLengthArray change in the srb-related
data in the backends.

Change-Id: I6f5b2ebd8e75416ce0cca0817bb529446a4cb664
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

Sad to see this go since the d pointer pattern with implicit sharing
would have been perfect for this class, had this been a public API.

However, as binary compatibility will not be a concern for QRhi classes,
it is wasteful to allocate memory on every QRhiShaderResourceBinding.
This allows users, such as Qt Quick, to use QRhiShaderResourceBinding as
a cheap, simple, value class, without having to invent their own
alternatives in performance critical places.

The change brings a not insignficant improvement in certain qmlbench scenes
(the ones with thousands of unbatched geometry nodes).

Change-Id: I6d1dced6498d9ad625f90ead78bc0a417ea99ed8
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

The expectation for it is to function identically to what we get with
QOpenGLShaderProgram. (same environment variables, same logging
categories, etc.).

QOpenGLProgramBinaryCache is now shared between the QOpenGL convenience
classes (like QOpenGLShaderProgram) and QRhi. To achieve more modularity
and to prepare for QOpenGLShaderProgram and friends moving out of QtGui,
this class cannot depend on QOpenGLShader* anymore. This involves adding
some minor conversions between QRhi and QOpenGL enums for example.

Change-Id: I2f4664e074823ea536281aea8006a6db159a7381
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

One of our compilers for emscripten coerces all signaling NaNs to
quiet ones, so won't do any actual signaling. Anyone relying on them
to do so shall be disappointed, so it's better that they know about it
at compile-time - or, at least, have the ability to find it out.

Put the signaling NaN producers (and remaining (test) code using them)
under the control of a feature that's disabled when numeric_limits
claims double has no signaling NaN. Assume the bootstrap library
doesn't need signaling NaNs. Sadly, until C++20 <bit>, there's no
contexpr way to test that alleged signalling and quiet NaNs are
actually distinct.

Added some auto-tests for signaling NaN, including that it's distinct
from quiet NaN. Any platform on which the last fails should disable
this feature.

Task-number: QTBUG-77967
Change-Id: I57e9d14bfe276732cd313887adc9acc354d88f08
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>

 Conflicts:
	src/corelib/global/qrandom.cpp
	src/corelib/io/qfileinfo.cpp
	src/corelib/kernel/qeventdispatcher_win.cpp
	src/corelib/kernel/qeventdispatcher_win_p.h
	src/gui/text/qfontdatabase.cpp
	src/platformsupport/fontdatabases/mac/qcoretextfontdatabase.mm
	src/plugins/platforms/windows/qwindowsglcontext.cpp
	src/testlib/qtestcase.cpp

Done-With: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Done-With: Edward Welbourne <edward.welbourne@qt.io>
Change-Id: I4893212471aa24be804c989a581810e2f714545c

Revert surfacePixelSize() to be a getter only. With Metal this will
mean returning the "live" layer size (and so not the
layer.drawableSize), which is in line with what we expect with other
backends.

Instead, we leave it to the swapchain's buildOrResize() to "commit"
the size by setting drawableSize on the layer. With typical
application or Qt Quick logic this ensures that layer.drawableSize is
set once and stays static until we get to process the next resize - on
the rendering thread.

This of course would still mean that there was a race when a client
queries surfacePixelSize() to set the depth-stencil buffer size that
is associated with a swapchain. (because that must happen before
calling buildOrResize() according to the current semantics)

That can however be solved in a quite elegant way, it turns out,
because we already have a flag that indicates if a QRhiRenderBuffer is
used in combination with (and only in combination with) a
swapchain. If we simply say that setting the UsedWithSwapChainOnly
flag provides automatic sizing as well (so no setPixelSize() call is
needed), clients can simply get rid of the problematic
surfacePixelSize() query and everything works.

Task-number: QTBUG-78641
Change-Id: Ib1bfc9ef8531bcce033d1f1e5d4d5b4984d6d69f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>

Change-Id: I5408e53f90c1c19836c400659bac15a8690c6ae8
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>

It can be important to see for example the adapter enumeration that is
printed when qt.rhi.general is enabled. Make it enabled by default in
the tests.

Change-Id: I7bd073781e176d9b17b5386c548e9f8a2e16c10f
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

Change-Id: I879b62c55e4211d3e4e1a18f6699f26e3f5de1f8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

When a layer is resized, e.g. during a window resize, the contents of
the layer may lag behind if the client doesn't fill the layer in
response to the window resize and corresponding expose event.

The default behavior is for Core Animation to stretch the content
to fill the layer, but this results in the content "jumping" back
and forth when the content then picks up the new size and fills
the layer.

Instead we tell Core Animation to fix the content to the top left
corner. If a layer is sized up without a corresponding layer contents
update this will result in missing/transparent pixels in the bottom
or right part of the layer, explicitly showing what the result of
the missing paint is. During debugging we also highlight this area
by adding a magenta background color to the layer.

Conversely, if the layer is sized down we don't need to resize it,
we can just keep the fixed top left position, and the content will
stay in place during the resize. This allows for optimizations
during window resizing, where we don't need to allocate new
buffers if the old buffer is larger than the new one.

Change-Id: I265b57e3a0ddff8bbcda3af5d670cd8c3b00b181
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>

Change-Id: I32de4610a2aebbc7e0adcad9bb3440683cae5906
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>

We should detect the cases where there's already a delegate, and
setting up the delegate before the layer is added makes sense.

Change-Id: I67896cbc96d11ce9a3826fd8aa0e5e104a83a21c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>

Change-Id: I10d972254c02de8789e64c8503861d51764a1633
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>

Change-Id: I333e2bfe4a25bfbfebef7b2ec30a600fd441c9a9
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>

Change-Id: I29881b379481287b4938e47fc06405c918aa39a3
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>

It is present in standardPixmap but missing from standardIcon resulting in
QMessageBox using the fallback PNG provided by Qt for the "No" button.

Change-Id: If4f14c7de26eb32277cd19a7be75360dba4f4e29
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>

Not much different from i.MX6, apart from switching to aarch64 and the
appropriate tune flags.

[ChangeLog][Platform Specific Changes][Linux] Added a device spec for
64-bit i.MX8 systems (Vivante graphics stack)

Change-Id: I1fe939fca87d5f3031cefbf43fa359aeeaf44752
Reviewed-by: Andy Nichols <andy.nichols@qt.io>

Forgot the _p suffix.

Change-Id: I48225418fd40d45020b016b59578fcc1944d15c0
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

Change-Id: I077ba12b406f662ba22b2f2cddf0171963335739
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>

Specify the type of the enum value SendPostedEventsWindowsTimerId
to be UINT_PTR to work with the g++ interpretation of enumeration
signedness and use the correct type for the returned timer id.

Fixes: QTBUG-78491
Change-Id: I7b3f306d3f60da7a21500ece5243ac90854ccf1a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

The test was found crashing with software rendering in Qt 5.7.

Removing the insignification revealed that there are failures
on WinRT as well, blacklist them for the moment.

Task-number: QTBUG-78802
Fixes: QTBUG-49630
Change-Id: Ib1a3efe69d7b63cdd98c6da364ab09e0e2dbdf62
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>

Change-Id: I751802d3f9f389e80cbb9aabcdb637d4742d3832
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

Fixes: QTBUG-538
Change-Id: Id06e316e7ae3d59b63b256ef565a1ad6dc5d9dd2
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>

...instead of the qt_ meta catalogs. The qt_ catalogs
are needed for backwards compatibility and depend on
translations for now deprecated modules, such as qtscript,
that might not be installed in the system. This causes
loading the translation to fail.

Instead of the qt_ catalogs, the examples should use the
translation files for the Qt modules used, here qtbase_.

Task-number: QTBUG-69203
Change-Id: I13f5a3d6653cef8379a712fbc02ec320eea4e51a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>

Various methods were undocumented and even one that was lacked a \since 5.14

Change-Id: I1e65ed1bb9c5b9de06210d7e18af36539aafc4ec
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

Change-Id: I2e6c27953ecce95df3ac4868a6d953596ba115f2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

Fixes detecting requested robustness for OpenGL < 4.0.

Fixes: QTBUG-78781
Change-Id: I6a10f3ed925dd05d5caa7d6b6e12935e27eed3e9
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>

Some AMD CPUs (e.g. AMD A4-6250J and AMD Ryzen 3000-series) have a
failing random generation instruction, which always returns
0xffffffff, even when generation was "successful".

This code checks if hardware random generator generates four consecutive
equal numbers. If it does, then we probably have a failing one and
should disable it completely.

Change-Id: I38c87920ca2e8cce4143afbff5e453ce3845d11a
Fixes: QTBUG-69423
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>

This was visible in the triquadcube test when enabling transparent window
background: the cube on the left was rendered incorrectly because alpha
was not written out due to not setting glColorMask() back to the defaults
when switching to another pipeline.

Change-Id: I7a8c94072e0b68a58fffcc8c1a200e3940dcad44
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

This class will likely be used by the OpenGL backend of QRhi as well.
Therefore, we need to make it more self-contained and independent.

Change-Id: If046ed41e25c70cc9abb45219b451f9179feaa1c
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

Task-number: QTBUG-78605
Change-Id: Icc3a9636055b5f45418da28cc05aa02e19370c02
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

This will also cause clearing to 0,0,0,0.

Essential in order to allow fast testing of window transparency
issues in combination with QRhi and the various backends.

Change-Id: Iee2763c1d06f1d3e5d59a9142abaf30fab1dc543
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

With OpenGL a scissor (or viewport) rectangle is not allowed to have a negative
width or height. Everything else is allowed. This is also the semantic we wish to
keep for QRhiViewport and QRhiScissor.

This raises some problems. For instance, when we do bottom-left - top-left
rectangle conversion, the case of partially out of bounds rects needs to be
taken into account.

Otherwise, Qt Quick ends up in wrong scissoring in certain cases, typically when
the QQuickWindow size is decreased so the content does not fit because that will
then start generating negative x, y scissors for clipping (which is perfectly
valid but the QRhi backends need to be able to deal with it)

Then there is the problem of having to clamp width and height carefully, because
some validation layers for some APIs will reject a viewport or scissor with
partially out of bounds rectangles.

To verify all this, add a new manual test, based on the cubemap one. (cubemap was
chosen because that is an ideal test scene as it fills the viewport completely, and
so it is visually straightforward when a scissor rectangle is moving around over it)

Fixes: QTBUG-78702
Change-Id: I60614836432ea9934fc0dbd0ac7e88931f476542
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

Since iOS 13, the cascade list for the default UI font contains
meta-families for several writing systems, such as CJK. Since
these font families were never populated to the database, we ignored
them in Qt, and thus got missing glyphs for the characters in question.

The fix is to make sure these fonts are populated in the database.
It contains a partial backport of 922d1950

,
which adds the qt_isFamilyPopulated() accessor to allow us to check
if the family has been populated in the font database. In Qt 5.14,
there is public API for this in QPlatformFontDatabase, so this is
a temporary resolution until then.

Fixes: QTBUG-77467
Change-Id: Ia9ebb8a19ad2367eb764ae1496a52966b465336b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>

Spotted in API change review, thanks to Albert Astals Cid.
Also added documentation of this method.

Change-Id: I2ef2c526a98b571a3cb3bb5f93d1952b1b0d63a9
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>