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