Re: wayland-protocols scope and governance
On Tue, Feb 19, 2019 at 5:50 PM Daniel Stone wrote: > > Hi all, > I'd like to open up a discussion on enlarging wayland-protocols to a > wider audience, with a better definition of what it contains. Hi Daniel, thanks for moving forward this discussion. To me your suggestions overall sound very sensible. > Currently, wayland-protocols is a relatively small set of protocols > which were either grandfathered in from Weston, or a semi-opinionated > set of protocols that someone thinks is 'good'. > > The original intent was to provide a set of 'blessed' desktop > protocols which 'everyone' would probably implement in order to > provide a coherent Wayland environment. To some extent - xdg-shell, > dmabuf, xdg-output, viewporter - this succeeded. For some others, it > failed badly - the input protocols no-one likes or has implemented, > necessitating Dorota's rewrite. > > The elephant in the room is extensions like layer-shell and some of > the related extensions to build a desktop environment from a set of > disparate clients using generic APIs. Personally I think the > experience of X11 shows it's only designing for pain, and this is the > general position of wayland-protocols at the moment. But on the other > hand, those protocols aren't going away, they are in use, and having > them developed in a separate siloed community is doing us all a > disservice, since neither hand fully knows what the other is doing. > Even if we don't agree on the fundamentals of the protocol, we could > at least discuss it and try to point out some pitfalls and make some > suggestions for improvement. > > A related issue is that it's hard for both application and compositor > authors to figure out what to do. There is no good 'big picture' on > how these protocols fit together, nor can people figure out which of > the competing proposals they should be using if they want to write an > application running on a given compositor, nor can compositor authors > figure out what apps want them to support. Depending on who happens to > be paying attention to the particular forum the question is asked, > they might get very different answers, depending on the point of view > of who answers. > > My first, hopefully uncontroversial, suggestion: introduce a list of > compositors / compositor frameworks, as well as clients / client > frameworks, and which protocols they use and support. This would help > both application and compositor authors figure out where they should > invest time and effort. I suggest that we keep this lightweight: have > a registry of compositors / compositor frameworks / toolkits / > clients, each with a couple of named people who can speak > authoritatively for that project. > > We could then allow each project to declare its support (or otherwise) > for any extension: will not ever implement, implementation not > planned, no opinion or N/A, implementation planned, implemented but > use not recommended (or limited/stubbed), implemented and recommended. > This list would be machine-parseable (XML, JSON, YAML, whatever is > easiest to fit), with a GitLab CI pipeline used to generate a > https://wayland.freedesktop.org/protocols/ website on every push, > which gave both a per-extension and a per-project support table. And > some more readable docs. I think this would be a really good entry > point and clear up a lot of confusion. > > As a strawman list of projects to begin with (I'm sure there are others): > - compositors and compositor frameworks: Chromium (Exosphere), > Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots > - toolkits: EFL, GTK, Qt > - media: GStreamer, Kodi, VLC, XBMC > - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan) For completeness KWin uses the KDE Framework KWayland, that wraps common Wayland structs to be nicely consumed by Qt/Cpp based compositors. Writing a Wayland compositor is also possible with QtWayland, which is more high-level. > My second suggestion is to formalise the 'xdg' namespace. xdg > extensions have been accepted or rejected by rough consensus between > Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough > to me, assuming that 'xdg' retains the focus of an integrated (as > opposed to build-it-yourself) desktop. The IVI namespace would > similarly be delegated to automotive people, and maybe we could > delegate the layer_ namespace to those developers as well. I would formalize the xdg namespace (also in regards to what Simon said) as protocols for "up to a fully integrated desktop". In this notion a fully integrated desktop is defined as the most comprehensive form of what the protocols there try to accomplish, while it does not exclude other maybe less complex or more specialized compositors and devices, like phone UIs from using a sub-set of xdg-protocols, if they are useful in there specific use cases. The "build-it-yourself" desktops would then fall somewhere in the middle of the complexity-range and could still
[ANNOUNCE] weston 5.0.91
This is the alpha release for weston 6.0. A lot has happened for this release, some big items to note are: We now have xdg-shell stable support! We've moved to meson as our primary build system and have deprecated the autotools build entirely. You need to run configure with --enable-autotools to use autotools, and we will be removing autotools after the 6.0 release. Full commit history follows: Alexandros Frantzis (11): xwayland: Silence format-truncation compilation warnings clients: Add simple-dmabuf-egl clients/simple-dmabuf-egl: Support dmabuf format modifiers clients/simple-dmabuf-egl: Render a moving square libweston: Introduce zwp_linux_explicit_synchronization_v1 libweston: Introduce an internal linux sync file API libweston: Support zwp_surface_synchronization_v1.set_acquire_fence libweston: Support zwp_surface_synchronization_v1.get_release tests: Add tests for per commit zwp_buffer_release_v1 behavior clients: Support explicit synchronization in simple-dmabuf-egl clients: Add a mandelbrot set shader to simple-dmabuf-egl Arkadiusz Hiler (1): compositor-drm: Log atomic commits and flips Changwoo Cho (1): libweston: fix typo in comment Daniel Stone (14): CONTRIBUTING: How do I get started? compositor: Add weston_layer_mask_is_infinite compositor: Add scene-graph debug scope compositor-drm: Calculate atomic-commit flags earlier compositor-drm: Add backend pointer to drm_output compositor-drm: Add drm-backend log debug scope gl-renderer: Remove warning on missing extensions compositor-drm: Don't warn about missing backlight control tests: Rename surface-screenshot tests: fix include in input-timestamps-helper.c Add Meson build system CI: Add Meson build gitlab-ci: Actually capture Meson logs compositor-drm: Fall back if GBM surface fails with modifiers David Fort (1): rdp-compositor: fix compilation with FreeRDP 2.0-rc4 Deepak Rawat (1): compositor-drm: Read FB2_MODIFIERS capability Derek Foreman (2): configure.ac: Reopen master for regular development configure.ac: bump to version 5.0.91 for the alpha release Dima Ryazanov (4): Don't look for weston.ini in the current working directory Revert "Fix a crash when unlocking or unconfining a pointer" clients: Delete an unused variable clients: A better fix for a crash when unlocking or unconfining a pointer Emil Velikov (2): libweston: split EGL and GL info logging libweston: print EGL information as early as possible Emmanuel Gil Peyrot (1): ivi-shell: Add missing sentence point Emre Ucan (7): ivi-shell: Add build_view_list function ivi-shell: unmap views which are not in scenegraph ivi-shell: check ivi_view mappedness in commit_changes() ivi-shell: don't use input panel implementation ivi-shell: remove input panel implementation ivi-shell: remove unused functions and members ivi-shell: remove input-method section from config Eric Engestrom (2): meson: fix -Wno-foo argument testing Revert "meson: fix -Wno-foo argument testing" Eric Toombs (3): man: fix small typo: directroy weston: deprecate enable_tap in favour of enable-tap weston: add more libinput config options Greg V (8): build: use pkg-config to find libjpeg in meson build: use '-Wl,' wrapper for the -export-dynamic linker flag build: add missing wayland-client dep in meson desktop-shell: extract view_get_transform, make it reliable xwayland: fix clipboard related crash xwm: fix resize grab related crash desktop-shell: fix resize grab related crash desktop-shell: remove surface destroy listener when focus state is destroyed Jonas Ã…dahl (1): gitlab-ci.yml: Install meson from 0.49 branch Marius Vlad (25): pixel-formats: Added pixel_format_get_info_shm() helper for printing SHM buffers compositor: Make pixel format printing in human-friendly form Fix compiler warnings generated by older toolchains/compiler Fix compiler warnings: clobber variables Fix compiler warnings: invalid type format Fix compiler warning: unused variable when building with DEBUG libweston/compositor-drm: Print composition mode in weston-debug libweston/compositor-drm: No need to test for invalid alpha for the view libweston/compositor-drm: Add missing debug message for scanout_view clients/screenshot: Avoid using global variables to pass down data between functions clients/screenshot: Allow weston-screenshooter to be called directly libweston/weston-debug: Add a easy way to determine if the debug protocol has been enabled libweston: Allow taking screenshots when debug protocol is enabled ivi-shell/hmi-controller: Include config.h as to not break ivi-shell build on meson
[ANNOUNCE] wayland 1.16.91
This is the alpha release for wayland 1.17. In addition to some clean-ups and bug fixes, we now have protocol to express an internal server error message, and a new version of the wl_seat protocol with no changes other than keymaps must be private. Full commit history follows: Christopher James Halse Rogers (2): server: Split out varargs version of wl_resource_post_error. proto, server: Add internal server error message. (v2) Daniel Stone (6): scanner: Plug two memory leaks scanner: Mark fail() as noreturn scanner: Reverse expat/libxml include order tests: Use volatile pointer for NULL dereference tests: Overly elaborate compiler warning workaround tests: Remove memory leak checking infrastructure Derek Foreman (3): configure.ac: Reopen master for regular development protocol: Bump seat to version 7 and require keymaps be private configure.ac: bump version to 1.16.91 for the alpha release Eric Engestrom (1): TODO: remove "SDL port", it's been done by now Simon Ser (2): protocol: prefer wl_surface.damage_buffer Print NULL strings as "nil" in wl_closure_print git tag: 1.16.91 https://wayland.freedesktop.org/releases/wayland-1.16.91.tar.xz MD5: 711fea532899f2de096ebafdc54d1e3f wayland-1.16.91.tar.xz SHA1: 35eae388ad02b42e8e5004e214ef92230afb5eaa wayland-1.16.91.tar.xz SHA256: d51b83a51034ed5474517e0b0bca2d4e7056e4c51d720ea885f0c34f243fee90 wayland-1.16.91.tar.xz SHA512: 5c1a96cbe31d36386f66b9d02fce4f5eb96e93b3a602124a57966f06f1103d8fd7035a8084816c4b51f21adea4dde73f5d293295fbd7227b270ca95efa19b56f wayland-1.16.91.tar.xz PGP: https://wayland.freedesktop.org/releases/wayland-1.16.91.tar.xz.sig ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
This is a great plan, Daniel, thank you for taking the time to write it up and help push this problem towards a solution. On 2019-02-19 4:50 PM, Daniel Stone wrote: > My first, hopefully uncontroversial, suggestion: introduce a list of > compositors / compositor frameworks, as well as clients / client > frameworks, and which protocols they use and support. This would help > both application and compositor authors figure out where they should > invest time and effort. I suggest that we keep this lightweight: have > a registry of compositors / compositor frameworks / toolkits / > clients, each with a couple of named people who can speak > authoritatively for that project. > > As a strawman list of projects to begin with (I'm sure there are others): > - compositors and compositor frameworks: Chromium (Exosphere), > Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots Sway & wlroots probably shouldn't be separate, but it might be useful to link to the list of wlroots-based projects from the compatability page: https://github.com/swaywm/wlroots/wiki/Projects-which-use-wlroots These projects rarely, if ever, implement protocols themselves, opting instead to implement them in wlroots and share the functionality with everyone else. > - toolkits: EFL, GTK, Qt GLFW, SDL > - media: GStreamer, Kodi, VLC, XBMC mpv > - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan) This might start getting out of hand, I think. Here's an incomplete list of clients which use wlr protocols: - mako - slurp - grim - wl-stream - xdg-desktop-portal-wlr - swaylock - swayidle - swaybg (soon) - waybar - jaybar - phosh - virtboard - bemenu This is just the clients I can think of off the top of my head. Consider also demo clients, like weston and wlroots clients. There's going to be a lot of clients! Something I want to avoid is making the criteria for inclusion in the list subjective, and if we have to decide what makes GLFW worth including and weston-simple-egl worth excluding, I fear politics will ensue. > My second suggestion is to formalise the 'xdg' namespace. xdg > extensions have been accepted or rejected by rough consensus between > Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough > to me, assuming that 'xdg' retains the focus of an integrated (as > opposed to build-it-yourself) desktop. What is the criteria for having a voice in this xdg namespace "consensus"? This seems a bit opinionated and subjective. > Or Weston hasn't implemented xdg_foreign and probably won't, but I'm > fine with it existing and being a common extension. On the other hand, > Weston/Mutter/etc would have very strong opposition to a 'wp_randr' > extension, and last I saw wlroots would have very strong opposition to > wp_pointer_gestures. So those wouldn't be wp. This makes me wonder: what's the role of Weston in this? As a reference compositor which isn't designed for end-users, I don't think Weston has ever been well-positioned to be an influencer on Wayland, but should rather be a reflection of what Wayland is without its influence. Do you have any thougths on this? In other words, if Weston doesn't want to implement $protocol: so what? How do/should the gatekeepers of Weston make these decisions? > Bikeshedding the prefix to use [for vetoed but still relevant > protocols] would be welcome, as I don't have any good suggestions > right now. xdg? I think gatekeeping the xdg namespace is going to allow a lot of the frustrating politics to thrive even with these changes, and it is a nice namespace for defining these standards. > Once we've established and codified these ground rules - with a > document along the lines of Wayland's CONTRIBUTING.md - we can open up > commit access to wayland-protocols, so we're not so reliant on a > couple of arbitrary gatekeepers. Obviously this would be done with the > expectation that those ground rules are followed - don't post a wp_ > extension on a Sunday morning and then commit it in the evening with a > couple of +1s because no-one objected - but we're all reasonable > adults, and can treat each other reasonably without having to enforce > ACLs. > > Does anyone have any thoughts or suggestions here? Is this a good > aspiration? Is it the best way of achieving that aspiration? +1 I don't see commit access as a magic equalizer, fwiw. I don't mind sending a patch along and letting someone else integrate it so long as they're following well-defined policies and not operating under their own agenda. Another thing I'd like to clarify is the process of agreeing on the appropriate prefix for a protocol. Perhaps there's an experimental_ or draft_ namespace which has a near-zero barrier to entry (just add your implementation to the list), and then you can separately make your case for adopting it into another namespace. During the draft step you can pitch your protocol to interested parties, write implementations, and so on, which strengthens the case
Re: wayland-protocols scope and governance
On Tuesday, February 19, 2019 5:50 PM, Daniel Stone wrote: > Hi all, > I'd like to open up a discussion on enlarging wayland-protocols to a > wider audience, with a better definition of what it contains. First of all, thanks a lot for bringing this up and taking the time to write a proposal! > Currently, wayland-protocols is a relatively small set of protocols > which were either grandfathered in from Weston, or a semi-opinionated > set of protocols that someone thinks is 'good'. > > The original intent was to provide a set of 'blessed' desktop > protocols which 'everyone' would probably implement in order to > provide a coherent Wayland environment. To some extent - xdg-shell, > dmabuf, xdg-output, viewporter - this succeeded. For some others, it > failed badly - the input protocols no-one likes or has implemented, > necessitating Dorota's rewrite. > > The elephant in the room is extensions like layer-shell and some of > the related extensions to build a desktop environment from a set of > disparate clients using generic APIs. Personally I think the > experience of X11 shows it's only designing for pain, and this is the > general position of wayland-protocols at the moment. But on the other > hand, those protocols aren't going away, they are in use, and having > them developed in a separate siloed community is doing us all a > disservice, since neither hand fully knows what the other is doing. > Even if we don't agree on the fundamentals of the protocol, we could > at least discuss it and try to point out some pitfalls and make some > suggestions for improvement. Thanks for recognizing these protocols even if you don't agree. I think the way xdg-decoration has been standardized is also a good example of this (thanks again Jonas for your review). > A related issue is that it's hard for both application and compositor > authors to figure out what to do. There is no good 'big picture' on > how these protocols fit together, nor can people figure out which of > the competing proposals they should be using if they want to write an > application running on a given compositor, nor can compositor authors > figure out what apps want them to support. Depending on who happens to > be paying attention to the particular forum the question is asked, > they might get very different answers, depending on the point of view > of who answers. > > My first, hopefully uncontroversial, suggestion: introduce a list of > compositors / compositor frameworks, as well as clients / client > frameworks, and which protocols they use and support. This would help > both application and compositor authors figure out where they should > invest time and effort. I suggest that we keep this lightweight: have > a registry of compositors / compositor frameworks / toolkits / > clients, each with a couple of named people who can speak > authoritatively for that project. > > We could then allow each project to declare its support (or otherwise) > for any extension: will not ever implement, implementation not > planned, no opinion or N/A, implementation planned, implemented but > use not recommended (or limited/stubbed), implemented and recommended. > This list would be machine-parseable (XML, JSON, YAML, whatever is > easiest to fit), with a GitLab CI pipeline used to generate a > https://wayland.freedesktop.org/protocols/ website on every push, > which gave both a per-extension and a per-project support table. And > some more readable docs. I think this would be a really good entry > point and clear up a lot of confusion. +1 This is a very good idea. This will probably make it easier to know when it's okay to stop supporting old versions of some protocols too. Right now we have to build such a list ourselves [1]. [1]: https://github.com/swaywm/sway/issues/3690 > My second suggestion is to formalise the 'xdg' namespace. xdg > extensions have been accepted or rejected by rough consensus between > Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough > to me, assuming that 'xdg' retains the focus of an integrated (as > opposed to build-it-yourself) desktop. I'm kind of confused regarding "xdg", so I'll let others comment on this one. Here's a quote from Jonas regarding this prefix: > "xdg" shouldn't be seen as a "desktop" (device that sits on a desk) thing, > but a place to put protocols that aims to "bridge" different environments, > be they things running in devices placed on desks or in hands. There's also the case of xdg-decoration, which GNOME disagrees with but KDE agrees on. > The IVI namespace would similarly be delegated to automotive people, and > maybe we could delegate the layer_ namespace to those developers as well. We only have one protocol with the "layer_" prefix right now, and I don't think we'll have more. So I'm not sure it's worth it to have it as a prefix. Maybe another name would be better? The list of protocols we implement right now is available at [2] (of course, I'm not saying all of them
wayland-protocols scope and governance
Hi all, I'd like to open up a discussion on enlarging wayland-protocols to a wider audience, with a better definition of what it contains. Currently, wayland-protocols is a relatively small set of protocols which were either grandfathered in from Weston, or a semi-opinionated set of protocols that someone thinks is 'good'. The original intent was to provide a set of 'blessed' desktop protocols which 'everyone' would probably implement in order to provide a coherent Wayland environment. To some extent - xdg-shell, dmabuf, xdg-output, viewporter - this succeeded. For some others, it failed badly - the input protocols no-one likes or has implemented, necessitating Dorota's rewrite. The elephant in the room is extensions like layer-shell and some of the related extensions to build a desktop environment from a set of disparate clients using generic APIs. Personally I think the experience of X11 shows it's only designing for pain, and this is the general position of wayland-protocols at the moment. But on the other hand, those protocols aren't going away, they are in use, and having them developed in a separate siloed community is doing us all a disservice, since neither hand fully knows what the other is doing. Even if we don't agree on the fundamentals of the protocol, we could at least discuss it and try to point out some pitfalls and make some suggestions for improvement. A related issue is that it's hard for both application and compositor authors to figure out what to do. There is no good 'big picture' on how these protocols fit together, nor can people figure out which of the competing proposals they should be using if they want to write an application running on a given compositor, nor can compositor authors figure out what apps want them to support. Depending on who happens to be paying attention to the particular forum the question is asked, they might get very different answers, depending on the point of view of who answers. My first, hopefully uncontroversial, suggestion: introduce a list of compositors / compositor frameworks, as well as clients / client frameworks, and which protocols they use and support. This would help both application and compositor authors figure out where they should invest time and effort. I suggest that we keep this lightweight: have a registry of compositors / compositor frameworks / toolkits / clients, each with a couple of named people who can speak authoritatively for that project. We could then allow each project to declare its support (or otherwise) for any extension: will not ever implement, implementation not planned, no opinion or N/A, implementation planned, implemented but use not recommended (or limited/stubbed), implemented and recommended. This list would be machine-parseable (XML, JSON, YAML, whatever is easiest to fit), with a GitLab CI pipeline used to generate a https://wayland.freedesktop.org/protocols/ website on every push, which gave both a per-extension and a per-project support table. And some more readable docs. I think this would be a really good entry point and clear up a lot of confusion. As a strawman list of projects to begin with (I'm sure there are others): - compositors and compositor frameworks: Chromium (Exosphere), Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots - toolkits: EFL, GTK, Qt - media: GStreamer, Kodi, VLC, XBMC - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan) My second suggestion is to formalise the 'xdg' namespace. xdg extensions have been accepted or rejected by rough consensus between Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough to me, assuming that 'xdg' retains the focus of an integrated (as opposed to build-it-yourself) desktop. The IVI namespace would similarly be delegated to automotive people, and maybe we could delegate the layer_ namespace to those developers as well. My third suggestion is to formalise the 'wp' namespace, as core extensions that everyone can agree on. It doesn't mean everyone needs to implement them, but at least not have active opposition. For example, Mutter hadn't implemented wp_viewporter for the longest time, but also had no opposition to it being implemented - which wouldn't block it being a 'wp' protocol. Or Weston hasn't implemented xdg_foreign and probably won't, but I'm fine with it existing and being a common extension. On the other hand, Weston/Mutter/etc would have very strong opposition to a 'wp_randr' extension, and last I saw wlroots would have very strong opposition to wp_pointer_gestures. So those wouldn't be wp. So where does that leave other extensions? My fourth suggestion is that we look to the OpenGL/EGL/Vulkan registries: if an extension has been vetoed from the wp_ namespace, but still had support and implementations from multiple projects, that we still accept and publish it under a different namespace which makes it clear that some projects think the extension is fundamentally a bad idea, but
Weston/wayland release schedule
Hello, Thanks everyone for the flurry of activity reviewing and landing important patches for the release! In agreement with Daniel's suggestion to freeze and release today, I'm going to start rolling the alpha shortly. Here's the final release schedule: Alpha: today, February 19th Beta: March 5th Rc1: March 12th March 19th - first potential final release date. Thanks, Derek ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Question about linux-explicit-synchronization
On Mon, 18 Feb 2019 at 10:13, Scott Anderson wrote: > On 18/02/19 11:02 pm, Daniel Stone wrote: > > Doing this gets _really_ tricky as you start considering things like > > synchronised subsurfaces (which always seems to be the case), since > > you have to make sure you're not presenting incoherent results. But > > for unrelated surfaces, you can definitely delay presentation. > > Ok, cool. That actually answers a follow-up question I would've had. > I've been looking at implementing this in wlroots, and subsurfaces > certainly were a point I was wondering about. > > The case in particular would be: > - Parent surface is "ready" (signaled fence or no fence) > - Subsurface is synchronized and fence is not signaled > > The intuitive thing would be to delay the parent's content from being > updated until the subsurface is ready, but the protocol itself is a bit > underspecified when it comes to this. Yeah, the protocol should be fixed then in order to be clear. With implicit sync, the compositor commits the configuration anyway (GL or KMS), then atomicity is ensured by the implementation waiting. The intention for explicit sync is the same: the compositor ensures that the configurations are coherent. Subsurfaces are explicitly tethered together by specification, however there's nothing in the spec which tethers presentation of separate surface trees. Those are allowed to be desynchronised, and it was the intent of this spec to allow that for separate window trees. If you've got a good idea of some spec language that would help clear this up for subsurface trees, I'm all ears. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Upcoming release
Hi, On Fri, 25 Jan 2019 at 16:05, Derek Foreman wrote: > On 1/18/19 4:20 PM, Derek Foreman wrote: > > Does anyone have objections to an early February freeze and a March > > release? Anyone with large series near completion? > > > > Also, I'd like to float the idea of removing the fbdev backend for this > > release (or the next). The bulk of the interesting features target the > > drm backend, and it feels like fbdev can sometimes be a bit of a pain to > > update when changes are required elsewhere. Any strong opinions either way? > > Ok, I've heard no complaints, and we really are overdue... Yeah, quite. > There's been some reasonable pushback against dropping fbdev > immediately, so let's leave that in for this release. > > As to the release schedule, maybe: > February 1, Alpha > February 15, Beta > March 1, RC1 > March 8 as a first potential final release date. > > Is this too soon to enter freeze? It's not a lot of warning. So, Weston is in good shape - we now have both xdg-shell stable as well as xdg-shell clients on ivi-shell compositors. I've had a scrub through the MR and don't see anything major we would want to land in the release that we can't do after freeze anyway. Given that, and the complete absence of any objections - how about alpha and freeze today? Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
