Towards 1.0

Kristian Høgsberg krh at
Fri Feb 17 09:01:48 PST 2012


So with 0.85.0 Wayland and Weston released, it's a good time to figure
out what the plan is going forward.  We had a two day workshop in
Brussels leading up to FOSDEM and we went through the Wayland protocol
to figure out what's missing and what to do about various loose ends.
We also worked our way through ICCCM, EWMH and Xdnd, to make sure we
have an answer for the various functionality defined there.  I'll try
to summarize what we came up with below, but first a few practical

We now have bugzilla set up in  Nothing
surprising there, we have a wayland product and wayland and weston

Second, about branches, release plans and protocol/api breaking: we
start breaking things on master (both wayland and weston) now.  The
master branch is going to break API and protocol and that's going to
make it much harder to track things.  Of course, that's how it always
was (except for the brief freeze leading up to 0.85), but we do have a
lot of pent-up protocol changes that will start landing now.

The 0.85 branches are going to keep API and protocol stable, but I
don't see a problem in backporting bigger features like Pekkas
transformations or Jesses sprites.  It may make sense for toolkits to
stick with the 0.85 branch for as long as they don't need features
from the new protocol work.  For Gtk+, for example, we still have work
to do with dnd, client-side-decorations and popups and most of this
work can be done with 0.85.

I expect we'll take a few months to finish the protocol work and then
we'll start the 0.9x releases.  From this point on, the protocol
should not change in backwards incompatible ways.  The protocol
supports versioning and discovery of new interfaces, so we can extend
the protocol as we need, both as we move towards 1.0 and after 1.0.
Ideally we can incorporate the protocol changes pretty fast and then
sit on them for a while.  Once we haven't made protocol changes in a
while, we should be in a good spot to start freezing it.

Anyway, for the immediate future, we have a lot of stuff that we need
to work on.  I've tried to combine the TODO file from the wayland
repo, various notes of mine and the notes from FOSDEM.  I'll update
and consolidate all this back into the TODO file.

 - version/since attributes in the protocol xml.  Let's us keep track
of when a request or event was added to an interface and we can check
this against the negotiated version at runtime.

 - we need surface.enter/leave events to be emitted as the surface
enters and leaves outputs.  This lets us track which output(s) a
surface is currently showing on, which affects how we render (subpixel
information, dpi, rotation).  By using enter/leave events, a surface
can be on multiple output.

 - We need rotation information in the output (multiples of 90
degress) and we'll need a way for a client to communicate that it has
rendered it's 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 correctly and the compositor needs to know
that it did.

 - We need the fullscreen request.  Pretty much what has already been
discussed on the list.  We need to send a configure event to the
client as we go fullscreen, wait for the client to attach new buffer
before changing anything.

 - Brief talk about multi-gpu.  Not conclusive, but we have the option
of advertising multiple wl_drm objects, and let the client or EGL pick
which drm device to render to.  Perhaps different arguments to
eglGetDisplay or maybe a eglCreateWindowSurface attribute.

 - 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.  Concencus 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
is something in the protocol/architecute that makes it harder than it
should be.

 - remove wl_buffer.damage.  This is only used for wl_shm buffers and
is not a generic wl_buffer request.  We move it to wl_shm, and we'll
have to figure out how to get swrast to call it.

 - drop global coords in events.  clients have no use for this.

 - reconsider data types for coordinates in events.  double, floats or
fixed point.  Transformed and/or accelerated input generates sub-pixel
positions.  24.8 fixed point could work.  Need to think about the
range of coordinates we need.  Different from X problem, since we
don't have sub-windows, which is where X hits the 16 bit limitations.
Monitor and window sizes haven't yet out-grown the 16 bit range.

 - 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?

 - split pointer_focus into enter/leave event, split pointer events
into wl_pointer interface.  split keyboard events into wl_keyboard
interface, touch events into wl_touch.  Rename wl_input_device to
wl_seat.  Add mechanism to let wl_seat announce whether it has
wl_pointer/wl_keyboard/wl_touch devices.

 - add timestamp to touch_cancel, add touch id to touch_cancel (?)

 - serial numbers.  The wayland protocol, as X, uses timestamps to
