Hello, 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 things.
We now have bugzilla set up in bugs.freedesktop.org. Nothing surprising there, we have a wayland product and wayland and weston components: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland 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 libwayland-server.so) 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. 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) - 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. EWMH - 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 problem. - 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 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 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 them. EGL/gbm - 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. Weston - 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 it. thanks, Kristian _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
