| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Change-Id: I9a3285dc5bddd848ec557287c4641d9edce752a9
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
|
|
|
|
|
|
| |
Conforming to the Qt project directory structure.
Change-Id: I452867fabc88e9594fa26f944b5d3e1ca4ffc720
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
|
|
|
|
|
|
|
|
|
| |
We cannot just assume all clients implement the same version of the
various interfaces as the compositor does. Keep track of them, and
react accordingly when creating a resource or sending an event.
Change-Id: I9792433a14d49c5c4df0c892fc1349ce0dfb0d43
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
|
|
| |
That's a public class in Qt 5.4. Use the more appropriate CompositorWindow.
Change-Id: Id7de20c7e2d5b373f8ef9fe9a836188dc864479e
Reviewed-by: Giulio Camuffo <giulio.camuffo@jollamobile.com>
|
|
|
|
|
|
|
|
|
|
| |
Currently a global is bound with the version the interface has in the xml
file. This is a problem for apps that explicitly link to libwayland-client
because they may link to a newer libwayland, so the version of some interface
may be higher than the one that it is actually implemented.
Change-Id: Id0dbe6c0f1e05fe91954b9d8d9472d42d2053cdc
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
With a SHM client, if a null attach happened, then the old buffer would be
deleted but left with a dangling pointer which would be deleted again on the
destructor.
This was revealed by tst_dialog.
Change-Id: I89e22487e7ec982789a4b7dfd45e5db7db3222d1
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
|
|
|
|
|
| |
Change-Id: Ibf6facdd1fba72c2f9741e49cf2c83f9b4136ffc
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
|
|
|
|
|
| |
Change-Id: I6ba4731abbf892f8f7bb0a0d5b30bba8082e67be
Reviewed-by: Giulio Camuffo <giulio.camuffo@jollamobile.com>
|
|
|
|
|
|
|
|
| |
setCursorSurface may be invoked with a null surface.
This was exposed by tst_QWidget::destroyBackingStore.
Change-Id: Iac1ef6d2f17e5ee6a693ddbf3875b743bde2ded1
Reviewed-by: Giulio Camuffo <giulio.camuffo@jollamobile.com>
|
|
|
|
|
| |
Change-Id: I76303b8640f013167159d94e8db7d673358c4983
Reviewed-by: Giulio Camuffo <giulio.camuffo@jollamobile.com>
|
|
|
|
|
| |
Change-Id: I1072d6efa059e01d8dcba98c90320bcc242d1c0f
Reviewed-by: Giulio Camuffo <giulio.camuffo@jollamobile.com>
|
|
|
|
|
| |
Change-Id: Id73f8ddffe00359f38c634fc88b1f81ac5638653
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
The previous virtual method initShell() was not working because
it was called from QWaylandCompositor constructor.
Replace that with a mthod to create the default shell to be
manually called by the compositors if they so choose.
Change-Id: I35a1dc0edfaf4237ca47b532645ac0d95752311c
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Different compositors may need different shell behaviors, or
even different shell protocols. A smartphone compositor, for
example, may want to make wl_shell_surface::set_popup or
other requests noop, because they don't make sense in the
formfactor, or it may even want to not implement wl_shell_surface
at all, but some smartphone_shell_surface.
A compositor may define its own shell implementation by overriding
QWaylandCompositor::initShell(), and creating there its interface
instance. The default implementation still creates the built-in
wl_shell_surface implementation.
Change-Id: I143b0cd4e30e31d4051ada6e562d486d9bf1a751
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
|
|
|
|
|
|
|
|
|
|
| |
QtQuick compositors already use a view class (QWaylandSurfaceItem),
so add a new QWaylandSurfaceView, which is subclassed by
QWaylandSurfaceItem, and move the view related methods of QWaylandSurface
there. A QWaylandSurface can have many views.
Change-Id: I7e92fe1f7e9d252f5f40a3097feabb5f3318b03a
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
|
|
|
|
|
|
|
|
| |
A surface without any attached shell surface should never be mapped,
so make the latter set the mapped state on the surface.
Change-Id: If09bd9eebecd6e0a52f862cb866d85aec403c3a0
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current way buffers are handled is sub-optimal. They are hidden
inside QtWayland::Surface and the actual renderer, be it QtQuick or
anything else, cannot get a direct hold of them, nor it can directly
control when the underlying textures are created or deleted.
The main additions in this commit are the splitting of the QtQuick
code path and the new QWaylandBufferRef and QWaylandBufferAttacher
classes.
QWaylandBufferRef allows a renderer to retain a reference
to a wl_buffer even after the underlying Surface discarded it.
That allows the renderer to directly decide when to destroy the texture
of the buffer.
QWaylandBufferAttacher is a pure virtual class which must be implemented
by the renderer. Instances of it will be assigned to the QWaylandSurfaces,
created. Its attach() virtual method will then be called when a new buffer
is committed to the surface. The renderer can then choose to immediately
create a texture or wait for some later time. It is its responsibility to
create and destroy the GL texture, it will not happen automatically.
This functionality is implemented for QtQuick in the new QWaylandQuickCompositor
and QWaylandQuickSurface classes.
Change-Id: I674b4e5fb8c65c3b1c582e33ff3a0b0e45f2acc9
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The QWidget API isn't well fit for a Wayland compositor, and does
not have any advantage over a QWindow, which can also draw using
QPainter. Besides the current implementation doesn't work properly,
and no one seems to be interested in fixing it.
Change-Id: Id1c337506af48e1d1fdd8d14f0ed637d299702f3
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
It must redraw, even if it doesn't actually redraw anything, irrespective
of the fact that a attach/damage has come or not. Just calling frame();commit()
is perfectly valid.
Change-Id: If298654b8a7cb7c954cfbad8618f23134731cb9f
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
|
|
|
| |
We want to make sure the events reach the clients asap.
Change-Id: I0783c6be4f4412fd5f3665faec1e57d141291ce7
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
| |
Change-Id: I8efbda3e5266c5668b2461429a21d900e2ecd175
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When there is a rendering thread, like with QtQuick compositors,
there is a race condition where the frame callbacks are sent before
the last buffer the client sent is released.
Assume the following scenario:
attach(B1)/frame(F1)/commit()...frame started...attach(B2)/frame(F2)/
commit()...frame finished.
On frame finished the callback just installed is emitted before the
buffer B2 is being used and B1 released. That forces the client to
allocate a third buffer to draw the next frame.
Now, do not send out the frame callbacks until a new frame started.
The successive draw will release B1, use the new B2 and than send out F2.
Change-Id: I5743c7baf9fdd3cde28c5f594ff646c06abb74b7
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
A client calling attach(A);commit();attach(B);commit() should result
in its back buffer be set to B, and A be discarded.
If the client wants to have a queue it should keep it client side or
a protocol extension tailored for that purpose should be developed.
Change-Id: Ia0048f311504d85821df9f5b9225887801efec71
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/compositor/wayland_wrapper/qwlsurface.cpp
Change-Id: I3b6a4af41f272d3dc7fc920ba2542f2dd7978175
|
| |
| |
| |
| |
| | |
Change-Id: Ifb6e2456c781e80f84e27e68c3e279ea993f9307
Reviewed-by: Andy Nichols <andy.nichols@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: Idb0ad89c47fdca7249022049c00063a4d0bac95a
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/client/hardwareintegration/qwaylandclientbufferintegrationplugin_p.h
src/client/hardwareintegration/qwaylandserverbufferintegrationplugin_p.h
src/compositor/hardware_integration/qwaylandclientbufferintegrationplugin.h
src/compositor/hardware_integration/qwaylandserverbufferintegrationplugin.h
src/plugins/hardwareintegration/client/brcm-egl/main.cpp
src/plugins/hardwareintegration/client/drm-egl-server/main.cpp
src/plugins/hardwareintegration/client/wayland-egl/main.cpp
src/plugins/hardwareintegration/client/xcomposite-egl/main.cpp
src/plugins/hardwareintegration/client/xcomposite-glx/main.cpp
src/plugins/hardwareintegration/compositor/brcm-egl/main.cpp
src/plugins/hardwareintegration/compositor/drm-egl-server/main.cpp
src/plugins/hardwareintegration/compositor/wayland-egl/main.cpp
src/plugins/hardwareintegration/compositor/xcomposite-egl/main.cpp
src/plugins/hardwareintegration/compositor/xcomposite-glx/main.cpp
Change-Id: I9a9b418075970dd334babc3590b9b0315c2afb0d
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: I888ef46381342af61a48c6e542ec564e67adfe13
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Improve the way wl_surface's frame callbacks are handled. The sooner
they are sent the better is for the clients, as they have more time to
render the next frame, but reducing the time for the compositor to
render its frame. The best compromise is probably to send them out
after the compositor has issued its GL calls but before calling
eglSwapBuffers(), and before the GPU actually draws anything.
Rename the function to send the callbacks to only reflect its purpose,
leaving the compositors free to choose when they want to send them.
Change-Id: Ifcdfcad9e54b4d07d5c087898123ac724395a194
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
| |/
|/|
| |
| |
| |
| |
| |
| | |
Fixes build break when built on linux with wayland libs installed
via pkg manager.
Change-Id: I17be64e702d07e817a2e34e76ddbe8dde064f3d2
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The surface now has a distinct back and front buffer. Front means it
is on the screen and being used as a texture. Back means it should be
put to screen in the next updatePaintNode().
For the purpose of QML and GUI-thread properties, the 'back' buffer is
what contains the correct properties as it is what it will eventually
be rendered with. For the purpose of rendering, the front buffer
contains the right texture. If no back buffer is present, then there
was no changes and front buffer applies to both.
The Surface's buffer queue has been updated to only fire damage and
advance once we swap back buffer to front buffer which happens during
updatePaintNode(). The fact that the buffer advancing happens during
sync also means that we are releasing buffers back to the client as
soon as another buffer is ready to be displayed in the compositor.
This is "half a frame" earlier than the current implementation (which
releases after the next swap). We consider this safe because:
- The compositor has a new buffer to display and does not need the
old one.
- If the GPU is not done rasterizing the scanout buffer for the
previous frame, it should hold a read-lock on the buffer so
preventing the client from starting a render to it. If this
assumption fails on any hardware we can make the time of
buffer-advance optional. Either during "sync" or during "after
rendering" as it is today, but "after rendering" will not offer any
guarantee, just more time, resulting in a higher chance of the
buffers being ready. Aka, without an internal read-lock and no
fence mechanism, there is no guarantee.
Texture cleanup is now explicit as we have a well defined location to
clean up textures, during updatePaintNode(). This avoids cleanup
issues which previously existed as buffer cleanup was happening on the
GUI thread. Surface and Buffer destruction coming over wayland is
queued up in compositor and handled before the next "sync", when it is
safe to do so.
The change also removes doUpdate, postBuffer and frameSwappedInternal
as these are no longer used. Direct rendering will need to be
considered in a new light with the new buffering scheme, and anyway
needs work.
Change-Id: I2db0385b4b8859f96caba374f3530448178e1473
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using the texture cache is wrong for two reasons:
1) it's a private API
2) we will get new QImages all the time so the caching is effectively useless
The main problem here is that the textures were not deleted which embedded
systems do not really like.
Change-Id: Ia9bafb0df58491f5ceb08ddcd9bf11b7c6137c83
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|/
|
|
|
|
|
| |
Fixes linking on some toolchains where linkage is a bit more restrictive.
Change-Id: I7ec3f2bde009ce6d2e20e4b500a96d234cdcc301
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
|
|
|
| |
It mapps closer to the underlying OpenGL architecture
Change-Id: I4e0dca4d54670846488c86df2a0fa0c58d49734d
Reviewed-by: Jan Arne Petersen <jan.petersen@kdab.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
| |
Change-Id: I4399681dc91ca20a84177247379cf6eafd2b6a6e
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The context is not passed anymore to texture() and similar functions since
they have to use the current context anyhow.
createTextureFromBuffer() becomes bindTextureToBuffer() which is called
with the texture bound. The integration can also provide its own texture in
case the one created and managed by the surfacebuffer is not suitable.
Change-Id: I1bfc4fe35c0e3db6081b47c551f20f4bca9aa04e
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
| |
Change-Id: I33950ae923f5edba4faeca26cc0656be0255e403
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
| |
Specify precision to make the shader working.
Change-Id: I055fe47e1073403dc981274236fa82e091e0eca4
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
Reviewed-by: Andy Nichols <andy.nichols@digia.com>
|
|
|
|
|
|
|
|
| |
This simplifies the creation and use of ExtensionFlags.
Change-Id: Ia72bbc3f712759b231d8543a4f13ef2fdf6260f3
Reviewed-by: Jan Arne Petersen <jan.petersen@kdab.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
| |
Handy when Quick rendering that needs stencil is performed in-process.
Change-Id: Ic6593150ddde217fa0ad257f889eda131fb09095
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
|
|
|
|
|
|
|
|
| |
Add an ExtensionFlag enum to QWaylandCompositor and allow to specify
extensions to enable via the constructor.
Change-Id: If1a691232134034ba4055a9ed280bc211dcaebe8
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Wayland output defines refresh rate in millihertz (int) while Qt uses Hz
(float). Make sure all integer APIs are using millihertz, and covert Hz
values to mHz when passing from Qt.
Change-Id: I5886f5618680d99db6fc106dd7b8998b00a2face
Reviewed-by: Jan Arne Petersen <jan.petersen@kdab.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Andy Nichols <andy.nichols@digia.com>
|
|
|
|
|
|
|
|
| |
Explicitly adding the QT += v8 in .pro files is
now an error, so it has been removed.
Change-Id: Ib8f6fc497790f90da5c36e18337a8aa74be3b06b
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
|
|
|
|
|
|
|
| |
Change-Id: I69944a417d40ad39d261b58a35eee4f84156995f
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Andy Nichols <andy.nichols@digia.com>
|
|
|
|
|
| |
Change-Id: I245abe09f60cb24e435af53ad7b2d2142f91b55c
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
| |
Change-Id: Iacbd83d5551b3a5c2152ff80bb0085ce3f853306
Reviewed-by: Andy Nichols <andy.nichols@digia.com>
|
|
|
|
|
| |
Change-Id: Iad80149278edd670fd55a3a6c1b4975ac81d7f59
Reviewed-by: Andy Nichols <andy.nichols@digia.com>
|
|
|
|
|
| |
Change-Id: I1f363238232c145941940fe203b110f8855d8c26
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the QtCompositor library and API do not follow the Qt API
naming conventions. This commit intends to fix these inconsistencies.
filenames start with q
headers containing private API's end in _p
public API classes begin with Q
use the qt namespace macros where necessary
Wayland namespace is now QtWayland
wayland_wrapper classes are now private API's
It's important to make these changes not just for stylistic reasons, but
also because when qmake builds the module in checks for these
conventions to determine how to deploy the include files.
Change-Id: I8bfadeceda92a0f52cb73c704551da75540e7587
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The QtCompositor API is to be considered experimental
in Qt 5.1 and thus it should be disabled from being
built by default. If the qmake variable CONFIG
contains "wayland-compositor" then the QtCompositor
API will be built.
Change-Id: If10f5a688749f31338a80be45bbec22a0f2d12da
Reviewed-by: Pier Luigi Fiorini <pierluigi.fiorini@gmail.com>
Reviewed-by: Jørgen Lind <jorgen.lind@gmail.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
|