match up certain requests with input events.  The problem is that
sometimes an event happens that triggers a timestamped event.  For
example, a surface goes away and a new surface receives a
pointer.enter event.  These events are normally timestamped with the
evdev event timestamp, but in this case, we don't have a evdev
timestamp.  So we have to go to gettimeofday (or clock_gettime()) and
then we don't know if it's coming from the same time source etc.  And
we don't really need a real time timestamp, we just need a serial
number that encodes the order of events inside the server.  So we need
to introduce a serial number mechanism (uint32_t, maintained in that we can use to order events, and have a look
at the events we send out and decide whether they need serial number
or timestamp or both.  We still need real-time timestamps for actual
input device events (motion, buttons, keys, touch), to be able to
reason about double-click speed and movement speed.  The serial number
will also give us a mechanism to key together events that are
"logically the same" such as a unicode event and a keycode event, or a
motion event and a relative event from a raw device.

 - the output protocol needs to send all the ugly timing details for the modes.

 - we need an input shape extension that lets the client set the input
shape of the window.  We can start with just a region-lite api, that
lets applications specify the region as a set of rectangles.  Should
we make a wl_region interface that encapsulates the region
building/updating api and then make a surface.set_input_region(region)
request?  We'll need the same thing for opaqe region.


 - 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)

 - 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

 - TRANSIENT_FOR handled by wl_shell_surface, WM_CLASS replaced by
.desktop file filename (absolute path if non-standard location)
WM_CLASS used for grouping windows in one button in a panel, for
example.  So we'll need a request to set that.

 - WM_TAKE_FOCUS, a workaround for lack of timestamp in the focus
event, not a problem for us, but we may need a "no kb focus please"
mechanism.  Or should this be implicit in a specific surface type?

 - Session management is dbus now.  The compsitor may talk to the dbus
session manager and communicate cookies to the session manager, that
allows the compositor to restore windows to their current state.


 - The EWMH standard has a lot of properties, window types and
language for standardizing out-of-process desktop components such as
pagers, panels and desktop backgrounds.  We're not going to try to
standardize that in 1.0, the focus is going to be on the communication
between regular applications and the desktop environment.  It
certainly possible to do with Wayland, and standardization could come
from different environments doing their own thing initially, and then
later try to consolidate.  desktop-shell and tablet-shell in weston
are good examples of custom interfaces to split the desktop
environment into several processes.

 - _NET_WM_NAME (shell_surface.set_title(utf8)), _NET_WM_ICON Is this
just another wl_surface? Do we need this if we have the .desktop file?
How to set multiple sizes?

 - ping event, essentially the opposite of the display.sync request.
Compositor can ping clients to see if they're alive (typically when
sending input events to a client surface)

 - Opaque region request.  This is an optimization to let the
compositor skip repainting content below an opaque area.  Share the
region interface with input region?

 - WM_USER_TIME is needed by a WM to implement focus stealing
prevention since it can't know when a random window last received
input events.  With the wm in the display server, this is not a

 - Don't need wl_surface pid, we know the client and can get creds
from the socket (should implement this).

 - move to workspace, keep on top, on all workspaces, minimize etc
requests for implementing client side window menu? or just make a
"show window menu" request?

 - window move and resize functionality for kb and touch.

 - dnd loose ends: drag icon; 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

 -  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 when
user clicks there.  We could use the region mechanism here too.

 - popup placement protocol logic.

 - subsurface mechanism.  we need this for cases where we would use an
X subwindow for gl or video other different visual type.

 - input protocol restructuring: break up events into wl_pointer
(enter/leave/motion/button/axis events, set_pointer_surface request),
wl_keyboard (enter/leave/key events... what else... unicode event,
set_map request? pending kb work), and wl_touch (down/up/motion/cancel
events) interfaces, rename wl_input_device to wl_seat.  wl_seat has
zero or one of each, and will announce this at bind time.  Raw devices
are also tied to a wl_seat, but we'll not do that for 1.0, we just
need to make sure wl_seat has a forward compatible way to announce


 - Land Anders gbm_surface patches.

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

 - Land Robert Braggs EGL extensions: start frame, frame age, swap with damage

 - Make it possible to share buffers from compositor to clients.
Tricky part here is how to indicate to EGL on the server side that it
should make an EGLImage available to a client.  We'll need a "create a
wl_buffer for this EGLImage for this client" kind of entry point.

 - gbm get_format patch, Jesses sprite patches.


 - dpms/backlight control.  we need this to be a real display server.

 - Framebased input event delivery.  Only process input events at the
beginning of new frames instead of as they come in.

Anyway, that's the big list.  There's no particular order to it and
there are huge tasks and trivial stuff in there, but it's a fairly
complete list.  We have a  lot of patches sitting on the mailing list
and I'm starting to review and merge them now, which should address a
lot of the issues here.  If I miss something, feel free to resend that
patches and ideal also put the branch somewhere where I can just pull


More information about the wayland-devel mailing list