KWin/Wayland Development: Difference between revisions
< KWin
Mgraesslin (talk | contribs) Created page with "= 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 KSnap..." |
No edit summary |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
= 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 = | = Security = | ||
* Virtual Keyboard need to be somehow controlled by KWin to ensure that no input can be injected | * 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 | * 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? | * 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 | |||
Latest revision as of 12:44, 12 April 2018
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