The Compositor Modules are released, the modular C++ library for writing Wayland compositors

[Roman Gilg]

I'm happy to announce the first publicly available release of The
Compositor Modules, the modular C++ library to easily write a Wayland
compositor. The release is available on GitHub. [1]

You can read the full announcement with more details about the library
exclusively on Phoronix. [2]

The goal I once described at XDC 21 [3] has finally been reached by
that. There are still of course things to do, but the main library
structure is now in place. We can concentrate now on more feature
work. Check out the feature table in the main README to see what's
already there and what we plan on doing next.

If you're interested in using the library or contributing to it, let
me know either by email or join our Matrix room. [4]

[1] https://github.com/winft/como
[2] https://www.phoronix.com/review/the-compositor-modules-como
[3] https://youtu.be/lTp7al9FXFs?t=885
[4] https://matrix.to/#/#como:matrix.org

Reminder: 2024 X.Org Board of Directors Elections timeline extended, request for nominations

[Christopher Michael]

This is a reminder that we are still looking for candidates for the 
upcoming X.Org Board of Directors elections, and that membership 
renewals are still open and will be needed to vote on those elections. 
Please read below for more details.



Cheers,

Christopher Michael, on behalf of the X.Org BoD


On 3/1/24 06:25, Christopher Michael wrote:


We are seeking nominations for candidates for election to the X.org 
Foundation Board of Directors. However, as we presently do not have 
enough nominations to start the election - the decision has been made 
to extend the timeline by 2 weeks. Note this is a fairly regular part 
of the elections process.



The new deadline for nominations to the X.org Board of Directors is 
23:59 UTC on 11 March 2024



The Board consists of directors elected from the membership. Each 
year, an election is held to bring the total number of directors to 
eight. The four members receiving the highest vote totals will serve 
as directors for two year terms.


The directors who received two year terms starting in 2023 were 
Arkadiusz Hiler, Christopher Michael, Lyude Paul, and Daniel Vetter. 
They will continue to serve until their term ends in 2024. Current 
directors whose term expires in 2024 are Emma Anholt, Mark Filion, 
Ricardo Garcia, and Alyssa Rosenzweig.



A director is expected to participate in the fortnightly IRC meeting 
to discuss current business and to attend the annual meeting of the 
X.Org Foundation, which will be held at a location determined in 
advance by the Board of Directors.


A member may nominate themselves or any other member they feel is 
qualified. Nominations should be sent to the Election Committee at 
electi...@x.org.


Nominees shall be required to be current members of the X.Org 
Foundation, and submit a personal statement of up to 200 words that 
will be provided to prospective voters. The collected statements, 
along with the statement of contribution to the X.Org Foundation in 
the member's account page on http://members.x.org, will be made 
available to all voters to help them make their voting decisions.


Nominations and completed personal statements must be received no 
later than 23:59 UTC on 11 March 2024.


The slate of candidates will be published 18 March 2024 and candidate 
Q&A will begin then. The deadline for Xorg membership applications and 
renewals has also been extended 2 weeks and is now 25 March 2024.



Cheers,

Christopher Michael, on behalf of the X.Org BoD

Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston

[Pekka Paalanen]

On Mon, 4 Mar 2024 17:59:25 +
Terry Barnaby  wrote:

> On 04/03/2024 15:50, Pekka Paalanen wrote:
> > On Mon, 4 Mar 2024 14:51:52 +
> > Terry Barnaby  wrote:
> >  
> >> On 04/03/2024 14:14, Pekka Paalanen wrote:  
> >>> On Mon, 4 Mar 2024 13:24:56 +
> >>> Terry Barnaby  wrote:
> >>> 
>  On 04/03/2024 09:41, Pekka Paalanen wrote:  
> > On Mon, 4 Mar 2024 08:12:10 +
> > Terry Barnaby  wrote:
> >
> >> While I am trying to investigate my issue in the QtWayland arena via 
> >> the
> >> Qt Jira Bug system, I thought I would try taking Qt out of the equation
> >> to simplify the application a bit more to try and gain some
> >> understanding of what is going on and how this should all work.
> >>
> >> So I have created a pure GStreamer/Wayland/Weston application to test
> >> out how this should work. This is at:
> >> https://portal.beam.ltd.uk/public//test022-wayland-video-example.tar.gz
> >>
> >> This tries to implement a C++ Widget style application using native
> >> Wayland. It is rough and could easily be doing things wrong wrt 
> >> Wayland.
> >> However it does work to a reasonable degree.
> >>
> >> However, I appear to see the same sort of issue I see with my Qt based
> >> system in that when a subsurface of a subsurface is used, the Gstreamer
> >> video is not seen.
> >>
> >> This example normally (UseWidgetTop=0) has a top level xdg_toplevel
> >> desktop surface (Gui), a subsurface to that (Video) and then 
> >> waylandsink
> >> creates a subsurface to that which it sets to de-sync mode.
> >>
> >> When this example is run with UseWidgetTop=0 the video frames from
> >> gstreamer are only shown shown when the top subsurface is manually
> >> committed with gvideo->update() every second, otherwise the video
> >> pipeline is stalled.  
> > This is intentional. From wl_subsurface specification:
> >
> >  Even if a sub-surface is in desynchronized mode, it will 
> > behave as
> >  in synchronized mode, if its parent surface behaves as in
> >  synchronized mode. This rule is applied recursively throughout 
> > the
> >  tree of surfaces. This means, that one can set a sub-surface 
> > into
> >  synchronized mode, and then assume that all its child and 
> > grand-child
> >  sub-surfaces are synchronized, too, without explicitly setting 
> > them.
> >
> > This is derived from the design decision that a wl_surface and its
> > immediate sub-surfaces form a seamlessly integrated unit that works
> > like a single wl_surface without sub-surfaces would. wl_subsurface
> > state is state in the sub-surface's parent, so that the parent controls
> > everything as if there was just a single wl_surface. If the parent sets
> > its sub-surface as desynchronized, it explicitly gives the sub-surface
> > the permission to update on screen regardless of the parent's updates.
> > When the sub-surface is in synchronized mode, the parent surface wants
> > to be updated in sync with the sub-surface in an atomic fashion.
> >
> > When your surface stack looks like:
> >
> > - main surface A, top-level, root surface (implicitly desynchronized)
> >  - sub-surface B, synchronized
> >- sub-surface C, desynchronized
> >
> > Updates to surface C are immediately made part of surface B, because
> > surface C is in desynchronized mode. If B was the root surface, all C
> > updates would simply go through.
> >
> > However, surface B is a part of surface A, and surface B is in
> > synchronized mode. This means that the client wants surface A updates to
> > be explicit and atomic. Nothing must change on screen until A is
> > explicitly committed itself. So any update to surface B requires a
> > commit on surface A to become visible. Surface C does not get to
> > override the atomicity requirement of surface A updates.
> >
> > This has been designed so that software component A can control surface
> > A, and delegate a part of surface A to component B which happens to the
> > using a sub-surface: surface B. If surface B parts are further
> > delegated to another component C, then component A can still be sure
> > that nothing updates on surface A until it says so. Component A sets
> > surface B to synchronized to ensure that.
> >
> > That's the rationale behind the Wayland design.
> >
> >
> > Thanks,
> > pq  
>  Ah, thanks for the info, that may be why this is not working even in Qt
>  then.
> 
>  This seems a dropoff in Wayland to me. If a software module wants to
>  display Video into an area on the screen at its own rate, setting that
>  surface to de-synced mode is no use in the general case with this
>