wayland/TODO

Core wayland protocol

 - Fix visuals

 - Generic error reporting mechanism: display.error(object, code, msg)
   event that all interfaces can use to report fatal (ie client
   killing) errors.  The object is the object that the "error is
   generated for", what that means is up to the interface to define,
   but the errorcode has to be unique in the context of that object.
   The msg argument is a textual description that the client can print
   as it dies.

 - Move map_* requests to wl_shell as set_*, rename to
   wl_desktop_shell.  Make initial attach the request that shows the
   surface and make attach with 0 buffer show the surface.  Drop the
   map concept at that point.  Make wl_shell the EWMH of wayland.
   Handle window title, icons, lower window, needs attention,
   minimize, maximize, move to desktop?

 - scanner: wl_* prefix removal: split it out into a namespace part so
   we can call variables "surface" instead of "wl_surface"?

 - Framebased input event delivery.

 - Protocol for arbitrating access to scanout buffers (physically
   contiguous memory).  When a client goes fullscreen (or ideally as
   the compositor starts the animation that will make it fullscreen)
   we send a "give up your scanout buffer" to the current fullscreen
   client (if any) and when the client acks that we send a "try to
   allocate a scanout buffer now" event to the fullscreen-to-be
   client.

 - Next steps based on EGL_WL_bind_display: create EGLImageKHR from
   shm buffers? async auth in the implementation of the extension?

 - wayland-egl: lazy-copy-back swapbuffer, sub-window, scanout flags
   for fullscreen.

 - configure should provide dx_left, dx_right, dy_top, dy_bottom, or
   dx, dy, width and height.

 - surface.set_grab_mode(GRAB_OWNER_EVENTS vs GRAB_SURFACE_EVENTS), to
   make menus work right: click and drag in a menubar grabs the
   pointer to the menubar (which we need for detecting motion into
   another menu item), but we need events for the popup menu surface
   as well.

 - The message format has to include information about number of fds
   in the message so we can skip a message correctly.  Or we should
   just give up on trying to recover from unknown messages.  We need
   to make sure you never get a message from an interface you don't
   know about (using per-client id space and subscribe) or include
   information on number of fds, so marshalling logic can skip.

 - generate pointer_focus (and drag focus) on raise/lower, move
   windows, all kinds of changes in surface stacking.

 - glyph cache

      buffer = drm.create_buffer(); /* buffer with stuff in it */

      cache.upload(buffer, x, y, width, height, int hash)

      drm.buffer: id, name, stride etc /* event to announce cache buffer */

      cache.image: hash, buffer, x, y, stride /* event to announce
					      * location in cache */

      cache.reject: hash   /* no upload for you! */

      cache.retire: buffer /* cache has stopped using buffer, please
			    * reupload whatever you had in that buffer */

 - DnD issues:

    - Drag should not be tied to a source surface, just the client.
      the grab will break if the surface goes away, but the wl_drag
      struct doesn't need to hold on to the source surface.

    - Root window must send NULL type (to decline drop) or
      x-wayland/root-something type if the source offers that.  But
      the target deletes the drag_offer object when drag.pointer_focus
      leaves the surface...

    - How do we animate the drag icon back to the drag origin in case
      of a failed drag?  Client should set drag icon separately,
      compositor can do it then.

    - How to handle surfaces from clients that don't know about dnd or
      don't care?  Maybe the dnd object should have a
      dnd.register_surface() method so clients can opt-in the surfaces
      that will participate in dnd.  Or just assume client is not
      participating until we receive an accept request.

    - Selection/copy+paste issues: is it sufficient to only introduce
      the selection offer when a client receives kb focus?  Or maybe
      it is actually a security feature?  Clipboard manager in server
      for retained selections?

 - Pointer image issue:

    - A direct touch input device (eg touch screen) doesn't have a
      pointer; indicate that somehow.

    - Cursor themes, tie in with glyph/image cache.

 - A "please suspend" event from the compositor, to indicate to an
   application that it's no longer visible/active.  Or maybe discard
   buffer, as in "wayland discarded your buffer, it's no longer
   visible, you can stop updating it now.", reattach, as in "oh hey,
   I'm about to show your buffer that I threw away, what was it
   again?".  for wayland system compositor vt switcing, for example,
   to be able to throw away the surfaces in the session we're
   switching away from.  for minimized windows that we don't want live
   thumb nails for. etc.

 - Per client id space.  Each client has an entire 32 bit id namespace
   to itself.  On the server side, each struct wl_client has an object
   hash table.  Object announcements use a server id space and clients
   must respond with subscribe request with a client id for the
   object.  Part of wl_proxy_create_for_id():

      wl_display_subscribe(display, id, new_id, my_version);

   or maybe

      wl_display_bind(display, id, new_id, my_version);

   Fixes a few things:

    - Maps the global object into the client id space, lets client
      allocate the id.  All ids are allocated by the client this way,
      which fixes the range protocol problem.

    - Tells the server that the client is interested in events from
      the object.  Lets the server know that a client participates in a
      certain protocol (like drag and drop), so the server can account
      for whether or not the client is expected to reply

    - Server emits initial object state event(s) in reponse to
      receiving the subscribe request.  Introduces an extra round trip
      at initialization time, but the server will still announces all
      objects in one burst and the client can subscribe in a burst as
      well.

    - Separates client resources, since each client will have it's own
      hash table.  It's not longer possible to guess the id of another
      surface and access it.

    - Server must track the client id for each client an object is
      exposed to.  In some cases we know this (a surface is always
      only owned by one client), in other cases it provides a way to
      track who's interested in the object events.  For input device
      events, we can look up the client name when it receives pointer
      focus or keyboard focus and cache it in the device.

    - Server must know which id to send when passing object references
      in events.  We could say that any object we're passing to a
      client must have a server id, and each client has a server id ->
      client id hash.

 - LCD subpixel info, dpi, monitor make and model, event when a
   surface moves from one output to another.

 - input device discovery, hotplug

    - Advertise axes as part of the discovery, use something like
      "org.wayland.input.x" to identify the axes.

    - keyboard state, layout events at connect time and when it
      changes, keyboard leds

    - relative events

    - multi touch?

    - synaptics, 3-button emulation, scim

 - drm bo access control, authentication, flink_to

 - Range protocol may not be sufficient... if a server cycles through
   2^32 object IDs we don't have a way to handle wrapping.  And since
   we hand out a range of 256 IDs to each new clients, we're just
   talking about 2^24 clients.  That's 31 years with a new client
   every minute...  Maybe just use bigger ranges, then it's feasible
   to track and garbage collect them when a client dies.

 - Add protocol to let applications specify the effective/logical
   surface rectangle, that is, the edge of the window, ignoring drop
   shadows and other padding.  The compositor needs this for snapping
   and constraining window motion.  Also, maybe communicate the opaque
   region of the window (or just a conservative, simple estimate), to
   let the compositor reduce overdraw.

 - Protocol for specifying title bar rectangle (for moving
   unresponsive apps) and a rectangle for the close button (for
   detecting ignored close clicks).

 - multi gpu, needs queue and seqno to wait on in requests

 - libxkbcommon

    - pull in actions logic from xserver

    - pull in keycode to keysym logic from libX11

    - expose alloc functions in libxkbcommon, drop xserver funcs?

    - pull the logic to write the xkb file from xkb_desc and names
      into libxkbcommon and just build up the new xkb_desc instead of
      dump+parse? (XkbWriteXKBKeymapForNames followed by
      xkb_compile_keymap_from_string in XkbDDXLoadKeymapByNames)

    - pull in keysym defs as XKB_KEY_BackSpace

    - figure out what other X headers we can get rid of, make it not
      need X at all (except when we gen the keysyms).

    - Sort out namespace pollution (XkbFoo macros, atom funcs etc).

    - Sort out 32 bit vmods and serialization

 - Automatic "triple buffering", ie, don't block on vsync if we're
   repainting below the refresh rate.

    - surface.attach triggers a compositor.release_buffer event when
      the buffer can be used again without messing things up (ie, it's
      no longer the front buffer, or the compositor has attached the
      new surface).

    - compositor sends out a repaint event (to who? do clients have to
      ask for this like they ask for the frame event?) once it has
      repainted the scene with the recent updates.

    - once a client receives the repaint event, it should start
      rendering its next frame.  If it has received a buffer release
      event for the old buffer, that can be reused, otherwise it has
      to allocate a third buffer (ie, we automatically do triple
      buffering for fullscreen surfaces).

    - if a client is triple buffering and receives a release event
      before the repaint event, it can go back to double buffering.

    - the repaint event needs some kind of timestamp to drive
      animations, since clients may not use the frame event at all.
      Could just be the time of the most recent frame.


