TODO

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