Difference between revisions of "KWin/Wayland Development"

Jump to: navigation, search
(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...")
 
Line 3: Line 3:
 
* 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

Revision as of 13:52, 20 September 2012

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

Content is available under Creative Commons License SA 4.0 unless otherwise noted.