Clients and ports

 - port gtk+

    - draw window decorations in gtkwindow.c

    - Details about pointer grabs. wayland doesn't have active grabs,
      menus will behave subtly different.  Under X, clicking a menu
      open grabs the pointer and clicking outside the window pops down
      the menu and swallows the click.  without active grabs we can't
      swallow the click.  I'm sure there much more...

    - dnd, copy-paste

 - Investigate DirectFB on Wayland (or is that Wayland on DirectFB?)

 - SDL port, bnf has work in progress here:
   http://cgit.freedesktop.org/~bnf/sdl-wayland/

 - libva + eglimage + kms integration

 - X on Wayland

    - map multiple wayland input devices to MPX in Xorg.

    - rootless; avoid allocating and setting the front buffer, draw
      window decorations in the X server (!), how to map input?


Ideas

 - A wayland settings protocol to tell clients about themes (icons,
   cursors, widget themes), fonts details (family, hinting
   preferences) etc.  Just send all settings at connect time, send
   updates when a setting change.  Getting a little close to gconf
   here, but could be pretty simple:

     interface "settings":
       event int_value(string name, int value)
       event string_value(string name, string value)

   but maybe it's better to just require that clients get that from
   somewhere else (gconf/dbus).


Crazy ideas

 - AF_WAYLAND - A new socket type.  Eliminate compositor context
   switch by making kernel understand enough of wayland that it can
   forward input events as wayland events and do page flipping in
   response to surface_attach requests:

    - ioctl(wayland_fd, "surface_attach to object 5 should do a kms page
			 flip on ctrc 2");

    - what about multiple crtcs? what about frame event for other
      clients?

    - forward these input devices to the client

    - "scancode 124 pressed or released with scan codes 18,22 and 30
       held down gives control back to userspace wayland.

    - what about maintaining cursor position? what about pointer
      acceleration?  maybe this only works in "client cursor mode",
      where wayland hides the cursor and only sends relative events?
      Solves the composited cursor problem.  How does X show its
      cursor then?

    - Probably not worth it.