NOTES

   1
   2 KEYWORDS:
   3
   4 Wayland is a nano display server, relying on drm modesetting, gem
   5 batchbuffer submission and hw initialization generally in the kernel.
   6 Wayland puts the compositing manager and display server in the same
   7 process.  Window management is largely pushed to the clients, they
   8 draw their own decorations and move and resize themselves, typically
   9 implemented in a toolkit library.  More of the core desktop could be
  10 pushed into wayland, for example, stock desktop components such as the
  11 panel or the desktop background.
  12
  13 The actual compositor will define a fair bit of desktop policy and it
  14 is expected that different use cases (desktop environments, devices,
  15 appliances) will provide their own custom compositor.
  16
  17 It is still designed with a windowed type of desktop in mind, as
  18 opposed to fullscreen-all-the-time type of interface, but should be
  19 useful wherever several processes contribute content to be composited.
  20
  21 Current trends goes towards less and less rendering in X server, more
  22 hardware setup and management in kernel and shared libraries allow
  23 code sharing without putting it all in a server.  freetype,
  24 fontconfig, cairo all point in this direction, as does direct
  25 rendering mesa.
  26
  27 Client allocates DRM buffers, draws decorations, and full window
  28 contents and posts entire thing to server along with dimensions.
  29
  30 Everything is direct rendered and composited.  No cliprects, no
  31 drawing api/protocl between server and client.  No
  32 pixmaps/windows/drawables, only surfaces (essentially pixmaps).  No
  33 gcs/fonts, no nested windows.  OpenGL is already direct rendered,
  34 pixman may be direct rendered which adds the cairo API, or cairo
  35 may gain a GL backend.
  36
  37 Could be a "shell" for launching gdm X server, user session servers,
  38 safe mode xservers, graphics text console.  From gdm, we could also
  39 launch a rdp session, solid ice sessions.
  40
  41 All surface commands (copy, attach, map=set quads) are buffered until
  42 the client sends a commit command, which executes everything
  43 atomically.  The commit command includes a cookie, which will be
  44 returned in an event generated by the server once the commit has been
  45 executed.  This allows clients to throttle themselves against the
  46 server and implement smooth animations.
  47
  48
  49 ISSUES:
  50
  51 Include panel and desktop background in wayland?
  52
  53 How does clients move their surfaces? set a full tri-mesh every time?
  54
  55 How does the server apply transformations to a surface behind the
  56 clients back? (wobbly, minimize, zoom)  Maybe wobble is client side?
  57
  58 How do apps share the glyph cache?
  59
  60 Input handling - keyboard focus, multiple input devices, multiple
  61 pointers, multi touch.
  62
  63 Drawing cursors, moving them, cursor themes, attaching surfaces to
  64 cursors.  How do you change cursors when you mouse over a text
  65 field if you don't have subwindows?
  66
  67 synaptics, 3-button emulation, xkb, scim
  68
  69 changing screen resolution, adding monitors.
  70
  71 What to do when protocol out buffer fills up?  Just block on write
  72 would work I guess.  Clients are supposed to throttle using the bread
  73 crumb events, so we shouldn't get into this situation.
  74
  75 When a surface is the size of the screen and on top, we can set the
  76 scanout buffer to that surface directly.  Like compiz unredirect
  77 top-level window feature.  Except it won't have any protocol state
  78 side-effects and the client that owns the surface won't know.  We lose
  79 control of updates.  Should work well for X server root window under
  80 wayland.
  81
  82 Throttling/scheduling - there is currently no mechanism for scheduling
  83 clients to prevent greedy clients from spamming the server and
  84 starving other clients.  On the other hand, now that recompositing is
  85 done in the idle handler (and eventually at vertical retrace time),
  86 there's nothing a client can do to hog the server.  Unless we include
  87 a copyregion type request, to let a client update it's surface
  88 contents by asking the server to atomically copy a region from some
  89 other buffer to the surface buffer.
  90
  91 Atomicity - we have the map and the attach requests which sometimes
  92 will have to be executed atomically.  Moving the window is done using
  93 the map request and will not involve an attach requet.  Updating the
  94 window contents will use an attach request but no map.  Resizing,
  95 however, will use both and in that case must be executed atomically.
  96 One way to do this is to have the server always batch up requests and
  97 then introduce a kind of "commit" request, which will push the batched
  98 changes into effect.  This is easier than it sounds, since we only
  99 have to remember the most recent map and most recent attach.  The
 100 commit request will generate an corresponding commit event once the
 101 committed changes become visible on screen.  The client can provide a
 102 bread-crumb id in the commit request, which will be sent back in the
 103 commit event.
 104
 105  - is batching+commit per client or per surface?  Much more convenient
 106    if per-client, since a client can batch up a bunch of stuff and get
 107    atomic updates to multiple windows.  Also nice to only get one
 108    commit event for changes to a bunch of windows.  Is a little more
 109    tricky server-side, since we now have to keep a list of windows
 110    with pending changes in the wl_client struct.
 111
 112  - batching+commit also lets a client reuse parts of the surface
 113    buffer without allocating a new full-size back buffer.  For
 114    scrolling, for example, the client can render just the newly
 115    exposed part of the page to a smaller temporary buffer, then issue
 116    a copy request to copy the preserved part of the page up, and the
 117    new part of the page into the exposed area.
 118
 119  - This does let a client batch up an uncontrolled amount of copy
 120    requests that the server has to execute when it gets the commit
 121    request.  This could potentially lock up the server for a while,
 122    leading to lost frames.  Should never cause tearing though, we're
 123    changing the surface contents, not the server back buffer which is
 124    what is scheduled for blitting at vsync time.
 125
 126
 127 RMI
 128
 129 The wayland protocol is a async object oriented protocol.  All
 130 requests are method invocations on some object.  The request include
 131 an object id that uniquely identifies an object on the server.  Each
 132 object implements an interface and the requests include an opcode that
 133 identifies which method in the interface to invoke.
 134
 135 The server sends back events to the client, each event is emitted from
 136 an object.  Events can be error conditions.  The event includes the
 137 object id and the event opcode, from which the client can determine
 138 the type of event.  Events are generated both in repsonse to a request
 139 (in which case the request and the event constitutes a round trip) or
 140 spontanously when the server state changes.
 141
 142 the get_interface method is called on an object to get an object
 143 handle that implements the specified interface.
 144
 145
 146 EMBEDDING OTHER WINDOWS
 147
 148 X11 lets clients embed windows from other clients other copy pixmap
 149 contents rendered by another client into their window.  This is often
 150 used for applets in a panel, browser plugins and similar.  Wayland
 151 doesn't directly allow this, but clients can communicate GEM buffer
 152 names out-of-band, for example, using d-bus or as command line
 153 arguments when the panel launches the applet.  Another option is to
 154 use a nested wayland instance.  For this, the wayland server will have
 155 to be a library that the host application links to.  The host
 156 application will then pass the wayland server socket name to the
 157 embedded application, and will need to implement the wayland
 158 compositor interface.  The host application composites the client
 159 surfaces as part of it's window, that is, in the web page or in the
 160 panel.  The benefit of nesting the wayland server is that it provides
 161 the requests the embedded client needs to inform the host about buffer
 162 updates and a mechanism for forwarding input events from the host
 163 application.