QtCS2021 - Wayland client BOF: Difference between revisions
m (Volker Hilsheimer moved page Wayland client BOF to QtCS2021 - Wayland client BOF) |
(→Notes) |
||
| Line 7: | Line 7: | ||
==Session Owners== | ==Session Owners== | ||
* Eskil Abrahamsen Blomfeldt (eskil.abrahamsen-blomfeldt@qt.io) | *Eskil Abrahamsen Blomfeldt (eskil.abrahamsen-blomfeldt@qt.io) | ||
==Notes== | ==Notes== | ||
Things to discuss: | |||
- The upcoming "is occluded" protocol upstream (sounds amazing): | |||
<nowiki>https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99</nowiki> | |||
- everyone agrees. | |||
- The new Qt shell - what's the story? | |||
Just for embedded. We (KDE) can ignore it. | |||
- Our LayerShellQt library - creating API upstream and including XdgPositioner | |||
- we need to configure properties before creating the shell | |||
- we create the shell on show | |||
- which doesn't give a hook | |||
- either need to change qwaylandwindow (which is hard due to reasons) | |||
-or set properties in advance | |||
Agreed it would be good to have support for this in Qt. | |||
- DataDevice V3 (can I poke for review) | |||
Poke noted by Qt people, they'll follow up. Maybe I need to check too. | |||
- Activation (poke? ) | |||
- embedded users | |||
Poke noted. | |||
Do we need it in compositors? Mixed results. Agreement that we can have a client-side implementation first and implement compositor-side when someone asks for it. | |||
Generally lots of agreement that we need to start adding public API: https://bugreports.qt.io/browse/QTBUG-94729 | |||
> Qt Client side decoration paths; Can we shove them into a subsurface (or 4)? I think it would be cleaner | |||
Everyone agrees. We need to be careful if we need to use place below as we might hit compositor bugs. | |||
We should 4-tile though, it'll be more performant. Maybe we can make a POC and have Jan confirm it works and finish the details as he's the main user. | |||
> Exposing fractional scaling? Good idea? | |||
Yeah. Lets give it a go. How do we handle values that aren't multiples of buffer size? enums / common denominator? It will have issues, but no more than X11...lets give it a go and see. | |||
Latest revision as of 11:28, 23 June 2021
Session Summary
Synchronization on topics concerning the Wayland client plugin with Qt, KDE and others.
Session Owners
- Eskil Abrahamsen Blomfeldt (eskil.abrahamsen-blomfeldt@qt.io)
Notes
Things to discuss:
- The upcoming "is occluded" protocol upstream (sounds amazing):
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99
- everyone agrees.
- The new Qt shell - what's the story?
Just for embedded. We (KDE) can ignore it.
- Our LayerShellQt library - creating API upstream and including XdgPositioner
- we need to configure properties before creating the shell
- we create the shell on show
- which doesn't give a hook
- either need to change qwaylandwindow (which is hard due to reasons)
-or set properties in advance
Agreed it would be good to have support for this in Qt.
- DataDevice V3 (can I poke for review)
Poke noted by Qt people, they'll follow up. Maybe I need to check too.
- Activation (poke? )
- embedded users
Poke noted.
Do we need it in compositors? Mixed results. Agreement that we can have a client-side implementation first and implement compositor-side when someone asks for it.
Generally lots of agreement that we need to start adding public API: https://bugreports.qt.io/browse/QTBUG-94729
> Qt Client side decoration paths; Can we shove them into a subsurface (or 4)? I think it would be cleaner
Everyone agrees. We need to be careful if we need to use place below as we might hit compositor bugs.
We should 4-tile though, it'll be more performant. Maybe we can make a POC and have Jan confirm it works and finish the details as he's the main user.
> Exposing fractional scaling? Good idea?
Yeah. Lets give it a go. How do we handle values that aren't multiples of buffer size? enums / common denominator? It will have issues, but no more than X11...lets give it a go and see.