TODO

   1 Core wayland protocol
   2
   3  - Atomicity.  Currently a lot of the atomicity in Wayland relies on
   4    how we batch up all requests in a protocol buffer and only flushes
   5    in the "blockhandler" in the client.  Consensus was that we need
   6    something more reliable and explicit.  The suggestion is that we
   7    make surface.attach a synchronization point such that everything
   8    before that is batched and applied atomically when the
   9    surface.attach request comes in.  For cases where we need atomicity
  10    beyond a surface.attach, we can add an atomic grouping mechanism,
  11    that can group together multiple surface.attach requests into a
  12    bigger atomic change.  To be researched a bit.
  13
  14  - Maybe try to make remote wayland actually happen, to see if there
  15    is something in the protocol/architecture that makes it harder than
  16    it should be.
  17
  18  - Add timestamp to touch_cancel, add touch id to touch_cancel (?)
  19
  20  - The output protocol needs to send all the ugly timing details for the modes.
  21
  22 ICCCM
  23
  24  - mime-type guidelines for data_source (ie, both dnd and selection):
  25    recommended types for text or images, types that a clipboard
  26    manager must support, mime-types must be listed in preferred order
  27
  28  - we need a "no kb focus please" mechanism.  Or should this be
  29    implicit in a specific surface type?
  30
  31 EWMH
  32
  33  - configure should provide dx_left, dx_right, dy_top, dy_bottom, or
  34    dx, dy, width and height.
  35
  36  - move to workspace, keep on top, on all workspaces, minimize etc
  37    requests for implementing client side window menu? or just make a
  38    "show window menu" request to let the compositor display and manage
  39    a popup window?
  40
  41  - window move and resize functionality for kb and touch.
  42
  43  - Protocol for specifying title bar rectangle (for moving
  44    unresponsive apps).  Rectangle for close button, so we can popup
  45    force-close dialog if application doesn't respond to ping event
  46    when user clicks there.  We could use the region mechanism here
  47    too.
  48
  49  - popup placement protocol logic.
  50
  51  - subsurface mechanism.  we need this for cases where we would use an
  52    X subwindow for gl or video other different visual type.
  53
  54 EGL/gbm
  55
  56  - Don't wl_display_iterate in eglSwapBuffer, send an eventfd fd?
  57
  58  - Land Robert Braggs EGL extensions: frame age, swap with damage
  59
  60  - Make it possible to share buffers from compositor to clients.
  61    Tricky part here is how to indicate to EGL on the server side that
  62    it should make an EGLImage available to a client.  We'll need a
  63    "create a wl_buffer for this EGLImage for this client" kind of
  64    entry point.
  65
  66  - Protocol for arbitrating access to scanout buffers (physically
  67    contiguous memory).  When a client goes fullscreen (or ideally as
  68    the compositor starts the animation that will make it fullscreen)
  69    we send a "give up your scanout buffer" to the current fullscreen
  70    client (if any) and when the client acks that we send a "try to
  71    allocate a scanout buffer now" event to the fullscreen-to-be
  72    client.
  73
  74 Misc
  75
  76  - glyph cache
  77
  78     - Needs a mechanism to pass buffers to client.
  79
  80       buffer = drm.create_buffer(); /* buffer with stuff in it */
  81
  82       cache.upload(buffer, x, y, width, height, int hash)
  83
  84       drm.buffer: id, name, stride etc /* event to announce cache buffer */
  85
  86       cache.image: hash, buffer, x, y, stride /* event to announce
  87                                               * location in cache */
  88
  89       cache.reject: hash   /* no upload for you! */
  90
  91       cache.retire: buffer /* cache has stopped using buffer, please
  92                             * reupload whatever you had in that buffer */
  93
  94  - A "please suspend" event from the compositor, to indicate to an
  95    application that it's no longer visible/active.  Or maybe discard
  96    buffer, as in "wayland discarded your buffer, it's no longer
  97    visible, you can stop updating it now.", reattach, as in "oh hey,
  98    I'm about to show your buffer that I threw away, what was it
  99    again?".  for wayland system compositor vt switcing, for example,
 100    to be able to throw away the surfaces in the session we're
 101    switching away from.  for minimized windows that we don't want live
 102    thumb nails for. etc.
 103
 104 Clients and ports
 105
 106  - port gtk+
 107
 108     - draw window decorations in gtkwindow.c
 109
 110     - Details about pointer grabs. wayland doesn't have active grabs,
 111       menus will behave subtly different.  Under X, clicking a menu
 112       open grabs the pointer and clicking outside the window pops down
 113       the menu and swallows the click.  without active grabs we can't
 114       swallow the click.  I'm sure there much more...
 115
 116     - dnd, copy-paste
 117
 118  - Investigate DirectFB on Wayland (or is that Wayland on DirectFB?)
 119
 120  - SDL port, bnf has work in progress here:
 121    http://cgit.freedesktop.org/~bnf/sdl-wayland/
 122
 123  - libva + eglimage + kms integration
 124
 125
 126 Ideas
 127
 128  - A wayland settings protocol to tell clients about themes (icons,
 129    cursors, widget themes), fonts details (family, hinting
 130    preferences) etc.  Just send all settings at connect time, send
 131    updates when a setting change.  Getting a little close to gconf
 132    here, but could be pretty simple:
 133
 134      interface "settings":
 135        event int_value(string name, int value)
 136        event string_value(string name, string value)
 137
 138    but maybe it's better to just require that clients get that from
 139    somewhere else (gconf/dbus).
 140
 141
 142 Crazy ideas
 143
 144  - AF_WAYLAND - A new socket type.  Eliminate compositor context
 145    switch by making kernel understand enough of wayland that it can
 146    forward input events as wayland events and do page flipping in
 147    response to surface_attach requests:
 148
 149     - ioctl(wayland_fd, "surface_attach to object 5 should do a kms page
 150                          flip on ctrc 2");
 151
 152     - what about multiple crtcs? what about frame event for other
 153       clients?
 154
 155     - forward these input devices to the client
 156
 157     - "scancode 124 pressed or released with scan codes 18,22 and 30
 158        held down gives control back to userspace wayland.
 159
 160     - what about maintaining cursor position? what about pointer
 161       acceleration?  maybe this only works in "client cursor mode",
 162       where wayland hides the cursor and only sends relative events?
 163       Solves the composited cursor problem.  How does X show its
 164       cursor then?
 165
 166     - Probably not worth it.