Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.
Qt-contributors-summit-2014-QtCS2014 QtWayland: Difference between revisions
No edit summary |
(Categorize) |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{Cleanup | reason=Auto-imported from ExpressionEngine.}} | |||
[[Category:QtCS2014]] | |||
=QtWayland QtCS2014 Notes:= | =QtWayland QtCS2014 Notes:= | ||
==Make the QtCompositor more generic and less tied to Wayland (add Mir support).== | ==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 | 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)== | ==Move the Qt Wayland client plug-in out of the QtWayland repository (possibly into qtbase)== | ||
| Line 15: | Line 17: | ||
==Set a release time line for QtWayland + QtCompositor== | ==Set a release time line for QtWayland + QtCompositor== | ||
It | It won't be possible to release a stable QtCompositor <span class="caps">API</span> until at least Qt 5.5 because there are still needed changes to the <span class="caps">API</span> as well as a proper <span class="caps">API</span> 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.== | ==We need to be running tests to catch regressions in both the Wayland client plug-in and the QtCompositor code.== | ||
| Line 27: | Line 29: | ||
==Someone should write the QtWayland documentation== | ==Someone should write the QtWayland documentation== | ||
Yes | Yes "someone" should <span class="smiley">;-)</span> | ||
Latest revision as of 17:50, 6 January 2017
| 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 ;-)