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