Plans for 1.2

[Kristian Høgsberg]

Hello,

So here's my mail with ideas, plans and schedule for 1.2.  First off,
I realize that 1.1 might have happened a bit fast and I don't remember
if I posted about plans for further major release before, so I'll talk
about that now.  What I'd like to do is to release a new major version
every quarter.  So we'll be aiming for 1.2 end of June, 1.3 end of
September and so on.  The motivation for this is that we have a lot of
new features and new protocol in the works and a time-based release
schedule is a good way to flush out those features.  Instead of
dragging out a release while waiting for a feature to become ready, we
release on a regular schedule to make sure the features that did land
get released on time.

As mentioned before, as we roll out new releases, we will never break
the protocol or the client side API.  We don't guarantee anything
about the wayland-server API for now, but as more non-weston
compositor starts to appear (QtCompositor, Enlightenment, GNOME Shell,
KWin), we'll want to think about how to stabilize that API too.  In
particular, if we relelase every three months and break server side
API each time, things will get out of hand fast.

As for ideas and plans for 1.2, we definitely want the subsurface work
from Pekka and Jans input method work in 1.2.  Pekka should be back on
subsurface again soon, and it's close to done as it is, so I'm
confident we can get that done.  Jans works is also mostly complete,
but I'd like to see wider verification of the work.  To that end we're
working on EFL integration and the GNOME project will also review and
start integrating the functionality.  This is not a comment on Jan's
good work - wayland itself was running on five different toolkits
before we called 1.0, so we're just continuing our tradition of broad
validation.

Beyond the features we carry over from the 1.1 plan, there's a lot of
open issues and new functionality we can consider for 1.2.  The list
here is a little under-edited; some issues are fairly well-described,
others are merely keywords, but I've been trying to get this email out
for too long already.  Reply if you want something elaborated or want
to work on some of these issues.

  • Trim libwayland-server down to just IPC.  As mentioned above, we
    need a plan for keeping libwayland-server API stable.  Looking at
    the functionality in the server library, it's clear (in hindsight)
    that there are two different "things" in there: 1) The IPC API,
    that is, everything that concerns wl_display, wl_client,
    wl_resource and 2) and half-hearted attempt at sharing input code
    and focus logic that leaves a lot of problematic structs in the
    API surface, only to share less than 1000 lines of code.

    My idea here is that we can just move those input structs and
    helper functions into weston and cut libwayland-server down to
    just the core server side IPC API.  In the short term, compositors
    can copy those structs and functions into their source, but longer
    term, they're probably better off reimplementing those objects and
    logic their native framework (QObject, GObject etc).

  • weston-launcher: We talked about moving VT-switching to
    weston-launcher to let it handle the VT-switch signals and tty
    setup.  The launcher can drop and set master around VT switch
    automatically, use evdev mute [1], and recover the console if
    weston crashes.

    [1] http://marc.info/?l=linux-input&m=136612070607484&w=1

  • Popup placement protocol.  Rob just reposted his patches, we need
    to try them in at least on real-world toolkit before committing to
    the appraoch.

  • Pointerlock (http://www.html5rocks.com/en/tutorials/pointerlock/intro/)

    Original RFC here, and there's a revised 5 patch series after that:

      http://lists.freedesktop.org/archives/wayland-devel/2013-February/007635.html

    I think the feature is good and I've verified with the doom3 port
    and other FPS style games.  I think the remaining issue is whether
    or not to include pointer warping in the lock interfaces.

  • Core protocol gaps.  We've identified a number of missing requests
    or events in the protocl that we need to fix or work around:

      ‣ communicate key repeat parameters
      ‣ ennumerate mouse buttons
      ‣ popup serial semantics
      ‣ workspace size event
      ‣ destroy requests for globals (pointer, keyboard and touch,
        others. wl_pointer.close),

  • The locking issues I've been working on in the acquire-fd patch.
    I have an updated patch I'll send out soon.

  • Richard Hughes color management work.

  • Handle SYN_DROPPED.  Martin tracked down his dropped button click
    to SYN_DROPPED and we need to handle that correctly.

  • Backend for DisplayLink type devices - or maybe this is just a new
    compositor-drm.c feature.

  • Mouse motion binding from giucam.  This feature is obviously
    useful, just not sure if we want to use the binding abstraction.
    Maybe some kind of event filter mechanism.

  • Remote display - still on the table, but low priority.  I'd like
    to merge the branch with a few clean-ups soon, it's fairly
    self-contained.

  • xwayland: set_transient with no parent crash (bring back vignattis
    fixes from the xwm client branch).  Make xwayland support DRI2
    swapbuffers.  MWM Resize hints.  Double buffer decoration drawing.
    DND bridge between wayland and X (fun!).  Window icons, frame
    buttons.  Use popup shell surface for X popups so the X grab for
    menus work correctly (also fun!).

Kristian