TODO

   1 Core wayland protocol
   2
   3  - We need rotation information in the output (multiples of 90
   4    degress) and we'll need a way for a client to communicate that it
   5    has rendered it's buffer according to the output rotation.  The
   6    goal is to be able to pageflip directly to the client buffer, and
   7    for that we need the client to render accordingly and the
   8    compositor needs to know that it did.
   9
  10  - Atomicity.  Currently a lot of the atomicity in Wayland relies on
  11    how we batch up all requests in a protocol buffer and only flushes
  12    in the "blockhandler" in the client.  Consensus was that we need
  13    something more reliable and explicit.  The suggestion is that we
  14    make surface.attach a synchronization point such that everything
  15    before that is batched and applied atomically when the
  16    surface.attach request comes in.  For cases where we need atomicity
  17    beyond a surface.attach, we can add an atomic grouping mechanism,
  18    that can group together multiple surface.attach requests into a
  19    bigger atomic change.  To be researched a bit.
  20
  21  - We should make pointer sprites regular surfaces.  Something like
  22    input_device.set_sprite(surface).  This also make client side
  23    animated cursors simple/possible, since we now get a frame event
  24    that can drive the animation.
  25
  26  - Maybe try to make remote wayland actually happen, to see if there
  27    is something in the protocol/architecute that makes it harder than
  28    it should be.
  29
  30  - Key events need a bit more work/thinking/redesign. As it is we need
  31    a mechanism to change and synchronize keymaps, repeat rates.  But
  32    as we started talking, we decided that we needed to go back and
  33    research what other systems do instead of just essentially copying
  34    the X model.  Sending out unicode events in addition to keycode
  35    events has a lot of benefits (OSK can send out unicode events
  36    instead of fake keycode events, apps become much simpler...)  Move
  37    keymap handling and repeat to the server?  Needs more research.
  38
  39  - Pointer axis events need modifiers (ctrl-scroll eg), but we either
  40    need to send the modifier state with each axis/scroll event or send
  41    keys down on pointer_focus and subsequent key events... or just key
  42    events for modifier keys... or for the non-repeating subset?
  43
  44  - Input protocol restructuring: break up events into wl_pointer
  45    (enter/leave/motion/button/axis events, set_pointer_surface
  46    request), wl_keyboard (enter/leave/key events... what
  47    else... unicode event, set_map request? pending kb work), and
  48    wl_touch (down/up/motion/cancel events) interfaces.  Rename
  49    wl_input_device to wl_seat.  wl_seat has zero or one of each, and
  50    will announce this at bind time.  Raw devices are also tied to a
  51    wl_seat, but we may not do that for 1.0, we just need to make sure
  52    wl_seat has a forward compatible way to announce them.
  53
  54  - Add timestamp to touch_cancel, add touch id to touch_cancel (?)
  55
  56  - The output protocol needs to send all the ugly timing details for the modes.
  57
  58 ICCCM
  59
  60  - clipboard manager interface?  what's needed?  just notification
  61    that the selection has gone away.  should the clipboard manager be
  62    able to take over the selection "seamlessly", ie, with the same
  63    timestamp etc?  Doesn't seem like we need that, the clipboard will
  64    have to set a new data_source anyway, with the subset of mimetypes
  65    it offers (the clipboad manager may only offer a subset of the
  66    types offered by the original data_source)
  67
  68  - mime-type guidelines for data_source (ie, both dnd and selection):
  69    recommended types for text or images, types that a clipboard
  70    manager must support, mime-types must be listed in preferred order
  71
  72  - we need a "no kb focus please" mechanism.  Or should this be
  73    implicit in a specific surface type?
  74
  75 EWMH
  76
  77  - configure should provide dx_left, dx_right, dy_top, dy_bottom, or
  78    dx, dy, width and height.
  79
  80  - move to workspace, keep on top, on all workspaces, minimize etc
  81    requests for implementing client side window menu? or just make a
  82    "show window menu" request to let the compositor display and manage
  83    a popup window?
  84
  85  - window move and resize functionality for kb and touch.
  86
  87  - dnd loose ends: self-dnd: initiate dnd with a null data-source,
  88    compositor will not offer to other clients, client has to know
  89    internally what's offered and how to transfer data. no fd passing.
  90
  91  - Protocol for specifying title bar rectangle (for moving
  92    unresponsive apps).  Rectangle for close button, so we can popup
  93    force-close dialog if application doesn't respond to ping event
  94    when user clicks there.  We could use the region mechanism here
  95    too.
  96
  97  - popup placement protocol logic.
  98
  99  - subsurface mechanism.  we need this for cases where we would use an
 100    X subwindow for gl or video other different visual type.
 101
 102 EGL/gbm
 103
 104  - Don't wl_display_iterate in eglSwapBuffer, send an eventfd fd?
 105
 106  - Land Robert Braggs EGL extensions: frame age, swap with damage
 107
 108  - Make it possible to share buffers from compositor to clients.
 109    Tricky part here is how to indicate to EGL on the server side that
 110    it should make an EGLImage available to a client.  We'll need a
 111    "create a wl_buffer for this EGLImage for this client" kind of
 112    entry point.
 113
 114  - Protocol for arbitrating access to scanout buffers (physically
 115    contiguous memory).  When a client goes fullscreen (or ideally as
 116    the compositor starts the animation that will make it fullscreen)
 117    we send a "give up your scanout buffer" to the current fullscreen
 118    client (if any) and when the client acks that we send a "try to
 119    allocate a scanout buffer now" event to the fullscreen-to-be
 120    client.
 121
 122 Misc
 123
 124  - glyph cache
 125
 126     - Needs a mechanism to pass buffers to client.
 127
 128       buffer = drm.create_buffer(); /* buffer with stuff in it */
 129
 130       cache.upload(buffer, x, y, width, height, int hash)
 131
 132       drm.buffer: id, name, stride etc /* event to announce cache buffer */
 133
 134       cache.image: hash, buffer, x, y, stride /* event to announce
 135                                               * location in cache */
 136
 137       cache.reject: hash   /* no upload for you! */
 138
 139       cache.retire: buffer /* cache has stopped using buffer, please
 140                             * reupload whatever you had in that buffer */
 141
 142  - A "please suspend" event from the compositor, to indicate to an
 143    application that it's no longer visible/active.  Or maybe discard
 144    buffer, as in "wayland discarded your buffer, it's no longer
 145    visible, you can stop updating it now.", reattach, as in "oh hey,
 146    I'm about to show your buffer that I threw away, what was it
 147    again?".  for wayland system compositor vt switcing, for example,
 148    to be able to throw away the surfaces in the session we're
 149    switching away from.  for minimized windows that we don't want live
 150    thumb nails for. etc.
 151
 152 libxkbcommon
 153
 154   - pull in actions logic from xserver
 155
 156   - pull in keycode to keysym logic from libX11
 157
 158   - expose alloc functions in libxkbcommon, drop xserver funcs?
 159
 160   - pull the logic to write the xkb file from xkb_desc and names into
 161     libxkbcommon and just build up the new xkb_desc instead of
 162     dump+parse? (XkbWriteXKBKeymapForNames followed by
 163     xkb_compile_keymap_from_string in XkbDDXLoadKeymapByNames)
 164
 165   - pull in keysym defs as XKB_KEY_BackSpace
 166
 167   - figure out what other X headers we can get rid of, make it not
 168     need X at all (except when we gen the keysyms).
 169
 170   - Sort out namespace pollution (XkbFoo macros, atom funcs etc).
 171
 172   - Sort out 32 bit vmods and serialization
 173
 174
 175 Clients and ports
 176
 177  - port gtk+
 178
 179     - draw window decorations in gtkwindow.c
 180
 181     - Details about pointer grabs. wayland doesn't have active grabs,
 182       menus will behave subtly different.  Under X, clicking a menu
 183       open grabs the pointer and clicking outside the window pops down
 184       the menu and swallows the click.  without active grabs we can't
 185       swallow the click.  I'm sure there much more...
 186
 187     - dnd, copy-paste
 188
 189  - Investigate DirectFB on Wayland (or is that Wayland on DirectFB?)
 190
 191  - SDL port, bnf has work in progress here:
 192    http://cgit.freedesktop.org/~bnf/sdl-wayland/
 193
 194  - libva + eglimage + kms integration
 195
 196
 197 Ideas
 198
 199  - A wayland settings protocol to tell clients about themes (icons,
 200    cursors, widget themes), fonts details (family, hinting
 201    preferences) etc.  Just send all settings at connect time, send
 202    updates when a setting change.  Getting a little close to gconf
 203    here, but could be pretty simple:
 204
 205      interface "settings":
 206        event int_value(string name, int value)
 207        event string_value(string name, string value)
 208
 209    but maybe it's better to just require that clients get that from
 210    somewhere else (gconf/dbus).
 211
 212
 213 Crazy ideas
 214
 215  - AF_WAYLAND - A new socket type.  Eliminate compositor context
 216    switch by making kernel understand enough of wayland that it can
 217    forward input events as wayland events and do page flipping in
 218    response to surface_attach requests:
 219
 220     - ioctl(wayland_fd, "surface_attach to object 5 should do a kms page
 221                          flip on ctrc 2");
 222
 223     - what about multiple crtcs? what about frame event for other
 224       clients?
 225
 226     - forward these input devices to the client
 227
 228     - "scancode 124 pressed or released with scan codes 18,22 and 30
 229        held down gives control back to userspace wayland.
 230
 231     - what about maintaining cursor position? what about pointer
 232       acceleration?  maybe this only works in "client cursor mode",
 233       where wayland hides the cursor and only sends relative events?
 234       Solves the composited cursor problem.  How does X show its
 235       cursor then?
 236
 237     - Probably not worth it.