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
   6 kernel.  Wayland is compositing manager and display server in one
   7 process.  window management is largely pushed to the clients, they
   8 draw their own decorations and move and resize themselves,
   9 typically implemented in a library.  more of the core desktop could
  10 be pushed into wayland, for example, stock desktop components such
  11 as the panel or the desktop background.
  12
  13 It is still designed with a windowed type of desktop in mind, as
  14 opposed to fullscreen-all-the-time type of interface.
  15
  16 Current trends goes towards less and less rendering in X server, more
  17 hardware setup and management in kernel and shared libraries allow
  18 code sharing without putting it all in a server.  freetype,
  19 fontconfig, cairo all point in this direction, as does direct
  20 rendering mesa.
  21
  22 Client allocates DRM buffers, draws decorations, and full window
  23 contents and posts entire thing to server along with dimensions.
  24
  25 Everything is direct rendered and composited.  No cliprects, no
  26 drawing api/protocl between server and client.  No
  27 pixmaps/windows/drawables, only surfaces (essentially pixmaps).  No
  28 gcs/fonts, no nested windows.  OpenGL is already direct rendered,
  29 pixman may be direct rendered which adds the cairo API, or cairo
  30 may gain a GL backend.
  31
  32 Could be a "shell" for launching gdm X server, user session servers,
  33 safe mode xservers, graphics text console.  From gdm, we could also
  34 launch a rdp session, solid ice sessions.
  35
  36 All surface commands (copy, attach, map=set quads) are buffered until
  37 the client sends a commit command, which executes everything
  38 atomically...
  39
  40
  41 ISSUES:
  42
  43 Include panel and desktop background in wayland?
  44
  45 How does clients move their surfaces? set a full tri-mesh every time?
  46
  47 How does the server apply transformations to a surface behind the
  48 clients back? (wobbly, minimize, zoom)  Maybe wobble is client side?
  49
  50 How do apps share the glyph cache?
  51
  52 Input handling - keyboard focus, multiple input devices, multiple
  53 pointers, multi touch.
  54
  55 Drawing cursors, moving them, cursor themes, attaching surfaces to
  56 cursors.  How do you change cursors when you mouse over a text
  57 field if you don't have subwindows?
  58
  59 synaptics, 3-button emulation, xkb, scim
  60
  61 changing screen resolution, adding monitors.
  62
  63 What to do when protocol out buffer fills up?  Just block on write
  64 would work I guess.  Clients are supposed to throttle using the bread
  65 crumb events, so we shouldn't get into this situation.
  66
  67 Throttling/scheduling - there is currently no mechanism for scheduling
  68 clients to prevent greedy clients from spamming the server and
  69 starving other clients.  On the other hand, now that recompositing is
  70 done in the idle handler (and eventually at vertical retrace time),
  71 there's nothing a client can do to hog the server.  Unless we include
  72 a copyregion type request, to let a client update it's surface
  73 contents by asking the server to atomically copy a region from some
  74 other buffer to the surface buffer.
  75
  76 Atomicity - we have the map and the attach requests which sometimes
  77 will have to be executed atomically.  Moving the window is done using
  78 the map request and will not involve an attach requet.  Updating the
  79 window contents will use an attach request but no map.  Resizing,
  80 however, will use both and in that case must be executed atomically.
  81 One way to do this is to have the server always batch up requests and
  82 then introduce a kind of "commit" request, which will push the batched
  83 changes into effect.  This is easier than it sounds, since we only
  84 have to remember the most recent map and most recent attach.  The
  85 commit request will generate an corresponding commit event once the
  86 committed changes become visible on screen.  The client can provide a
  87 bread-crumb id in the commit request, which will be sent back in the
  88 commit event.
  89
  90  - is batching+commit per client or per surface?  Much more convenient
  91    if per-client, since a client can batch up a bunch of stuff and get
  92    atomic updates to multiple windows.  Also nice to only get one
  93    commit event for changes to a bunch of windows.  Is a little more
  94    tricky server-side, since we now have to keep a list of windows
  95    with pending changes in the wl_client struct.
  96
  97  - batching+commit also lets a client reuse parts of the surface
  98    buffer without allocating a new full-size back buffer.  For
  99    scrolling, for example, the client can render just the newly
 100    exposed part of the page to a smaller temporary buffer, then issue
 101    a copy request to copy the preserved part of the page up, and the
 102    new part of the page into the exposed area.
 103
 104  - This does let a client batch up an unctrolled amount of copy
 105    requests that the server has to execute when it gets the commit
 106    request.  This could potentially lock up the server for a while,
 107    leading to lost frames.  Should never cause tearing though, we're
 108    changing the surface contents, not the server back buffer which is
 109    what is scheduled for blitting at vsync time.
 110
 111
 112 RMI
 113
 114 The wayland protocol is a async object oriented protocol.  All
 115 requests are method invocations on some object.  The request include
 116 an object id that uniquely identifies an object on the server.  Each
 117 object implements an interface and the requests include an opcode that
 118 identifies which method in the interface to invoke.
 119
 120 The server sends back events to the client, each event is emitted from
 121 an object.  Events can be error conditions.  The event includes the
 122 object id and the event opcode, from which the client can determine
 123 the type of event.  Events are generated both in repsonse to a request
 124 (in which case the requet and the event constitutes a round trip) or
 125 spontanously when the server state changes.
 126
 127 the get_interface method is called on an object to get an object
 128 handle that implements the specified interface.