Update TODO

[profile/ivi/wayland.git] / TODO

diff --git a/TODO b/TODO
index abdab31..8cb8d34 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,64 +1,11 @@
 Core wayland protocol
 
 Core wayland protocol
 

- - We need rotation information in the output (multiples of 90
-   degrees) and we'll need a way for a client to communicate that it
-   has rendered its buffer according to the output rotation.  The
-   goal is to be able to pageflip directly to the client buffer, and
-   for that we need the client to render accordingly and the
-   compositor needs to know that it did.
-
- - Atomicity.  Currently a lot of the atomicity in Wayland relies on
-   how we batch up all requests in a protocol buffer and only flushes
-   in the "blockhandler" in the client.  Consensus was that we need
-   something more reliable and explicit.  The suggestion is that we
-   make surface.attach a synchronization point such that everything
-   before that is batched and applied atomically when the
-   surface.attach request comes in.  For cases where we need atomicity
-   beyond a surface.attach, we can add an atomic grouping mechanism,
-   that can group together multiple surface.attach requests into a
-   bigger atomic change.  To be researched a bit.
-
- - We should make pointer sprites regular surfaces.  Something like
-   input_device.set_sprite(surface).  This also make client side
-   animated cursors simple/possible, since we now get a frame event
-   that can drive the animation.
-

  - Maybe try to make remote wayland actually happen, to see if there
  - Maybe try to make remote wayland actually happen, to see if there

-   is something in the protocol/architecute that makes it harder than
+   is something in the protocol/architecture that makes it harder than

    it should be.
 
    it should be.
 

- - Key events need a bit more work/thinking/redesign. As it is we need
-   a mechanism to change and synchronize keymaps, repeat rates.  But
-   as we started talking, we decided that we needed to go back and
-   research what other systems do instead of just essentially copying
-   the X model.  Sending out unicode events in addition to keycode
-   events has a lot of benefits (OSK can send out unicode events
-   instead of fake keycode events, apps become much simpler...)  Move
-   keymap handling and repeat to the server?  Needs more research.
-
- - Pointer axis events need modifiers (ctrl-scroll eg), but we either
-   need to send the modifier state with each axis/scroll event or send
-   keys down on pointer_focus and subsequent key events... or just key
-   events for modifier keys... or for the non-repeating subset?
-
- - Add timestamp to touch_cancel, add touch id to touch_cancel (?)
-
- - The output protocol needs to send all the ugly timing details for the modes.
-

 ICCCM
 
 ICCCM
 

- - clipboard manager interface?  what's needed?  just notification
-   that the selection has gone away.  should the clipboard manager be
-   able to take over the selection "seamlessly", ie, with the same
-   timestamp etc?  Doesn't seem like we need that, the clipboard will
-   have to set a new data_source anyway, with the subset of mimetypes
-   it offers (the clipboad manager may only offer a subset of the
-   types offered by the original data_source)
-
-   The trouble is that when the clipboard manager sets a new data
-   source, we don't want to renew the timestamp and potentially reject
-   a newer "real" data source.
-

  - mime-type guidelines for data_source (ie, both dnd and selection):
    recommended types for text or images, types that a clipboard
    manager must support, mime-types must be listed in preferred order
  - mime-type guidelines for data_source (ie, both dnd and selection):
    recommended types for text or images, types that a clipboard
    manager must support, mime-types must be listed in preferred order


@@ -78,10 +25,6 @@ EWMH
 
  - window move and resize functionality for kb and touch.
 
 
  - window move and resize functionality for kb and touch.
 

- - dnd loose ends: self-dnd: initiate dnd with a null data-source,
-   compositor will not offer to other clients, client has to know
-   internally what's offered and how to transfer data. no fd passing.
-

  - Protocol for specifying title bar rectangle (for moving
    unresponsive apps).  Rectangle for close button, so we can popup
    force-close dialog if application doesn't respond to ping event
  - Protocol for specifying title bar rectangle (for moving
    unresponsive apps).  Rectangle for close button, so we can popup
    force-close dialog if application doesn't respond to ping event


@@ -95,8 +38,6 @@ EWMH
 
 EGL/gbm
 
 
 EGL/gbm
 

- - Don't wl_display_iterate in eglSwapBuffer, send an eventfd fd?
-

  - Land Robert Braggs EGL extensions: frame age, swap with damage
 
  - Make it possible to share buffers from compositor to clients.
  - Land Robert Braggs EGL extensions: frame age, swap with damage
 
  - Make it possible to share buffers from compositor to clients.


@@ -113,6 +54,7 @@ EGL/gbm
    allocate a scanout buffer now" event to the fullscreen-to-be
    client.
 
    allocate a scanout buffer now" event to the fullscreen-to-be
    client.
 

+

 Misc
 
  - glyph cache
 Misc
 
  - glyph cache


@@ -143,6 +85,7 @@ Misc
    switching away from.  for minimized windows that we don't want live
    thumb nails for. etc.
 
    switching away from.  for minimized windows that we don't want live
    thumb nails for. etc.
 

+

 Clients and ports
 
  - port gtk+
 Clients and ports
 
  - port gtk+


@@ -162,8 +105,6 @@ Clients and ports
  - SDL port, bnf has work in progress here:
    http://cgit.freedesktop.org/~bnf/sdl-wayland/
 
  - SDL port, bnf has work in progress here:
    http://cgit.freedesktop.org/~bnf/sdl-wayland/
 

- - libva + eglimage + kms integration
-

 
 Ideas
 
 
 Ideas