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  - Framebased input event delivery.
   7
   8  - Protocol for arbitrating access to scanout buffers (physically
   9    contiguous memory).  When a client goes fullscreen (or ideally as
  10    the compositor starts the animation that will make it fullscreen)
  11    we send a "give up your scanout buffer" to the current fullscreen
  12    client (if any) and when the client acks that we send a "try to
  13    allocate a scanout buffer now" event to the fullscreen-to-be
  14    client.
  15
  16  - Next steps based on EGL_WL_bind_display: create EGLImageKHR from
  17    shm buffers? async auth in the implementation of the extension?
  18
  19  - wayland-egl: lazy-copy-back swapbuffer, sub-window.
  20
  21  - configure should provide dx_left, dx_right, dy_top, dy_bottom, or
  22    dx, dy, width and height.
  23
  24  - surface.set_grab_mode(GRAB_OWNER_EVENTS vs GRAB_SURFACE_EVENTS), to
  25    make menus work right: click and drag in a menubar grabs the
  26    pointer to the menubar (which we need for detecting motion into
  27    another menu item), but we need events for the popup menu surface
  28    as well.
  29
  30  - glyph cache
  31
  32     - Needs a mechanism to pass buffers to client.
  33
  34       buffer = drm.create_buffer(); /* buffer with stuff in it */
  35
  36       cache.upload(buffer, x, y, width, height, int hash)
  37
  38       drm.buffer: id, name, stride etc /* event to announce cache buffer */
  39
  40       cache.image: hash, buffer, x, y, stride /* event to announce
  41                                               * location in cache */
  42
  43       cache.reject: hash   /* no upload for you! */
  44
  45       cache.retire: buffer /* cache has stopped using buffer, please
  46                             * reupload whatever you had in that buffer */
  47
  48  - DnD issues:
  49
  50     - Drag should not be tied to a source surface, just the client.
  51       the grab will break if the surface goes away, but the wl_drag
  52       struct doesn't need to hold on to the source surface.
  53
  54     - Root window must send NULL type (to decline drop) or
  55       x-wayland/root-something type if the source offers that.  But
  56       the target deletes the drag_offer object when drag.pointer_focus
  57       leaves the surface...
  58
  59     - How do we animate the drag icon back to the drag origin in case
  60       of a failed drag?  Client should set drag icon separately,
  61       compositor can do it then.
  62
  63     - How to handle surfaces from clients that don't know about dnd or
  64       don't care?  Maybe the dnd object should have a
  65       dnd.register_surface() method so clients can opt-in the surfaces
  66       that will participate in dnd.  Or just assume client is not
  67       participating until we receive an accept request.
  68
  69     - Selection/copy+paste issues: is it sufficient to only introduce
  70       the selection offer when a client receives kb focus?  Or maybe
  71       it is actually a security feature?  Clipboard manager in server
  72       for retained selections?
  73
  74  - Pointer image issue:
  75
  76     - A direct touch input device (eg touch screen) doesn't have a
  77       pointer; indicate that somehow.
  78
  79     - Cursor themes, tie in with glyph/image cache.
  80
  81  - A "please suspend" event from the compositor, to indicate to an
  82    application that it's no longer visible/active.  Or maybe discard
  83    buffer, as in "wayland discarded your buffer, it's no longer
  84    visible, you can stop updating it now.", reattach, as in "oh hey,
  85    I'm about to show your buffer that I threw away, what was it
  86    again?".  for wayland system compositor vt switcing, for example,
  87    to be able to throw away the surfaces in the session we're
  88    switching away from.  for minimized windows that we don't want live
  89    thumb nails for. etc.
  90
  91  - Event when a surface moves from one output to another.
  92
  93  - input device discovery, hotplug
  94
  95     - Advertise axes as part of the discovery, use something like
  96       "org.wayland.input.x" to identify the axes.
  97
  98     - keyboard state, layout events at connect time and when it
  99       changes, keyboard leds
 100
 101     - relative events
 102
 103     - multi touch?
 104
 105     - synaptics, 3-button emulation, scim
 106
 107  - multi gpu, needs queue and seqno to wait on in requests
 108
 109 Destkop/EWMH type protocol
 110
 111  - Add protocol to let applications specify the effective/logical
 112    surface rectangle, that is, the edge of the window, ignoring drop
 113    shadows and other padding.  The compositor needs this for snapping
 114    and constraining window motion.  Also, maybe communicate the opaque
 115    region of the window (or just a conservative, simple estimate), to
 116    let the compositor reduce overdraw.
 117
 118  - Protocol for specifying title bar rectangle (for moving
 119    unresponsive apps) and a rectangle for the close button (for
 120    detecting ignored close clicks).
 121
 122 libxkbcommon
 123
 124   - pull in actions logic from xserver
 125
 126   - pull in keycode to keysym logic from libX11
 127
 128   - expose alloc functions in libxkbcommon, drop xserver funcs?
 129
 130   - pull the logic to write the xkb file from xkb_desc and names into
 131     libxkbcommon and just build up the new xkb_desc instead of
 132     dump+parse? (XkbWriteXKBKeymapForNames followed by
 133     xkb_compile_keymap_from_string in XkbDDXLoadKeymapByNames)
 134
 135   - pull in keysym defs as XKB_KEY_BackSpace
 136
 137   - figure out what other X headers we can get rid of, make it not
 138     need X at all (except when we gen the keysyms).
 139
 140   - Sort out namespace pollution (XkbFoo macros, atom funcs etc).
 141
 142   - Sort out 32 bit vmods and serialization
 143
 144
 145 Clients and ports
 146
 147  - port gtk+
 148
 149     - draw window decorations in gtkwindow.c
 150
 151     - Details about pointer grabs. wayland doesn't have active grabs,
 152       menus will behave subtly different.  Under X, clicking a menu
 153       open grabs the pointer and clicking outside the window pops down
 154       the menu and swallows the click.  without active grabs we can't
 155       swallow the click.  I'm sure there much more...
 156
 157     - dnd, copy-paste
 158
 159  - Investigate DirectFB on Wayland (or is that Wayland on DirectFB?)
 160
 161  - SDL port, bnf has work in progress here:
 162    http://cgit.freedesktop.org/~bnf/sdl-wayland/
 163
 164  - libva + eglimage + kms integration
 165
 166
 167 Ideas
 168
 169  - A wayland settings protocol to tell clients about themes (icons,
 170    cursors, widget themes), fonts details (family, hinting
 171    preferences) etc.  Just send all settings at connect time, send
 172    updates when a setting change.  Getting a little close to gconf
 173    here, but could be pretty simple:
 174
 175      interface "settings":
 176        event int_value(string name, int value)
 177        event string_value(string name, string value)
 178
 179    but maybe it's better to just require that clients get that from
 180    somewhere else (gconf/dbus).
 181
 182
 183 Crazy ideas
 184
 185  - AF_WAYLAND - A new socket type.  Eliminate compositor context
 186    switch by making kernel understand enough of wayland that it can
 187    forward input events as wayland events and do page flipping in
 188    response to surface_attach requests:
 189
 190     - ioctl(wayland_fd, "surface_attach to object 5 should do a kms page
 191                          flip on ctrc 2");
 192
 193     - what about multiple crtcs? what about frame event for other
 194       clients?
 195
 196     - forward these input devices to the client
 197
 198     - "scancode 124 pressed or released with scan codes 18,22 and 30
 199        held down gives control back to userspace wayland.
 200
 201     - what about maintaining cursor position? what about pointer
 202       acceleration?  maybe this only works in "client cursor mode",
 203       where wayland hides the cursor and only sends relative events?
 204       Solves the composited cursor problem.  How does X show its
 205       cursor then?
 206
 207     - Probably not worth it.