Reminder: Seeking nominations for the 2025 X.Org Board of Directors Elections
Hello! The nomination period is currently open for the upcoming election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2025 election are now open and will remain open until 23:59 UTC on 16 April 2025. 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 2024 were Erik Faye-Lund, Mark Filion, Neal Gompa and Simon Ser. They will continue to serve until their term ends in 2026. Current directors whose term expires in 2025 are Lyude Paul, Arkadiusz Hiler and Christopher Michael. Additionally, a fourth board position is open following the resignation of Simona Vetter in Q3 2024. A director is expected to participate in the bi-weekly BBB 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, membership applications or renewals and completed personal statements must be received no later than 23:59 UTC on 16 April 2025. The slate of candidates will be published 23 April 2025 and candidate Q&A will begin then. The deadline for Xorg membership applications and renewals is 28 April 2025. Best, Mark Filion, on behalf of the X.Org BoD
[RFC] protocol: Clarify mediator role of compositor in wl_data_offer description
Hi all, While reviewing the protocol documentation, I noticed that the description of wl_data_offer could more clearly reflect the actual mediation role of the compositor in data transfer. Current Description (problematic) `` A wl_data_offer represents a piece of data offered for transfer by another client (the source client). It is used by the copy-and-paste and drag-and-drop mechanisms. The offer describes the different mime types that the data can be converted to and provides the mechanism for transferring the data directly from the source client. `` This could be misinterpreted as implying direct client-to-client transfer, obscuring the compositor's critical role. Proposed Revision `` A wl_data_offer is created by the compositor to mediate data transfer between clients. The source client interacts via wl_data_source, while the destination client uses this interface. It enables: - MIME type negotiation through the compositor - Secure data transfer orchestration - Both clipboard and drag-and-drop operations `` Key Clarifications Compositor as mediator Explicitly states the compositor creates/manages wl_data_offer Matches actual implementation (Weston/wlroots) Role separation Distinguishes wl_data_source (source) and wl_data_offer (destination) Avoids "direct transfer" implication Protocol accuracy Aligns with the security model where all transfers are compositor-supervised Would appreciate feedback on whether this warrants a protocol patch. A minimal documentation update could prevent client implementation confusion. Best regards, 苏怀安
[RFC] protocol: Ambiguous description of wl_data_device.leave event
Hi all, In the protocol description of wl_data_device.leave event [1], the phrase "session ends" could be misinterpreted to include intra-client surface switches. However, the actual implementation only triggers this event when leaving the entire client. Suggested clarification: - Old: "when the drag-and-drop pointer leaves the surface and the session ends" - New: "when the drag-and-drop pointer leaves the client's surfaces entirely, terminating the cross-client session" [1] https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_data_device