KWayland for KF6
Open, NormalPublic

Description

Early list of ideas/tasks:

  • Our protocol extensions:
    • number versioned: for example org_kde_kwin_outputdevice_v1
    • shorten name: kde_outputdevice_v1
  • xdg-shell:
    • Drop ShellClient
    • Drop XdgShellV5
    • Rename XdgShell classes to match the spec used in V6/Stable rather than trying to retrofit into V5
  • Should KWayland (Server part) be moved out of Frameworks into a Plasma lib?
  • Output and output device interfaces:
    • Improve synchronization of wl_output and xdg-output events
    • Composite output and xdg-output into output device (handle enable internally)
  • Should KWin endFrame calls be explicitly sent from the compositor?
romangg created this task.Oct 21 2019, 3:03 PM
romangg triaged this task as Normal priority.

@romangg arguably our protocols used by KF5 clients shouldn't break. Though for things only used by Plasma, pragmantically it should be fine.

  • Drop ShellClient
  • Drop XdgShellV5
  • Rename XdgShell classes to match the spec used in V6/Stable rather than trying to retrofit into V5
romangg updated the task description. (Show Details)Oct 21 2019, 3:11 PM
zzag added a comment.Oct 21 2019, 3:38 PM

Drop ShellClient

You mean wl-shell, right?

romangg updated the task description. (Show Details)Oct 26 2019, 1:53 PM
zzag added a comment.Oct 28 2019, 10:15 AM

Should KWayland (Server part) be moved out of Frameworks into a Plasma lib?

That's a really good question!

Generally speaking, I would prefer to move KWayland::Server back into KWin and re-brand KWayland::Client to KWaylandClient, it's still a good idea to have wrappers that can be used by clients, though one could argue that setting blur region and so on can be completely encapsulated in KWindowSystem thus eliminating the need for client side wrappers.

Anyway, I would support both moving KWayland::Server into a Plasma library or directly into KWin.

zzag added a comment.Oct 28 2019, 10:18 AM

or directly into KWin.

Moving into KWin will be better for us though as we wouldn't have to worry about keeping ABI and API compatibility.

Moving into KWin will be better for us though as we wouldn't have to worry about keeping ABI and API compatibility.

If we are a lib in plasma we don't necessarily need to worry about API/ABI either. It's somewhat lib dependent.
There are advantages of being separate as then the server side can be used for unit tests of kwayland-integration or whatever.


With regards to history, the reason it's a framework is so other frameworks can use it directly. We definitely do need frameworks to have a way to make some custom wayland calls.

I would say it hasn't entirely worked out as-is as KIdleTime, KWindowSystem and KGuiAddons all ended up having a plugin system where that plugin is in plasma anyway!

*if* we make kwayland plasma local (and I'm not entirely convinced either way), we will need to either:

  • Expand KWindowSystem with everything p-f or any future app might need, adding in an abstraction layer for everything
  • Expand QtWayland extension API (through either QPlatformHeaders or their half-done extension support)
romangg updated the task description. (Show Details)Oct 28 2019, 11:16 AM
romangg updated the task description. (Show Details)Oct 28 2019, 12:14 PM