Update TODO

NOTES

@@ -45,40 +45,6 @@ returned in an event generated by the server once the commit has been
 executed.  This allows clients to throttle themselves against the
 server and implement smooth animations.
 
-
-ISSUES:
-
-Include panel and desktop background in wayland?
-
-How does clients move their surfaces? set a full tri-mesh every time?
-
-How does the server apply transformations to a surface behind the
-clients back? (wobbly, minimize, zoom)  Maybe wobble is client side?
-
-How do apps share the glyph cache?
-
-Input handling - keyboard focus, multiple input devices, multiple
-pointers, multi touch.
-
-Drawing cursors, moving them, cursor themes, attaching surfaces to
-cursors.  How do you change cursors when you mouse over a text
-field if you don't have subwindows?
-
-synaptics, 3-button emulation, xkb, scim
-
-changing screen resolution, adding monitors.
-
-What to do when protocol out buffer fills up?  Just block on write
-would work I guess.  Clients are supposed to throttle using the bread
-crumb events, so we shouldn't get into this situation.
-
-When a surface is the size of the screen and on top, we can set the
-scanout buffer to that surface directly.  Like compiz unredirect
-top-level window feature.  Except it won't have any protocol state
-side-effects and the client that owns the surface won't know.  We lose
-control of updates.  Should work well for X server root window under
-wayland.
-
 Throttling/scheduling - there is currently no mechanism for scheduling
 clients to prevent greedy clients from spamming the server and
 starving other clients.  On the other hand, now that recompositing is

TODO

@@ -1,5 +1,11 @@
  - sync-to-vblank
 
+ - how does clients move their surfaces? set a full tri-mesh every
+   time? probably just go back to x and y position, let the compositor
+   do the fancy stuff.  How does the server apply transformations to a
+   surface behind the clients back? (wobbly, minimize, zoom) Maybe
+   wobble is client side?
+
  - switch scanout when top surface is full screen
 
     - what about cursors then?  maybe use hw cursors if the cursor
@@ -13,6 +19,14 @@
     - 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
+
+    - relative events
+
+    - input handling - keyboard focus, multiple input devices,
+      multiple pointers, multi touch.
+
  - wayland-system-compositor
 
     - device kit/libudev/console kit integration to discover seats,
@@ -108,10 +122,20 @@
       desired data to write, if it overwrites tail, block guest.  just
       a socket would be easier.
 
+ - moblin as a wayland compositor
+
+    - clutter as a wayland compositors
+
+    - argh, mutter
+
  - make libwayland-client less ghetto
 
  - sparse based idl compiler
 
+    - crack?
+
+    - xml based description instead?
+
  - actually make batch/commit batch up commands
 
  - protocol for setting the cursor image
@@ -119,6 +143,19 @@
     - should we have a mechanism to attach surface to cursor for
       guaranteed non-laggy drag?
 
+    - drawing cursors, moving them, cursor themes, attaching surfaces
+      to cursors.  How do you change cursors when you mouse over a
+      text field if you don't have subwindows?  This is what we do: a
+      client can set a cursor for a surface and wayland will set that
+      on enter and revert to default on leave
+
+ - server should be able to discard surfaces, and send a re-render
+   event to clients to get them to render and provide the surface
+   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.
+
  - auth; We need to generate a random socket name and advertise that
    on dbus along with a connection cookie.  Something like a method
    that returns the socket name and a connection cookie.  The
@@ -127,6 +164,10 @@
    Wayland server generates the cookie on demand when the dbus method
    is called and expires it after 5s or so.
 
+    - or just pass the fd over dbus
+
+ - drm bo access control, authentication, flink_to
+
  - enter/leave events from the input devices
 
  - gain, lose keyboard focus events; this event carries information
@@ -138,4 +179,27 @@
    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.
+   to track and garbage collect them when a client dies.
+
+ - multi gpu, needs queue and seqno to wait on in requests
+
+ - opaque region, window rect
+
+ - save and restore state on crash, clients reconnect, re-render
+   buffers
+
+ - how do apps share the glyph cache?  what is the glyph cache, how
+   does it work?  pixbuf cache?
+
+ - synaptics, 3-button emulation, scim
+
+ - what to do when protocol out buffer fills up?  Just block on write
+   would work I guess.  Clients are supposed to throttle using the
+   bread crumb events, so we shouldn't get into this situation.
+
+ - when a surface is the size of the screen and on top, we can set the
+   scanout buffer to that surface directly.  Like compiz unredirect
+   top-level window feature.  Except it won't have any protocol state
+   side-effects and the client that owns the surface won't know.  We
+   lose control of updates.  Should work well for X server root window
+   under wayland.