← KWin/Wayland Development You do not have permission to edit this page, for the following reason: The action you have requested is limited to users in one of the groups: Users, Administrators, trusted, KDEDevelopers. You can view and copy the source of this page. = 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 Return to KWin/Wayland Development. Retrieved from "https://community.kde.org/KWin/Wayland_Development"