From 23fceb1cf3ca0840a49e80a084d1299d0cf4520b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kristian=20H=C3=B8gsberg?= Date: Mon, 13 Oct 2008 22:51:56 -0400 Subject: [PATCH] Add note about fullscreen surfaces, misc edits. --- NOTES | 37 ++++++++++++++++++++++++++----------- 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/NOTES b/NOTES index 61ee8779..8c49bacd 100644 --- a/NOTES +++ b/NOTES @@ -2,16 +2,21 @@ KEYWORDS: Wayland is a nano display server, relying on drm modesetting, gem -batchbuffer submission and hw initialization generally in the -kernel. Wayland is compositing manager and display server in one -process. window management is largely pushed to the clients, they -draw their own decorations and move and resize themselves, -typically implemented in a library. more of the core desktop could -be pushed into wayland, for example, stock desktop components such -as the panel or the desktop background. +batchbuffer submission and hw initialization generally in the kernel. +Wayland puts the compositing manager and display server in the same +process. Window management is largely pushed to the clients, they +draw their own decorations and move and resize themselves, typically +implemented in a toolkit library. More of the core desktop could be +pushed into wayland, for example, stock desktop components such as the +panel or the desktop background. + +The actual compositor will define a fair bit of desktop policy and it +is expected that different use cases (desktop environments, devices, +appliances) will provide their own custom compositor. It is still designed with a windowed type of desktop in mind, as -opposed to fullscreen-all-the-time type of interface. +opposed to fullscreen-all-the-time type of interface, but should be +useful wherever several processes contribute content to be composited. Current trends goes towards less and less rendering in X server, more hardware setup and management in kernel and shared libraries allow @@ -35,7 +40,10 @@ launch a rdp session, solid ice sessions. All surface commands (copy, attach, map=set quads) are buffered until the client sends a commit command, which executes everything -atomically... +atomically. The commit command includes a cookie, which will be +returned in an event generated by the server once the commit has been +executed. This allows clients to throttle themselves against the +server and implement smooth animations. ISSUES: @@ -64,6 +72,13 @@ What to do when protocol out buffer fills up? Just block on write would work I guess. Clients are supposed to throttle using the bread crumb events, so we shouldn't get into this situation. +When a surface is the size of the screen and on top, we can set the +scanout buffer to that surface directly. Like compiz unredirect +top-level window feature. Except it won't have any protocol state +side-effects and the client that owns the surface won't know. We lose +control of updates. Should work well for X server root window under +wayland. + Throttling/scheduling - there is currently no mechanism for scheduling clients to prevent greedy clients from spamming the server and starving other clients. On the other hand, now that recompositing is @@ -101,7 +116,7 @@ commit event. a copy request to copy the preserved part of the page up, and the new part of the page into the exposed area. - - This does let a client batch up an unctrolled amount of copy + - This does let a client batch up an uncontrolled amount of copy requests that the server has to execute when it gets the commit request. This could potentially lock up the server for a while, leading to lost frames. Should never cause tearing though, we're @@ -121,7 +136,7 @@ The server sends back events to the client, each event is emitted from an object. Events can be error conditions. The event includes the object id and the event opcode, from which the client can determine the type of event. Events are generated both in repsonse to a request -(in which case the requet and the event constitutes a round trip) or +(in which case the request and the event constitutes a round trip) or spontanously when the server state changes. the get_interface method is called on an object to get an object