KWin/Wayland Development

From KDE Community Wiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Compositor configuration interfaces

  • Output configuration low-level via outputmanagement Wayland interface and high-level via libkscreen
  • Input devices low-level via KWin Dbus service
  • Night Color low-level via KWin Dbus service and high-level via libcolorcorrect

Security

  • Virtual Keyboard need to be somehow controlled by KWin to ensure that no input can be injected
  • Screenshots need to be restricted to KWin. Solution: move KSnapshot to KWin, remove D-Bus interface for Screenshots
  • Global Shortcut handling needs to be moved to KWin. Easy with kglobalaccel being moved to KWin, but what about non-KDE applications?

Random stuff

  • Need Video Buffer support, Phonon devs? Requires complete new coding path in compositor.
  • Usage of overlays (looking into the scene graph, selecting e.g. RGB overlay)
  • Input redirection (useful e.g. Present Windows, thumbnails)
  • event to window when it switches the screen (what about screen overlapping windows?)
  • screen management might need to move to KWin
  • one framebuffer per screen (requires changes in the compositor rendering path, could be handled in the OpenGL backend?)
  • XWayland allows us to have TFP from a Wayland buffer instead needing the XComposite. That might be very handy to go to Wayland fast. We can talk to X as we used to be. Normal KWin::Client will do, just needs different TFP path. Might cause some deadlock as KWin would be a client of X and X a client to KWin
  • PID available thanks to socket, makes killing hung Clients rather simple