Qt-contributors-summit-2014-QtCS2014 QtWayland

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

QtWayland QtCS2014 Notes:

Make the QtCompositor more generic and less tied to Wayland (add Mir support).

While it would be nice to have a proper compositor abstraction, it would make it more difficult to directly access the underlying buffers which is needed for further optimization. Hardware composition and direct rendering would be more difficult. There is no extension mechanism in other compositing technologies like Mir, and the ability to extend QtWayland’s protocols has been necessary so far in the existing products using QtCompositor.

Move the Qt Wayland client plug-in out of the QtWayland repository (possibly into qtbase)

The QtWayland extension mechanism (QtWaylandScanner) would need to be run for both the client and server-side libs, so it makes sense to keep the plug-in there.

Before releasing the QtCompositor API, we should make sure we have the ability to support using hardware compositors.

Gunnar Sletta will provide the patches necessary in QtWayland, QtCompositor, QtQuick to enable the use of hardware compositor layers from Qt based compositors.

Set a release time line for QtWayland + QtCompositor

It won’t be possible to release a stable QtCompositor API until at least Qt 5.5 because there are still needed changes to the API as well as a proper API review. QtCompositor will continue to be marked as experimental. We will however push to release the QtWayland module with the Wayland client plug-in with Qt 5.4. We accept that there will be some “oddities” with Wayland clients with Qt (Qt applications running on the Weston reference compositor), but QtCreator should be usable inside of Weston for us to consider our Wayland client support ready for release.

We need to be running tests to catch regressions in both the Wayland client plug-in and the QtCompositor code.

The QtWayland module should at the very least be running non-blocking build tests. We should also be running the QtBase GUI tests on the wayland client plug-in (and we should be running the Weston compositor on the CI machine to do so). Andrew Knight has volunteered to make sure that any tests written of QtWayland is added the the CI infrastructure. Eventually we should also be doing tests on your QtCompositor code as well because most changes made to the client will affect the compositor (and vice-versa).

We need a wiki page that contains known SHA1 + Wayland version combinations known to work with the QtCompositor API

This is a temporary solution to the problem that people are releasing products based on an unreleased product. Once we have a proper QtCompositor release this wont be an issue, but until then the wiki page on the QtProject wiki is a good solution.

Someone should write the QtWayland documentation

Yes “someone” should ;-)