Add note about fullscreen surfaces, misc edits.

diff --git a/NOTES b/NOTES
index 61ee877..8c49bac 100644 (file)
--- 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