Re: Proposal: no more alphas/betas for Wayland releases
On Tue, May 20, 2025 at 08:03:02PM +, Simon Ser wrote: > Hi all, > > With years passing by, development in the main Wayland repository has > slowed down quite a bit, activity has moved over to wayland-protocols > and compositors. However, cutting a new Wayland release is still a > heavyweight process: it takes at least one and a half months with at > least 3 pre-releases. I'm also not sure about the value of all of these > pre-releases: historically they've been used to push the last features > over the fence before the RCs, but it's easy enough to talk and > coordinate over the bits that we want to wait on for the release. > > I would suggest to drop the alphas/betas from the release process, ie. > go straight to RC1. The process would then continue as usual, with > weekly RCs. As a release manager this would help reduce the load. This > is also what I've been doing for Sway and wlroots for a very long time. > > Would this make sense? Are there other reasons why alphas/betas were > valuable? Personally I think only RCs are enough for what kind of changes tend to go into the wayland repo these days. Jonas > > Thanks, > > Simon
Re: Proposal: no more alphas/betas for Wayland releases
On Tue, May 20, 2025 at 4:03 PM Simon Ser wrote: > > Hi all, > > With years passing by, development in the main Wayland repository has > slowed down quite a bit, activity has moved over to wayland-protocols > and compositors. However, cutting a new Wayland release is still a > heavyweight process: it takes at least one and a half months with at > least 3 pre-releases. I'm also not sure about the value of all of these > pre-releases: historically they've been used to push the last features > over the fence before the RCs, but it's easy enough to talk and > coordinate over the bits that we want to wait on for the release. > > I would suggest to drop the alphas/betas from the release process, ie. > go straight to RC1. The process would then continue as usual, with > weekly RCs. As a release manager this would help reduce the load. This > is also what I've been doing for Sway and wlroots for a very long time. > > Would this make sense? Are there other reasons why alphas/betas were > valuable? > Funnily enough, I think wlroots should probably have them since wlroots releases are so highly disruptive for basically every consumer... That said, going straight to RCs for libwayland itself seems reasonable. But, do we even need those? Could we go straight to release since the churn is so low? -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Proposal: no more alphas/betas for Wayland releases
On Wednesday, May 21st, 2025 at 11:43, Neal Gompa wrote: > Funnily enough, I think wlroots should probably have them since > wlroots releases are so highly disruptive for basically every > consumer... wlroots has them since the last release. > That said, going straight to RCs for libwayland itself seems > reasonable. But, do we even need those? Could we go straight to > release since the churn is so low? Last time I asked people still wanted RCs.
Re: Proposal: no more alphas/betas for Wayland releases
On Wed, May 21, 2025 at 05:43:09AM -0400, Neal Gompa wrote: > On Tue, May 20, 2025 at 4:03 PM Simon Ser wrote: > > > > Hi all, > > > > With years passing by, development in the main Wayland repository has > > slowed down quite a bit, activity has moved over to wayland-protocols > > and compositors. However, cutting a new Wayland release is still a > > heavyweight process: it takes at least one and a half months with at > > least 3 pre-releases. I'm also not sure about the value of all of these > > pre-releases: historically they've been used to push the last features > > over the fence before the RCs, but it's easy enough to talk and > > coordinate over the bits that we want to wait on for the release. > > > > I would suggest to drop the alphas/betas from the release process, ie. > > go straight to RC1. The process would then continue as usual, with > > weekly RCs. As a release manager this would help reduce the load. This > > is also what I've been doing for Sway and wlroots for a very long time. > > > > Would this make sense? Are there other reasons why alphas/betas were > > valuable? > > > > Funnily enough, I think wlroots should probably have them since > wlroots releases are so highly disruptive for basically every > consumer... > > That said, going straight to RCs for libwayland itself seems > reasonable. But, do we even need those? Could we go straight to > release since the churn is so low? I think it's better to start with skipping alpha/beta for now, so that there is at least *some* testing before things end up in a release. This is different from wayland-protocols, since they don't end up causing any actual changes on people's system until servers and clients make use of and ship them. Jonas > > > > -- > 真実はいつも一つ！/ Always, there's only one truth!
Re: [PATCH V8 40/43] drm/colorop: Add 3D LUT support to color pipeline
On 2025-05-20 16:13, Harry Wentland wrote: > > > On 2025-05-19 19:43, Simon Ser wrote: >> On Sunday, May 18th, 2025 at 00:32, Xaver Hugl wrote: >> We can always make the property mutable on drivers that support it in >>> the future, much like the zpos property. I think we should keep it immutable for now. >>> >>> Sure, but I don't see any reason for immutability with an enum >>> property - it can just limit the possible values to what it supports, >>> and that can be only one value. Either way, it's not a big issue. >> >> Immutability is a clear indication that a property has a fixed read-only >> value which can't be switched by user-space. That's also the pattern >> used everywhere in the KMS uAPI, so I think it's better to remain >> consistent here. > > I was envisioning this to be a driver-caps thing, but I agree > if we make this mutable it can still serve that function but with > different/future HW possibly support other interpolation schemes. > Would changing this enum property from IMMUTABLE to MUTABLE in the future (for drivers that support multiple types) break any userspace that assumes IMMUTABLE? If not, maybe it's best to leave it IMMUTABLE now and change it only in the future if needed. Harry > Harry
Re: [PATCH V9 00/43] Color Pipeline API w/ VKMS
On 2025-05-17 07:51, Xaver Hugl wrote: > Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro > : >> >> >> >> On 5/15/25 15:39, Daniel Stone wrote: >>> Hi, >>> >>> On Thu, 15 May 2025 at 19:02, Harry Wentland wrote: On 2025-05-15 13:19, Daniel Stone wrote: > Yeah, the Weston patches are marching on. We've still been doing a > little bit of cleanup and prep work in the background to land them, > but we also can't land them until the kernel lands. None of that work > is material to the uAPI though: as said previously, the uAPI looks > completely solid and it's something we can definitely beneficially use > in Weston. (Even if we do need the obvious follow-ons for > post-blending as well ...) We can't merge kernel uAPI without canonical userspace that uses it. To move forward we'll need a userspace to at least publish a branch that shows the use of this new uAPI. Do you have a public branch for the Weston work for this? >>> >>> Yeah, https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1702 >>> has been around for a little while now. There are some driver bugs >>> that Leandro commented on, but they don't seem material to the uAPI as >>> such? >> >> Hello, >> >> Yes, there's nothing related to the API that is blocking us. It seemed >> very flexible and easy to use. The bugs that I've spotted are probably >> internal to AMD driver. >> >> I'd say that the Weston patches are converging nicely, we just need time >> to get them fully reviewed. We had a few preparation MR's to land >> before !1702, and now there's only one left (!1617). > > I also updated the KWin MR > (https://invent.kde.org/plasma/kwin/-/merge_requests/6600), it can now > use all the available properties and I think it's ready. I found two > issues with the kernel patches though: > - while attempting to set COLOR_ENCODING and COLOR_RANGE results in > the atomic commit being rejected, the existing values still get > applied if you use YCbCr-type buffers. I would've expected the color > pipeline to operate on the YUV values in that case - and leave > conversion to RGB up to the compositor adding the relevant matrix to > the pipeline AMD HW always operates on RGB values, so there'll always be an implicit conversion of YCbCr-type buffers to RGB. What we should do is reject YCbCr-type buffers with the color pipeline until we implement support for COLOR_ENCODING and COLOR_RANGE as a new CSC colorop. > - the interpolation mode drm properties for 1D and 3D LUTs are > immutable, I think they shouldn't be - to make it less annoying if in > the future we decide to add modes that userspace can set > Makes sense to me. Harry > Other than that, I agree that it's ready to go. > >> Thanks, >> Leandro >>> >>> Cheers, >>> Daniel >>
Re: [RFC] Wayland Security Modules
"Sloane, Brandon" writes: > I'm not sure how the pop-os/cosmic-comp PR is relevent. It seems to be about > exposing cosmic-comp as a library in general. While potentially useful, > several other compositors have been doing that for a while, and it doesn't > seem inform security decisions. Yeah, I guess it's not explained very much on the PR — the idea is that the library interface will expose hooks that are designed to allow an application that's just a very small wrapper around the full compositor implementation in the library to take over certain things, such as in this case doing a permission check of its choice before telling the compositor whether to proceed with something — something always on my mind is controlling access to the clipboard, for example. signature.asc Description: PGP signature
Re: Proposal: no more alphas/betas for Wayland releases
Hi, Looking at the recent history, I think we could have cut a release at any point in time and there wouldn't have been any issues with the release. So yes, I do think that simplifying and shortening the release process makes a lot of sense! On Tue, May 20, 2025, at 10:03 PM, Simon Ser wrote: > Hi all, > > With years passing by, development in the main Wayland repository has > slowed down quite a bit, activity has moved over to wayland-protocols > and compositors. However, cutting a new Wayland release is still a > heavyweight process: it takes at least one and a half months with at > least 3 pre-releases. I'm also not sure about the value of all of these > pre-releases: historically they've been used to push the last features > over the fence before the RCs, but it's easy enough to talk and > coordinate over the bits that we want to wait on for the release. > > I would suggest to drop the alphas/betas from the release process, ie. > go straight to RC1. The process would then continue as usual, with > weekly RCs. As a release manager this would help reduce the load. This > is also what I've been doing for Sway and wlroots for a very long time. > > Would this make sense? Are there other reasons why alphas/betas were > valuable? > > Thanks, > > Simon >
Re: [RFC] Wayland Security Modules
Thanks Alyssa, I've seen the previous libwsm project before. From what I can tell, that effort was abandoned without ever leaving the early prototype state. I'm not sure how the pop-os/cosmic-comp PR is relevent. It seems to be about exposing cosmic-comp as a library in general. While potentially useful, several other compositors have been doing that for a while, and it doesn't seem inform security decisions. I think the biggest difference with what I am ultimately trying to do and what the previous libwsm repository and linked mailing list discussion encompassed is that the prior efforts envisioned capabilities as being something a client either has or doesn't have (perhaps subject to user confirmation). E.G, for my usecase the question is not "does this client have permission to paste from the clipboard" or "does this client have permission to do a capture the screen", but rather "does this client have permission to view data from this specific wl_data_source" and "does this client have permission to capture this specific wl_surface". Notably, this question really is about "capturing this specific wl_surface", and not "a wl_surface owned by this specific client". I anticipate having trusted clients able to surfaces at different sensitivity levels. My concern with creating a high-level permission API is that it will inevitably embed assumptions about possible security models. Ultimately, I think the first question to answer is if there is any appetite to add some form of security modules to libwayland itself. Without being able to hook directly into some core libwayland functions, I think a higher level API would be pretty much forced. From: Alyssa Ross Sent: Wednesday, May 21, 2025 1:28 PM To: Sloane, Brandon Cc: wayland-devel@lists.freedesktop.org; Pekka Paalanen Subject: RE: [RFC] Wayland Security Modules "Sloane, Brandon" writes: >> -Original Message- >> From: Pekka Paalanen >> Sent: Tuesday, May 20, 2025 4:58 AM >> To: Sloane, Brandon >> Cc: wayland-devel@lists.freedesktop.org >> Subject: Re: [RFC] Wayland Security Modules >> >> On Mon, 19 May 2025 15:48:04 + >> "Sloane, Brandon" wrote: >> >> > Hello, >> > >> > I've spent the past few months prototyping a security modules system >> > for Wayland. Our specific motivation for this is to support SELinux >> > integration to meet some rather unique security requirements. >> > However, what we are proposing here is a rather general purpose >> > security module system that provides high level hooks modules can then >> > implement. Potential usecases for this system are: >> > >> > * Creating SELinux permissions for Wayland actions. >> > * Integrating with non-SELinux Linux Security Modules >> > (AppArmor/SMACK/etc). >> > * Integrating with PolicyKit. >> > * Disabling privileged protocols that a specific compositor >> > implements. >> > * Restricting privileged protocols to trusted clients. >> > * Creating backends for wp_security_context_manager. >> >> Hi, >> >> from this and the readme I understand that the goal is to remove security >> policies from compositors and place them outside of compositors and DE >> projects, where they can be shared by many desktop and other environments. >> Is that right? >> >> What is the reason for this goal? >> >> To unify policy configuration over all environments? >> >> To enforce policy where the compositor does not do so itself? > > I would say the goal is to move security policy out of the compositors to the > system integrators. I tend to consider DE projects to be a form of system > integration, so using them using this to implement their own security > policies would be well within scope (although I would hope they do so in a > way that allows downstream integrators to replace the security policy if > needed). Our specific motivation is that we building systems with some rather > niche security requirements that would not be suitable to implement in a > general purpose DE. We also want to unify our policy configuration with a > single environment, so our network policy, file access policy, device access > policy, and GUI policy can all exist as a single unified security policy. > > The ability of have a common policy configuration work across different > environments/compositors is nice, but was not a primary design goal. As we > went to design this, we quickly found that, even if we were only concerned > with a single compositor, the low-level IPC layer by far the most natural and > simplest place to implement this. You might find this previous related discussion interesting: https://lists.freedesktop.org/archives/wayland-devel/2021-July/041897.html Later in the thread a similar sounding previous attempt is linked: https://github.com/mupuf/libwsm After that conversation I was convinced that this is best implemented through direct integration with a specific compositor. Some work has now been started in that direction: http
[ANNOUNCE] libxkbcommon 1.10.0
Dear all, I am pleased to announce the release of libxkbcommon 1.10.0: https://github.com/xkbcommon/libxkbcommon/tree/xkbcommon-1.10.0 Changelog - ## API ### Breaking changes - *Modifiers masks* handling has been refactored to properly handle virtual modifiers. Modifier masks are now always considered as an *opaque encoding* of the modifiers state: - Modifiers masks should not be interpreted by other means than the provided API. In particular, one should not assume that modifiers masks always denote the modifiers *indexes* of the keymap. - It enables using virtual modifiers with arbitrary mappings. E.g. one can now reliably create virtual modifiers without relying on the legacy X11 mechanism, that requires a careful use of keys’ real and virtual modmaps. - It enables *interoperability* with further implementations of XKB. - Changed *Compose* behavior so that sequences defined later always override ones defined earlier, even if the new sequence is shorter. Contributed by Jules Bertholet ### Deprecated - Server applications using `xkb_state_update_mask()` should migrate to using `xkb_state_update_latched_locked()` instead, for proper handling of the keyboard state. ([#310](https://github.com/xkbcommon/libxkbcommon/issues/310)) - The following modifiers names in `xkbcommon/xkbcommon-names.h` are now deprecated and will be removed in a future version: - `XKB_MOD_NAME_ALT`: use `XKB_VMOD_NAME_ALT` instead. - `XKB_MOD_NAME_LOGO`: use `XKB_VMOD_NAME_SUPER` instead. - `XKB_MOD_NAME_NUM`: use `XKB_VMOD_NAME_NUM` instead. ([#538](https://github.com/xkbcommon/libxkbcommon/issues/538)) ### New - Added `xkb_state_update_latched_locked()` to update the keyboard state to change the latched and locked state of the modifiers and layout. This entry point is intended for *server* applications and should not be used by *client* applications. This can be use for e.g. a GUI layout switcher. ([#310](https://github.com/xkbcommon/libxkbcommon/issues/310)) - Added `xkb_keymap_mod_get_mask()` to query the mapping of a modifier. - Added `VoidAction()` action to match the keysym pair `NoSymbol`/`VoidSymbol`. It enables erasing a previous action and breaks latches. This is a libxkbcommon extension. When serializing it will be converted to `LockControls(controls=none,affect=neither)` for backward compatibility. ([#622](https://github.com/xkbcommon/libxkbcommon/issues/622)) - Improved syntax errors in XKB files to include the expected/got tokens. ([#644](https://github.com/xkbcommon/libxkbcommon/issues/644)) ### Fixes - *Compose*: fixed sequence not fully overriden if the new sequence has no keysym or string. ## Tools ### New - `xkbcli-compile-keymap`: Added option `--modmaps` that prints modifiers mappings. This is similar to the legacy `xmodmap -pm`. ## Build system ### Breaking changes - Removed support for byacc -- use bison instead. ([#644](https://github.com/xkbcommon/libxkbcommon/issues/644)) Git tag: git tag: xkbcommon-1.10.0 git commit: 7888474d0296dcad50c9ba4adfdfdf2be02d35e1 Cheers, Pierre Le Marre (aka Wismill)
RE: [RFC] Wayland Security Modules
"Sloane, Brandon" writes: >> -Original Message- >> From: Pekka Paalanen >> Sent: Tuesday, May 20, 2025 4:58 AM >> To: Sloane, Brandon >> Cc: wayland-devel@lists.freedesktop.org >> Subject: Re: [RFC] Wayland Security Modules >> >> On Mon, 19 May 2025 15:48:04 + >> "Sloane, Brandon" wrote: >> >> > Hello, >> > >> > I've spent the past few months prototyping a security modules system >> > for Wayland. Our specific motivation for this is to support SELinux >> > integration to meet some rather unique security requirements. >> > However, what we are proposing here is a rather general purpose >> > security module system that provides high level hooks modules can then >> > implement. Potential usecases for this system are: >> > >> > * Creating SELinux permissions for Wayland actions. >> > * Integrating with non-SELinux Linux Security Modules >> > (AppArmor/SMACK/etc). >> > * Integrating with PolicyKit. >> > * Disabling privileged protocols that a specific compositor >> > implements. >> > * Restricting privileged protocols to trusted clients. >> > * Creating backends for wp_security_context_manager. >> >> Hi, >> >> from this and the readme I understand that the goal is to remove security >> policies from compositors and place them outside of compositors and DE >> projects, where they can be shared by many desktop and other environments. >> Is that right? >> >> What is the reason for this goal? >> >> To unify policy configuration over all environments? >> >> To enforce policy where the compositor does not do so itself? > > I would say the goal is to move security policy out of the compositors to the > system integrators. I tend to consider DE projects to be a form of system > integration, so using them using this to implement their own security > policies would be well within scope (although I would hope they do so in a > way that allows downstream integrators to replace the security policy if > needed). Our specific motivation is that we building systems with some rather > niche security requirements that would not be suitable to implement in a > general purpose DE. We also want to unify our policy configuration with a > single environment, so our network policy, file access policy, device access > policy, and GUI policy can all exist as a single unified security policy. > > The ability of have a common policy configuration work across different > environments/compositors is nice, but was not a primary design goal. As we > went to design this, we quickly found that, even if we were only concerned > with a single compositor, the low-level IPC layer by far the most natural and > simplest place to implement this. You might find this previous related discussion interesting: https://lists.freedesktop.org/archives/wayland-devel/2021-July/041897.html Later in the thread a similar sounding previous attempt is linked: https://github.com/mupuf/libwsm After that conversation I was convinced that this is best implemented through direct integration with a specific compositor. Some work has now been started in that direction: https://github.com/pop-os/cosmic-comp/pull/1145 signature.asc Description: PGP signature
