TODO

   1 Core wayland protocol
   2
   3  - Move map_* requests to wl_shell as set_*, rename to
   4    wl_desktop_shell.  Make initial attach the request that shows the
   5    surface and make attach with 0 buffer show the surface.  Drop the
   6    map concept at that point.  Make wl_shell the EWMH of wayland.
   7    Handle window title, icons, lower window, needs attention,
   8    minimize, maximize, move to desktop?
   9
  10  - scanner: wl_* prefix removal: split it out into a namespace part so
  11    we can call variables "surface" instead of "wl_surface"?
  12
  13  - Framebased input event delivery.
  14
  15  - Protocol for arbitrating access to scanout buffers (physically
  16    contiguous memory).  When a client goes fullscreen (or ideally as
  17    the compositor starts the animation that will make it fullscreen)
  18    we send a "give up your scanout buffer" to the current fullscreen
  19    client (if any) and when the client acks that we send a "try to
  20    allocate a scanout buffer now" event to the fullscreen-to-be
  21    client.
  22
  23  - Next steps based on EGL_WL_bind_display: create EGLImageKHR from
  24    shm buffers? async auth in the implementation of the extension?
  25
  26  - wayland-egl: lazy-copy-back swapbuffer, sub-window, scanout flags
  27    for fullscreen.
  28
  29  - configure should provide dx_left, dx_right, dy_top, dy_bottom, or
  30    dx, dy, width and height.
  31
  32  - surface.set_grab_mode(GRAB_OWNER_EVENTS vs GRAB_SURFACE_EVENTS), to
  33    make menus work right: click and drag in a menubar grabs the
  34    pointer to the menubar (which we need for detecting motion into
  35    another menu item), but we need events for the popup menu surface
  36    as well.
  37
  38  - The message format has to include information about number of fds
  39    in the message so we can skip a message correctly.  Or we should
  40    just give up on trying to recover from unknown messages.  We need
  41    to make sure you never get a message from an interface you don't
  42    know about (using per-client id space and subscribe) or include
  43    information on number of fds, so marshalling logic can skip.
  44
  45  - generate pointer_focus (and drag focus) on raise/lower, move
  46    windows, all kinds of changes in surface stacking.
  47
  48  - glyph cache
  49
  50       buffer = drm.create_buffer(); /* buffer with stuff in it */
  51
  52       cache.upload(buffer, x, y, width, height, int hash)
  53
  54       drm.buffer: id, name, stride etc /* event to announce cache buffer */
  55
  56       cache.image: hash, buffer, x, y, stride /* event to announce
  57                                               * location in cache */
  58
  59       cache.reject: hash   /* no upload for you! */
  60
  61       cache.retire: buffer /* cache has stopped using buffer, please
  62                             * reupload whatever you had in that buffer */
  63
  64  - DnD issues:
  65
  66     - Drag should not be tied to a source surface, just the client.
  67       the grab will break if the surface goes away, but the wl_drag
  68       struct doesn't need to hold on to the source surface.
  69
  70     - Root window must send NULL type (to decline drop) or
  71       x-wayland/root-something type if the source offers that.  But
  72       the target deletes the drag_offer object when drag.pointer_focus
  73       leaves the surface...
  74
  75     - How do we animate the drag icon back to the drag origin in case
  76       of a failed drag?  Client should set drag icon separately,
  77       compositor can do it then.
  78
  79     - How to handle surfaces from clients that don't know about dnd or
  80       don't care?  Maybe the dnd object should have a
  81       dnd.register_surface() method so clients can opt-in the surfaces
  82       that will participate in dnd.  Or just assume client is not
  83       participating until we receive an accept request.
  84
  85     - Selection/copy+paste issues: is it sufficient to only introduce
  86       the selection offer when a client receives kb focus?  Or maybe
  87       it is actually a security feature?  Clipboard manager in server
  88       for retained selections?
  89
  90  - Pointer image issue:
  91
  92     - A direct touch input device (eg touch screen) doesn't have a
  93       pointer; indicate that somehow.
  94
  95     - Cursor themes, tie in with glyph/image cache.
  96
  97  - A "please suspend" event from the compositor, to indicate to an
  98    application that it's no longer visible/active.  Or maybe discard
  99    buffer, as in "wayland discarded your buffer, it's no longer
 100    visible, you can stop updating it now.", reattach, as in "oh hey,
 101    I'm about to show your buffer that I threw away, what was it
 102    again?".  for wayland system compositor vt switcing, for example,
 103    to be able to throw away the surfaces in the session we're
 104    switching away from.  for minimized windows that we don't want live
 105    thumb nails for. etc.
 106
 107  - Per client id space.  Each client has an entire 32 bit id namespace
 108    to itself.  On the server side, each struct wl_client has an object
 109    hash table.  Object announcements use a server id space and clients
 110    must respond with subscribe request with a client id for the
 111    object.  Part of wl_proxy_create_for_id():
 112
 113       wl_display_subscribe(display, id, new_id, my_version);
 114
 115    or maybe
 116
 117       wl_display_bind(display, id, new_id, my_version);
 118
 119    Fixes a few things:
 120
 121     - Maps the global object into the client id space, lets client
 122       allocate the id.  All ids are allocated by the client this way,
 123       which fixes the range protocol problem.
 124
 125     - Tells the server that the client is interested in events from
 126       the object.  Lets the server know that a client participates in a
 127       certain protocol (like drag and drop), so the server can account
 128       for whether or not the client is expected to reply
 129
 130     - Server emits initial object state event(s) in reponse to
 131       receiving the subscribe request.  Introduces an extra round trip
 132       at initialization time, but the server will still announces all
 133       objects in one burst and the client can subscribe in a burst as
 134       well.
 135
 136     - Separates client resources, since each client will have it's own
 137       hash table.  It's not longer possible to guess the id of another
 138       surface and access it.
 139
 140     - Server must track the client id for each client an object is
 141       exposed to.  In some cases we know this (a surface is always
 142       only owned by one client), in other cases it provides a way to
 143       track who's interested in the object events.  For input device
 144       events, we can look up the client name when it receives pointer
 145       focus or keyboard focus and cache it in the device.
 146
 147     - Server must know which id to send when passing object references
 148       in events.  We could say that any object we're passing to a
 149       client must have a server id, and each client has a server id ->
 150       client id hash.
 151
 152  - LCD subpixel info, dpi, monitor make and model, event when a
 153    surface moves from one output to another.
 154
 155  - input device discovery, hotplug
 156
 157     - Advertise axes as part of the discovery, use something like
 158       "org.wayland.input.x" to identify the axes.
 159
 160     - keyboard state, layout events at connect time and when it
 161       changes, keyboard leds
 162
 163     - relative events
 164
 165     - multi touch?
 166
 167     - synaptics, 3-button emulation, scim
 168
 169  - drm bo access control, authentication, flink_to
 170
 171  - Range protocol may not be sufficient... if a server cycles through
 172    2^32 object IDs we don't have a way to handle wrapping.  And since
 173    we hand out a range of 256 IDs to each new clients, we're just
 174    talking about 2^24 clients.  That's 31 years with a new client
 175    every minute...  Maybe just use bigger ranges, then it's feasible
 176    to track and garbage collect them when a client dies.
 177
 178  - Add protocol to let applications specify the effective/logical
 179    surface rectangle, that is, the edge of the window, ignoring drop
 180    shadows and other padding.  The compositor needs this for snapping
 181    and constraining window motion.  Also, maybe communicate the opaque
 182    region of the window (or just a conservative, simple estimate), to
 183    let the compositor reduce overdraw.
 184
 185  - Protocol for specifying title bar rectangle (for moving
 186    unresponsive apps) and a rectangle for the close button (for
 187    detecting ignored close clicks).
 188
 189  - multi gpu, needs queue and seqno to wait on in requests
 190
 191  - libxkbcommon
 192
 193     - pull in actions logic from xserver
 194
 195     - pull in keycode to keysym logic from libX11
 196
 197     - expose alloc functions in libxkbcommon, drop xserver funcs?
 198
 199     - pull the logic to write the xkb file from xkb_desc and names
 200       into libxkbcommon and just build up the new xkb_desc instead of
 201       dump+parse? (XkbWriteXKBKeymapForNames followed by
 202       xkb_compile_keymap_from_string in XkbDDXLoadKeymapByNames)
 203
 204     - pull in keysym defs as XKB_KEY_BackSpace
 205
 206     - figure out what other X headers we can get rid of, make it not
 207       need X at all (except when we gen the keysyms).
 208
 209     - Sort out namespace pollution (XkbFoo macros, atom funcs etc).
 210
 211     - Sort out 32 bit vmods and serialization
 212
 213  - Automatic "triple buffering", ie, don't block on vsync if we're
 214    repainting below the refresh rate.
 215
 216     - surface.attach triggers a compositor.release_buffer event when
 217       the buffer can be used again without messing things up (ie, it's
 218       no longer the front buffer, or the compositor has attached the
 219       new surface).
 220
 221     - compositor sends out a repaint event (to who? do clients have to
 222       ask for this like they ask for the frame event?) once it has
 223       repainted the scene with the recent updates.
 224
 225     - once a client receives the repaint event, it should start
 226       rendering its next frame.  If it has received a buffer release
 227       event for the old buffer, that can be reused, otherwise it has
 228       to allocate a third buffer (ie, we automatically do triple
 229       buffering for fullscreen surfaces).
 230
 231     - if a client is triple buffering and receives a release event
 232       before the repaint event, it can go back to double buffering.
 233
 234     - the repaint event needs some kind of timestamp to drive
 235       animations, since clients may not use the frame event at all.
 236       Could just be the time of the most recent frame.
 237
 238
 239 Clients and ports
 240
 241  - port gtk+
 242
 243     - draw window decorations in gtkwindow.c
 244
 245     - Details about pointer grabs. wayland doesn't have active grabs,
 246       menus will behave subtly different.  Under X, clicking a menu
 247       open grabs the pointer and clicking outside the window pops down
 248       the menu and swallows the click.  without active grabs we can't
 249       swallow the click.  I'm sure there much more...
 250
 251     - dnd, copy-paste
 252
 253  - Investigate DirectFB on Wayland (or is that Wayland on DirectFB?)
 254
 255  - SDL port, bnf has work in progress here:
 256    http://cgit.freedesktop.org/~bnf/sdl-wayland/
 257
 258  - libva + eglimage + kms integration
 259
 260  - X on Wayland
 261
 262     - map multiple wayland input devices to MPX in Xorg.
 263
 264     - rootless; avoid allocating and setting the front buffer, draw
 265       window decorations in the X server (!), how to map input?
 266
 267
 268 Ideas
 269
 270  - A wayland settings protocol to tell clients about themes (icons,
 271    cursors, widget themes), fonts details (family, hinting
 272    preferences) etc.  Just send all settings at connect time, send
 273    updates when a setting change.  Getting a little close to gconf
 274    here, but could be pretty simple:
 275
 276      interface "settings":
 277        event int_value(string name, int value)
 278        event string_value(string name, string value)
 279
 280    but maybe it's better to just require that clients get that from
 281    somewhere else (gconf/dbus).
 282
 283
 284 Crazy ideas
 285
 286  - AF_WAYLAND - A new socket type.  Eliminate compositor context
 287    switch by making kernel understand enough of wayland that it can
 288    forward input events as wayland events and do page flipping in
 289    response to surface_attach requests:
 290
 291     - ioctl(wayland_fd, "surface_attach to object 5 should do a kms page
 292                          flip on ctrc 2");
 293
 294     - what about multiple crtcs? what about frame event for other
 295       clients?
 296
 297     - forward these input devices to the client
 298
 299     - "scancode 124 pressed or released with scan codes 18,22 and 30
 300        held down gives control back to userspace wayland.
 301
 302     - what about maintaining cursor position? what about pointer
 303       acceleration?  maybe this only works in "client cursor mode",
 304       where wayland hides the cursor and only sends relative events?
 305       Solves the composited cursor problem.  How does X show its
 306       cursor then?
 307
 308     - Probably not worth it.