[ANNOUNCE] Weston 12.0.4
Hi all, Weston 12.0.4, a bug fix release for 12.0.0 has been released. Full changelog below: Arnaud Vrac (2): desktop-shell: clamp view alpha correctly clients/desktop-shell: fix crash on init when panel is disabled Marius Vlad (1): build: bump to version 12.0.4 for the point release Michael Olbrich (1): ivi-shell: clear seat focus if necessary when a surface is destroyed Philipp Zabel (1): libweston-desktop: Work around crash when opening popup menu Robert Mader (2): backend-drm: Don't force non-opaque overlays to primary plane backend-drm: Sort planes by faked zpos Tomohito Esaki (4): ivi-shell: Properly handle seat hotplugging ivi-shell: activate desktop surface hmi-controller: activate and deactivate sruface ivi-shell-user-interface: change timing to create the launcher surface Wujian Sun (1): libweston-desktop: Fix weston crash when lost the shsurf git tag: 12.0.4 https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.4/downloads/weston-12.0.4.tar.xz SHA256: efdb21859b38f8cbc2b4b39ad65cc1ea3ed1adab23ac28bf501a8a9f80a31727 weston-12.0.4.tar.xz SHA512: c988256b73ea72f06d8ec4faaac2f4a2c52b250b573d3c9906cd00dcba017ad2202875ff04d012b194044715fb5e586331238c54daa508b814c7ab22f3d40006 weston-12.0.4.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.4/downloads/weston-12.0.4.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] Weston 13.0.1
Hi all, Weston 13.0.1, a bug fix release for 13.0.0 has been released. Full changelog below: Arnaud Vrac (3): desktop-shell: clamp view alpha correctly desktop-shell: set proper curtain size when no output is created yet clients/desktop-shell: fix crash on init when panel is disabled Derek Foreman (3): gl-renderer: apply output transform before readback in repaint libweston: Clip damage to paint node visible region libweston/backends: Move damage flush into backends Jeffy Chen (2): renderer-gl: Fix wrong stride error when reading pixels desktop-shell: Avoid using maximized size in fullscreen state Marius Vlad (3): backend-pipewire: Move region initialization at the start libweston: Add paint node destruction into weston_layer_entry_remove() build: bump to version 13.0.1 for the point release Michael Olbrich (1): ivi-shell: clear seat focus if necessary when a surface is destroyed Philipp Zabel (1): libweston-desktop: Work around crash when opening popup menu Ray Smith (1): backend-drm: fix confused fallback format handling Robert Mader (2): backend-drm: Don't force non-opaque overlays to primary plane backend-drm: Sort planes by faked zpos Wujian Sun (1): libweston-desktop: Fix weston crash when lost the shsurf git tag: 13.0.1 https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz SHA256: ea1566ab4f5ffce7e9fd4f7a1fca5b30caae4d50023bf459213994094e02b29a weston-13.0.1.tar.xz SHA512: 4a0fd0b1aec823219421d701030bc534576be64b71ede70c7d33f131e9e64c0e0dc209e62f75cecb9368df7604c1d5b2321932eccc818b529d246ec2e3114122 weston-13.0.1.tar.xz PGP: https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz.sig signature.asc Description: PGP signature
Re: [ANNOUNCE] Weston 13.0.1
Hi all, Someone pointed out that the tag was wrong, pointing apparently to main branch. Had to delete the tag and re-create it. Should now point correctly. All links are the same, with the same files. Thanks for heads-up Dylan! On Tue, Apr 23, 2024 at 06:55:45PM +0300, Marius Vlad wrote: > Hi all, > > Weston 13.0.1, a bug fix release for 13.0.0 has been released. > > Full changelog below: > > Arnaud Vrac (3): > desktop-shell: clamp view alpha correctly > desktop-shell: set proper curtain size when no output is created yet > clients/desktop-shell: fix crash on init when panel is disabled > > Derek Foreman (3): > gl-renderer: apply output transform before readback in repaint > libweston: Clip damage to paint node visible region > libweston/backends: Move damage flush into backends > > Jeffy Chen (2): > renderer-gl: Fix wrong stride error when reading pixels > desktop-shell: Avoid using maximized size in fullscreen state > > Marius Vlad (3): > backend-pipewire: Move region initialization at the start > libweston: Add paint node destruction into weston_layer_entry_remove() > build: bump to version 13.0.1 for the point release > > Michael Olbrich (1): > ivi-shell: clear seat focus if necessary when a surface is destroyed > > Philipp Zabel (1): > libweston-desktop: Work around crash when opening popup menu > > Ray Smith (1): > backend-drm: fix confused fallback format handling > > Robert Mader (2): > backend-drm: Don't force non-opaque overlays to primary plane > backend-drm: Sort planes by faked zpos > > Wujian Sun (1): > libweston-desktop: Fix weston crash when lost the shsurf > > git tag: 13.0.1 > > https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz > SHA256: ea1566ab4f5ffce7e9fd4f7a1fca5b30caae4d50023bf459213994094e02b29a > weston-13.0.1.tar.xz > SHA512: > 4a0fd0b1aec823219421d701030bc534576be64b71ede70c7d33f131e9e64c0e0dc209e62f75cecb9368df7604c1d5b2321932eccc818b529d246ec2e3114122 > weston-13.0.1.tar.xz > PGP: > https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz.sig > signature.asc Description: PGP signature
Re: Call for proposals for the next governance meeting
Personally I would say we could give it a go, but I don't believe that this will significantly change how long some protocols take to get merged. The group transaction is taking so long because the subsurface sync and desync modes together with content update queues are hard to get right and the protocol makes everything much worse. The color management protocol took so long because it evolved with our understanding of color and colorimetry which changed significantly over the years. Some protocols are just stuck because stakeholders can't agree and most of the time the problem is just time and priorities. On Wed, Apr 17, 2024 at 5:09 PM Austin Shafer wrote: > > Hi all, > > Not a protocol, but I think it would be good to discuss the possibility > of regular Wayland Governance meetings at a decided frequency. Currently > meetings are scheduled on demand to discuss a particular subject or > protocol, but I believe routine discussions could be very beneficial in > progressing protocol designs. > > One issue we currently have is that many protocol proposals turn into > multi year endeavors. Explicit Sync [1] is a recent example of this > which was merged after two years, and surface group transactions [2] are > still in review after four years. While these proposals are full of > excellent discussions, if the time is measured in years I think that > means there's room for improvement regarding how long it takes us to > make forward progress. It can also be unclear who is interested in a > protocol and for what reasons, or who depends on it to ship features in > a particular release. > > As more distros switch to Wayland by default, I believe having more > frequent/routine meetings would be a good investment to avoid > indefinitely blocking new desktop features. Less formal conversations > can also provide opportunities to see how implementations are > progressing, ask for reviews, and get an idea of when protocols might be > ready to land. All of these could be beneficial for handling growing > pains: more Wayland users means more feature requests. My hope is this > could reduce the social burden of proposing a protocol or tracking its > progress. > > That being said there are many open questions to answer: > - Is there interest in formally making meetings at a certain time > interval, would the community find this useful? > - How to decide on a time? Poll before every meeting? > - How frequent should the regular meetings be? Monthly? Biweekly? > - How far in advance would we decide on agenda/topics? Tentative agenda > sent out a week before with a call for topics? > - Pain-points in the existing protocol approval process: would this help > them? > - Should we track action items from the previous meeting and follow up > on their status? > - Should there be "status updates"/pings for long-lived protocol proposals? > - Possible agenda items for regular meetings. I have some initial ideas > but would appreciate more suggestions if there are any pressing > topics? > > Non-goals which I don't want to accidentally accomplish with this: > - Rush discussions or rush protocols out the door > - Force a schedule onto projects or contributors > > As always I'm open to any suggestions. I'm happy to drive the discussion > on this in the next governance meeting, and also shoulder the > organizational burden of doing these if we go forward with it. > > [1] > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90 > [2] > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26 > > Thanks! > Austin > > On 4/17/24 8:37 AM, Vlad Zahorodnii wrote: > > Hello, > > > > The Wayland Governance Meeting is semi-regular meeting to drive > > discussion on wayland-protocols forward. > > > > We are looking for the proposals for the next meeting as well as people > > who can lead/drive the discussion. If there is a protocol that you would > > like to be on the agenda, please submit your proposals here. > > > > Regards, > > Vlad > > > > >
