TODO

   1 Core wayland protocol
   2
   3  - surface.set_grab_mode(GRAB_OWNER_EVENTS vs GRAB_SURFACE_EVENTS), to
   4    make menus work right: click and drag in a menubar grabs the
   5    pointer to the menubar (which we need for detecting motion into
   6    another menu item), but we need events for the popup menu surface
   7    as well.
   8
   9  - The message format has to include information about number of fds
  10    in the message so we can skip a message correctly.  Or we should
  11    just give up on trying to recover from unknown messages.  We need
  12    to make sure you never get a message from an interface you don't
  13    know about (using per-client id space and subscribe) or include
  14    information on number of fds, so marshalling logic can skip.
  15
  16  - generate pointer_focus (and drag focus) on raise/lower, move
  17    windows, all kinds of changes in surface stacking.
  18
  19  - glyph cache
  20
  21       buffer = drm.create_buffer(); /* buffer with stuff in it */
  22
  23       cache.upload(buffer, x, y, width, height, int hash)
  24
  25       drm.buffer: id, name, stride etc /* event to announce cache buffer */
  26
  27       cache.image: hash, buffer, x, y, stride /* event to announce
  28                                               * location in cache */
  29
  30       cache.reject: hash   /* no upload for you! */
  31
  32       cache.retire: buffer /* cache has stopped using buffer, please
  33                             * reupload whatever you had in that buffer */
  34
  35  - DnD issues:
  36
  37    Root window must send NULL type (to decline drop) or
  38    x-wayland/root-something type if the source offers that.  But the
  39    target deletes the drag_offer object when drag.pointer_focus leaves
  40    the surface...
  41
  42    How do we animate the drag icon back to the drag origin in case of
  43    a failed drag?
  44
  45    How to handle surfaces from clients that don't know about dnd or
  46    don't care?  Maybe the dnd object should have a
  47    dnd.register_surface() method so clients can opt-in the surfaces
  48    that will participate in dnd.  Or just assume client is not
  49    participating until we receive an accept request.
  50
  51  - Selection/copy+paste issues: is it sufficient to only introduce the
  52    selection offer when a client receives kb focus?  Or maybe it is
  53    actually a security feature?  Clipboard manager in server for
  54    retained selections?
  55
  56  - Pointer image issue:
  57
  58     - A direct touch input device (eg touch screen) doesn't have a
  59       pointer; indicate that somehow.
  60
  61     - Cursor themes, tie in with glyph/image cache.
  62
  63  - Discard buffer, as in "wayland discarded your buffer, it's no
  64    longer visible, you can stop updating it now.", reattach, as in "oh
  65    hey, I'm about to show your buffer that I threw away, what was it
  66    again?".  for wayland system compositor vt switcing, for example,
  67    to be able to throw away the surfaces in the session we're
  68    switching away from.  for minimized windows that we don't want live
  69    thumb nails for. etc.
  70
  71  - Import relevants bits from EWMH spec, stuff like window title,
  72    window class, app groups, icons, lower window, need attention,
  73    fullscreen (maybe different types of fullscreen).
  74
  75  - Per client id space.  Each client has an entire 32 bit id namespace
  76    to itself.  On the server side, each struct wl_client has an object
  77    hash table.  Object announcements use a server id space and clients
  78    must respond with subscribe request with a client id for the
  79    object.  Part of wl_proxy_create_for_id():
  80
  81       wl_display_subscribe(display, id, new_id, my_version);
  82
  83    or maybe
  84
  85       wl_display_bind(display, id, new_id, my_version);
  86
  87    Fixes a few things:
  88
  89     - Maps the global object into the client id space, lets client
  90       allocate the id.  All ids are allocated by the client this way,
  91       which fixes the range protocol problem.
  92
  93     - Tells the server that the client is interested in events from
  94       the object.  Lets the server know that a client participates in a
  95       certain protocol (like drag and drop), so the server can account
  96       for whether or not the client is expected to reply
  97
  98     - Server emits initial object state event(s) in reponse to
  99       receiving the subscribe request.  Introduces an extra round trip
 100       at initialization time, but the server will still announces all
 101       objects in one burst and the client can subscribe in a burst as
 102       well.
 103
 104     - Separates client resources, since each client will have it's own
 105       hash table.  It's not longer possible to guess the id of another
 106       surface and access it.
 107
 108     - Server must track the client id for each client an object is
 109       exposed to.  In some cases we know this (a surface is always
 110       only owned by one client), in other cases it provides a way to
 111       track who's interested in the object events.  For input device
 112       events, we can look up the client name when it receives pointer
 113       focus or keyboard focus and cache it in the device.
 114
 115     - Server must know which id to send when passing object references
 116       in events.  We could say that any object we're passing to a
 117       client must have a server id, and each client has a server id ->
 118       client id hash.
 119
 120  - When a surface is the size of the screen and on top, we can set the
 121    scanout buffer to that surface directly.  Like compiz unredirect
 122    top-level window feature.  Except it won't have any protocol state
 123    side-effects and the client that owns the surface won't know.  We
 124    lose control of updates.  Should work well for X server root window
 125    under wayland.  Should be possible for yuv overlays as well.
 126
 127     - what about cursors then?  maybe use hw cursors if the cursor
 128       satisfies hw limitations (64x64, only one cursor), switch to
 129       composited cursors if not.
 130
 131     - clients needs to allocate the surface to be suitable for
 132       scanout, which they can do whenever they go fullscreen.
 133
 134  - multihead, screen geometry and crtc layout protocol, hotplug, lcd
 135    subpixel info
 136
 137  - a wayland settings protocol to tell clients about themes (icons,
 138    cursors, widget themes), fonts details (family, hinting
 139    preferences) etc.  Just send all settings at connect time, send
 140    updates when a setting change.  Getting a little close to gconf
 141    here, but could be pretty simple:
 142
 143      interface "settings":
 144        event int_value(string name, int value)
 145        event string_value(string name, string value)
 146
 147    but maybe it's better to just require that clients get that from
 148    somewhere else (gconf/dbus).
 149
 150  - input device discovery, hotplug
 151
 152     - Advertise axes as part of the discovery, use something like
 153       "org.wayland.input.x" to identify the axes.
 154
 155     - keyboard state, layout events at connect time and when it
 156       changes, keyboard leds
 157
 158     - relative events
 159
 160     - multi touch?
 161
 162     - synaptics, 3-button emulation, scim
 163
 164  - drm bo access control, authentication, flink_to
 165
 166  - Range protocol may not be sufficient... if a server cycles through
 167    2^32 object IDs we don't have a way to handle wrapping.  And since
 168    we hand out a range of 256 IDs to each new clients, we're just
 169    talking about 2^24 clients.  That's 31 years with a new client
 170    every minute...  Maybe just use bigger ranges, then it's feasible
 171    to track and garbage collect them when a client dies.
 172
 173  - Add protocol to let applications specify the effective/logical
 174    surface rectangle, that is, the edge of the window, ignoring drop
 175    shadows and other padding.  The compositor needs this for snapping
 176    and constraining window motion.  Also, maybe communicate the opaque
 177    region of the window (or just a conservative, simple estimate), to
 178    let the compositor reduce overdraw.
 179
 180  - multi gpu, needs queue and seqno to wait on in requests
 181
 182 Clients and ports
 183
 184  - port gtk+
 185
 186     - draw window decorations in gtkwindow.c
 187
 188     - Details about pointer grabs. wayland doesn't have active grabs,
 189       menus will behave subtly different.  Under X, clicking a menu
 190       open grabs the pointer and clicking outside the window pops down
 191       the menu and swallows the click.  without active grabs we can't
 192       swallow the click.  I'm sure there much more...
 193
 194  - Port Qt?  There's already talk about this on the list.
 195
 196  - X on Wayland
 197
 198     - move most of the code from xf86-video-intel into a Xorg wayland
 199       module.
 200
 201     - don't ask KMS for available output and modes, use the info from
 202       the wayland server.  then stop mooching off of drmmode.c.
 203
 204     - map multiple wayland input devices to MPX in Xorg.
 205
 206     - rootless; avoid allocating and setting the front buffer, draw
 207       window decorations in the X server (!), how to map input?
 208
 209  - gnome-shell as a wayland session compositor
 210
 211     - runs as a client of the wayland session compositor, uses
 212       clutter+egl on wayland
 213
 214     - talks to an Xorg server as the compositing and window manager
 215       for that server and renders the output to a wayland surface.
 216       the Xorg server should be modified to take input from the system
 217       compositor through gnome-shell, but not allocate a front buffer.
 218
 219     - make gnome-shell itself a nested wayland server and allow native
 220       wayland clients to connect and can native wayland windows with
 221       the windows from the X server.
 222
 223  - qemu as a wayland client; session surface as X case
 224
 225     - qemu has too simple acceleration, so a Wayland backend like the
 226       SDL/VNC ones it has now is trivial.
 227
 228     - paravirt: forward wayland screen info as mmio, expose gem ioctls as mmio
 229
 230     - mapping vmem is tricky, should try to only use ioctl (pwrite+pread)
 231
 232     - not useful for Windows without a windows paravirt driver.
 233
 234     - two approaches: 1) do a toplevel qemu window, or 2) expose a
 235       wayland server in the guest that forwards to the host wayland
 236       server, ie a "remote" compositor, but with the gem buffers
 237       shared.  could do a wl_connection directly on mmio memory, with
 238       head and tail pointers.  use an alloc_head register to indicate
 239       desired data to write, if it overwrites tail, block guest.  just
 240       a socket would be easier.
 241
 242  - moblin as a wayland compositor
 243
 244     - clutter as a wayland compositors
 245
 246     - argh, mutter