The Technical Plans For Making Wayland 1.0
After laying out plans earlier this month at FOSDEM for releasing Wayland 1.0 this year, Kristian Høgsberg has now written a more detailed message to the Wayland developers that outlines some of the TODO list and other plans for making Wayland 1.0.
Kristian's message in full can be found on the Wayland mailing list. This message from the founder of the Wayland project is quite lengthy, but here's some snippets and key points:
- Now that Wayland/Weston 0.85 was released, API and protocol breaks will happen again for Wayland and Weston (Wayland's reference compositor) soon on master. However, the 0.85 branches will maintain API compatibility.
- A key paragraph about the API/protocol changes moving forward, "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."
- Among the TODO list items are surface enter/leave events for outputs, rotation information for outputs, the full-screen request support, multi-GPU support, remote Wayland support, modifiers for pointer axis events, serial numbers, many ICCCM improvements, EWMH work, and various EGL/GBM changes.
- In terms of Wayland's multi-GPU rendering support, Kristian said, "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."
- About "remote Wayland" support, "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." This past summer was the not too successful remote Wayland project as part of Google Summer of Code.
- Some of the Weston work towards version 1.0 with the reference compositor is DPMS/backlight control support and frame-based input event delivery.
Expect the Wayland/Weston 1.0 release in 2012, but it won't cause world domination and don't expect Wayland to really start attracting major changes on the Linux desktop until 2013.
Kristian's message in full can be found on the Wayland mailing list. This message from the founder of the Wayland project is quite lengthy, but here's some snippets and key points:
- Now that Wayland/Weston 0.85 was released, API and protocol breaks will happen again for Wayland and Weston (Wayland's reference compositor) soon on master. However, the 0.85 branches will maintain API compatibility.
- A key paragraph about the API/protocol changes moving forward, "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."
- Among the TODO list items are surface enter/leave events for outputs, rotation information for outputs, the full-screen request support, multi-GPU support, remote Wayland support, modifiers for pointer axis events, serial numbers, many ICCCM improvements, EWMH work, and various EGL/GBM changes.
- In terms of Wayland's multi-GPU rendering support, Kristian said, "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."
- About "remote Wayland" support, "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." This past summer was the not too successful remote Wayland project as part of Google Summer of Code.
- Some of the Weston work towards version 1.0 with the reference compositor is DPMS/backlight control support and frame-based input event delivery.
Expect the Wayland/Weston 1.0 release in 2012, but it won't cause world domination and don't expect Wayland to really start attracting major changes on the Linux desktop until 2013.
17 Comments