[ANNOUNCE] wayland-protocols 1.37
wayland-protocols 1.37 is now available. This release contains three new protocols: * xdg-toplevel-icon Associate an icon with a toplevel window. * ext-image-capture-source * ext-image-copy-capture A set of protocols that together allow capturing the pixel content of outputs and toplevels. Apart from this, it includes the usual protocol documentation improvements and fixes, as well as clarification of existing protocol review practices. Enjoy! Andri Yngvason (2): ext-image-capture-source-v1: new protocol ext-image-copy-capture-v1: new protocol Derek Foreman (1): various: Fix definition of double-buffered state Jonas Ådahl (1): build: Bump version to 1.37 Matthias Klumpp (1): staging: Add xdg-toplevel-icon protocol for dedicated toplevel icons Nicolas Fella (1): tablet-v2: Fix feedback description in mode_switch PolyMeilex (1): Fix some trivial typos Simon Ser (7): ci: don't run pipelines in forks readme: s/Makefile.am/meson.build/ readme: use references for links readme: recommend using "Draft:" prefix for RFC protocols members: trim trailing comma governance: document review requirements xdg-toplevel-icon: add error for destroyed wl_buffer Xaver Hugl (1): staging/tearing-control: clarify what happens after wl_surface destruction YaoBing Xiao (1): pointer-gestures: Add punctuation to clarify gesture cycles git tag: 1.37 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.37/downloads/wayland-protocols-1.37.tar.xz SHA256: a70e9be924f2e8688e6824dceaf6188faacd5ae218dfac8d0a3d0976211ef326 wayland-protocols-1.37.tar.xz SHA512: 57936a23d08957afa9563b51b2b195aa10410fa74176c0503f83b1544e243d4e5b99c3daf5fc14c0a68a78d3f5759e1a5ca9fe4ba0cbf5328168903c7575 wayland-protocols-1.37.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.37/downloads/wayland-protocols-1.37.tar.xz.sig
Re: Libreoffice Writer won't wok with Wayland
Hi, This sounds like a problem with the magnifier feature of GNOME Shell. Please file an issue at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ . Jonas On Tue, Jun 18, 2024 at 12:41:55PM -0700, Jim Greene wrote: > I’m a visually impaired user of Ubuntu 22.04 and Libreoffice Writer. I > use Gnome Magnifier, set to between 6X and 10X magnification. It works > well with Xorg, but not with Wayland. I’ve heard some distros, > including Ubuntu will eventually use only Wayland. That’s a problem for > me, and for other visually impaired users. > > At 6X magnification, the cursor is stuck at the bottom of the screen, > so that the bottom of letters are planted on the bottom of the view. As > magnification is increased, the cursor and the letters sink below the > bottom, until, at 10X, the letters are gone. I contacted TDF, who have > been working at it from their side, but I’ve always thought it’s a > Wayland issue. > > I’m a user, not a developer, so I hope Wayland developers can have a > look at the issue, maybe even in conjunction with TDF’s accessibility > director. > -- > Jim Greene
Re: Call for proposals for the next governance meeting
On Wed, Apr 17, 2024 at 11:09:09AM -0400, 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? Personally I wouldn't mind making them reoccurring at an interval, but I do see it being somewhat difficult to achieve. So far each meeting has had a topic and someone who has been wanting to lead the meeting. How do you imagine this would work; would we have someone assigned to handle this, or a rotating position, or ad-hoc depending on the topic? > - How to decide on a time? Poll before every meeting? I see the point of why we'd want to poll, because different topics might bring different people, with different timezones, but I also see a problem with polling every time; it's a reoccurring administrative task that, and there is a risk that people will get tired of answering the same poll if it's asked of them too often. Still, in advance whether there will be a quorum helps planning one's personal schedule, and a time poll could achieve this to some degree. > - How frequent should the regular meetings be? Monthly? Biweekly? Perhaps monthly, with any extra following the existing ad-hoc model, is a good start. > - 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? This sounds like agenda topics one would add. > - Should there be "status updates"/pings for long-lived protocol proposals? This is somewhat what the last meeting was about, a revival of the group transaction protocol proposal. > - 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. Having meetings ad-hoc has the benefit of not adding a consistently reoccurring burden on peoples schedule, and if the interest for this is not big enough, an alternative could perhaps be to make it easier some how to schedule ad-hoc meetings. Ideas for that could be a formal place to gather agenda topics and interest in participation, and someone responsible for organizing scheduling a meeting when there is enough agenda for a topic. It'll put an organizational burden on one or more person, but I imagine so is the case for meetings at an interval, but will require less commitment up front from the community at large. Jonas > > [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 wr
[ANNOUNCE] wayland-protocols 1.36
wayland-protocols 1.36 is now available. This release contains a fix to the xdg dialog protocol, placing the protocol itself in the `xdg` namespace. Enjoy! Jonas Ådahl (1): build: Bump version to 1.36 Simon Ser (1): xdg-dialog: fix missing namespace in protocol name git tag: 1.36 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.36/downloads/wayland-protocols-1.36.tar.xz SHA256: 71fd4de05e79f9a1ca559fac30c1f8365fa10346422f9fe795f74d77b9ef7e92 wayland-protocols-1.36.tar.xz SHA512: 5448b9aedc953ce6be0f378da900c195c8743cb6001f615823b5fc9cab3e3ee54271132055743278e10decef7f8e9dcdeef31593a2a12062575fb90eb0084be0 wayland-protocols-1.36.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.36/downloads/wayland-protocols-1.36.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] wayland-protocols 1.35
wayland-protocols 1.35 is now available. This release marks the tablet-v2 protocol as stable, and introduces a new protocol, alpha-modifier, meant to allow clients to offload transparency of an otherwise opaque buffer to the compositor. Other than that, this release also saw a bug fix to the cursor shape documentation, fixing a missed enum attribute to xdg-shell. The xdg-shell protocol now also explicitly recommends against drawing decorations outside of the window geometry when tiled. Enjoy! Jonas Ådahl (1): build: Bump version to 1.35 Sebastian Wick (2): cursor-shape-v1: Does not advertises the list of supported cursors xdg-shell: add missing enum attribute to set_constraint_adjustment Simon Ser (2): xdg-shell: recommend against drawing decorations when tiled tablet-v2: mark as stable Xaver Hugl (1): staging: add alpha-modifier protocol git tag: 1.35 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.35/downloads/wayland-protocols-1.35.tar.xz SHA256: 37a2716a28133dc819341c568a29d21e8cb72130e5c126a1fcfc9f42c23d95ab wayland-protocols-1.35.tar.xz SHA512: b4b915e145955f9c844d7ce4564ad13a854a4e7d4355913ef4cae7f09ab3e52ee69dceb6c76c9b7f82f1ab5c01071f0e5b00ce75cc7ab58274201eb4a4639710 wayland-protocols-1.35.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.35/downloads/wayland-protocols-1.35.tar.xz.sig
Re: GNOME Wayland sessions die with "No GPUs with outputs found"
If you need assistance running and configuring GNOME, the right place to
ask questions is https://discourse.gnome.org/.
Jonas
On Fri, Apr 05, 2024 at 12:00:22AM -0700, Shankar Ramamoorthy wrote:
> I'm trying to run Wayland on a headless EC2 instance and sessions die with
> "No GPUs with outputs found".
> I was wondering if perhaps there is an oversight w.r.t. the headless GPU
> case.
>
> I tracked down the message to the following code starting @ line 890 in
> src/backends/native/meta-monitor-manager-native.c in mutter
> if (manager_native->needs_outputs && !can_have_outputs)
> {
> g_set_error (error, G_IO_ERROR, G_IO_ERROR_NOT_FOUND,
>"No GPUs with outputs found");
> return FALSE;
> }
> I built libmutter with the "return FALSE;" commented out and then my
> Wayland sessions work.
> Perhaps the headless GPU case could be handled in the mutter source code.
>
> I'm on Ubuntu 22.04 and am starting Wayland via "gnome-shell --wayland
> --virtual-monitor 2056x1329". I access the EC2 instance remotely via
> NoMachine NX.
> Regards,
> Shankar
[ANNOUNCE] wayland-protocols 1.34
wayland-protocols 1.34 is now available. This release comes with three new staging protocols: * xdg-toplevel-drag This protocol enhances regular drag and drop by allowing attaching a toplevel window to a drag. This can be used to implement e.g. detachable toolbars and browser tab drag behavior that can be seen in other platforms. * xdg-dialog This protocol allows setting dialog specific hints on a toplevel, more specifically marking them as modal. * linux-drm-syncobj This protocol will allow explicit synchronization of buffers using DRM synchronization objects. While being a protocol that is unlikely to be widely used directly by applications and toolkits themselves, it is an important building block for improving Vulkan and OpenGL drivers. Other than this, the tablet and foreign toplevel list protocols also received clarifications and fixes. Enjoy! Carlos Garnacho (1): staging/dialog: Add "dialog" protocol David Redondo (1): Add xdg-toplevel-drag protocol Jonas Ådahl (1): build: Bump version to 1.34 Poly (1): Fix typo in ext-foreign-toplevel-list-v1 Simon Ser (3): tablet-v2: clarify that name/id events are optional linux-drm-syncobj-v1: new protocol linux-explicit-synchronization-v1: add linux-drm-syncobj note git tag: 1.34 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.34/downloads/wayland-protocols-1.34.tar.xz SHA256: c59b27cacd85f60baf4ee5f80df5c0d15760ead6a2432b00ab7e2e0574dcafeb wayland-protocols-1.34.tar.xz SHA512: d180eaaf87281dc7adade19070ee8308a5cb3dc2f60cff077960436ad647d3d207eb63fa0b079b7b315109654ad6e6b5e2588bfe859900e67edf8c67b1c3ad20 wayland-protocols-1.34.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.34/downloads/wayland-protocols-1.34.tar.xz.sig signature.asc Description: PGP signature
Re: wl_subsurface vs xdg_popup?
On Thu, Mar 07, 2024 at 04:31:47PM -0500, Shawn W wrote: > I've been looking at the protocol docs on http://wayland.app and something > that's stood out to me is wl_subsurface and xdg_popup. If I want a pop up > menu, which one should I go for? I would guess xdg_popup, but it seems like > some compositors may not support repositioning if they don't support version > 3 of the interface, and positioning a popup seems a little complicated. Then > I look at wl_subsurface, and unless I'm misunderstanding it, it seems like it > could also be used for generating popups, and is required for compositors to > support, but it's not clear to me whether the compositor will actually show a > wl_subsurface, since it wouldn't show a regular wl_surface. Would someone be > able to clarify the difference between these? Subsurfaces should in general be used for constructing a part of your "window", and not for auxiliary windows, like popup menus and tooltips. The reason for this is that unlike subsurfaces, popups have necessary grab semantics that is usually needed (click outside to to dismiss, etc), as well as logic to allow it to be positioned within e.g the work area, using xdg_positioner rules. I suggest allowing repositioning your popups only when the compositor support it, and in other, unmap it and map a new one at a new position, if you need to. Jonas
Re: Extension protocols to support keyboard and mouse sharing?
On Thu, Jul 20, 2023 at 01:47:47PM -0500, Matt Hoosier wrote: > Hi, > > For a while now, I’ve been hoping to see some commercial solutions like > https://symless.com/synergy that implement keyboard and mouse sharing > finally add support for running on DEs that use Wayland. > > It seems to be forever on their feature roadmaps but never really getting > closer. > > I assume the problem is lack of a good way to snoop on the input events and > (maybe; not sure how these commercial solutions implement it) rewrite or > suppress certain input events when they’re talking to a typical DE > compositor like Mutter. > > I had a quick look through the current set of things in wayland-protocols, > and nothing jumped out at me as work in that direction. > > Does anybody know of something underway in the upstream compositors that > might not have filtered down to wayland-protocols yet, which would be > useful for securely implementing mouse/keyboard sharing across separate > machines? Maybe I could point these vendors to it. There is an ongoing, effort to achieve this with xdg-desktop-portal APIs, where the intention is to allow a sandboxed input-leap (or in theory synergy) to be able to act as both a server and client in a Wayland session, while still actively requiring user consent. The pieces that I know of that currently have implementations that ties it all together are input-leap, xdg-desktop-portal, the GNOME portal backend (xdg-desktop-portal-gnome & mutter). The portals in question are input capture[1], for capturing the input from a display server (to the input leap *server*), and remote desktop[2], for remote controlling / injecting input events to a display server (from the input leap *client*). The portal APIs rely on libei[3] for input event transmission - the portals are there to negotiate consent and to set up sessions. It should be possible to use input-leap with mouse/keyboard sharing with all the building blocks manually compiled, but nothing has shipped in distributions yet. Jonas [1] https://github.com/flatpak/xdg-desktop-portal/pull/714 [2] https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.RemoteDesktop [3] https://gitlab.freedesktop.org/libinput/libei
[ANNOUNCE] wayland-protocols 1.32
wayland-protocols 1.32 is now available. This release includes 3 new staging protocols: * ext-foreign-toplevel-list - get information about toplevels, * security-context-v1 - allow race free identification of sandboxed clients, * cursor-shape-v1 - set cursor sprite using a shape enum instead of surface. The xdg-shell protocol also now has a 'suspended' toplevel state, usually sent when a toplevel is "out of sight" to the user, meant to communicate to a toplevel can for example take power saving measures. This release also include the usual set of straightening of question marks and clarifications of ambiguities. Enjoy! Daniel Stone (1): xdg-shell: Add suspended toplevel state David Redondo (1): xdg-activation: Clarify that the token stays valid if the object is destroyed Faith Ekstrand (1): Add a .mailmap file Isaac Freund (3): ext-session-lock-v1: use RFC 2119 key words ext-session-lock-v1: clarify to fix race ext-session-lock-v1: relicense to MIT Jonas Ådahl (4): xdg-output: Remove and tweak contradicting examples xdg-shell: Clarify that geometry doesn't automatically change xdg-shell: Clarify window geometry bounds build: Bump version to 1.32 Kirill Chibisov (1): stable/xdg-shell: clarify initial wl_surface acknowledgement Mikhail Gusarov (1): xdg-shell: Clarify relationship between [un]set_maximized and configure Pekka Paalanen (1): CI: bump ci-templates Philip Withnall (1): Fix typo in xdg-activation-v1 Simon Ser (9): Add merge request template for new protocols xdg-output-unstable-v1: deprecate name and description xdg-output: clarify goal ci: use detached CI pipelines ci: skip ci-fairy checks on main branch tablet-v2: fix typo in set_cursor serial description cursor-shape-v1: new protocol build: add Wayland subproject security-context-v1: new protocol Vlad Zahorodnii (1): linux-dmabuf: Fix a couple of typos Xaver Hugl (3): staging/drm-lease: clarify connector naming unstable/xdg-shell v6: clarify when which errors are used stable/xdg-shell: clarify when which protocol errors are used i509VCB (1): Add ext-foreign-toplevel-list protocol git tag: 1.32 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.32/downloads/wayland-protocols-1.32.tar.xz SHA256: 7459799d340c8296b695ef857c07ddef24c5a09b09ab6a74f7b92640d2b1ba11 wayland-protocols-1.32.tar.xz SHA512: 90bbd52daf342b98823ddeed04e349ae242d2eaf925ab8d603cceb36c980c83b5681bb890961e0d49584cb5c2e60a33abf8821770c6ab87956383630bd5b7966 wayland-protocols-1.32.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.32/downloads/wayland-protocols-1.32.tar.xz.sig signature.asc Description: PGP signature
Re: [RFC] Plane color pipeline KMS uAPI
On Thu, May 11, 2023 at 04:56:47PM +, Joshua Ashton wrote: > When we are talking about being 'prescriptive' in the API, are we > outright saying we don't want to support arbitrary 3D LUTs, or are we > just offering certain algorithms to be 'executed' for a plane/crtc/etc > in the atomic API? I am confused... The 'prescriptive' idea that the RFC of this thread proposes *is* a way to support arbitrary 3D LUTs (and other mathematical operations), arbitrarily, in a somewhat vendored way, only that it will not be vendor prefixed hard coded properties with specific positions in the pipeline, but instead more or less an introspectable pipeline, describing what kind of LUT's, Matrix multiplication (and in what order) etc a hardware can do. The theoretical userspace library would be the one turning descriptive "please turn this into that" requests into the "prescriptive" color pipeline operations. It would target general purpose compositors, but it wouldn't be mandatory. Doing vendor specific implemantions in gamescope would be possible; it wouldn't look like the verion that exist somewhere now that uses a bunch of AMD_* properties, it'd look more like the example Simon had in the initial RFC. Jonas > > There is so much stuff to do with color, that I don't think a > prescriptive API in the kernel could ever keep up with the things that > we want to be pushing from Gamescope/SteamOS. For example, we have so > many things going on, night mode, SDR gamut widening, HDR/SDR gain, > the ability to apply 'looks' for eg. invert luma or for retro looks, > enhanced contrast, tonemapping, inverse tonemapping... We also are > going to be doing a bunch of stuff with EETFs for handling out of > range HDR content for scanout. > > Some of what we do is kinda standard, regular "there is a paper on > this" algorithms, and others are not. > While yes, it might be very possible to do simple things, once you > start wanting to do something 'different', that's kinda lock-in. > > Whether this co-exists with arbitrary LUTs (that we definitely want > for SteamOS) or not: > I think putting a bunch of math-y stuff like this into the kernel is > probably the complete wrong approach. Everything would need to be > fixed point and it would be a huge pain in the butt to deal with on > that side. > > Maybe this is a "hot take", but IMO, DRM atomic is already waaay too > much being done in the kernel space. I think making it go even further > and having it be a prescriptive color API is a complete step in the > wrong direction. > > There is also the problem of... if there is a bug in the math here or > we want to add a new feature, if it's kernel side, you are locked in > to having that bug until the next release on your distro and probably > years if it's a new feature! > Updating kernels is much harder for 'enterprise' distros if it is not > mission critical. Having all of this in userspace is completely fine > however... > > If you want to make some userspace prescriptive -> descriptive color > library I am all for that for general case compositors, but I don't > think I would use something like that in Gamescope. > That's not to be rude, we are just picky and want freedom to do what > we want and iterate on it easily. > > I guess this all comes back to my initial point... having some > userspace to handle stuff that is either kinda or entirely vendor > specific is the right way of solving this problem :-P > > - Joshie 🐸✨ > > On Thu, 11 May 2023 at 09:51, Karol Herbst wrote: > > > > On Wed, May 10, 2023 at 9:59 AM Jonas Ådahl wrote: > > > > > > On Tue, May 09, 2023 at 08:22:30PM +, Simon Ser wrote: > > > > On Tuesday, May 9th, 2023 at 21:53, Dave Airlie > > > > wrote: > > > > > > > > > There are also other vendor side effects to having this in userspace. > > > > > > > > > > Will the library have a loader? > > > > > Will it allow proprietary plugins? > > > > > Will it allow proprietary reimplementations? > > > > > What will happen when a vendor wants distros to ship their > > > > > proprietary fork of said library? > > > > > > > > > > How would NVIDIA integrate this with their proprietary stack? > > > > > > > > Since all color operations exposed by KMS are standard, the library > > > > would just be a simple one: no loader, no plugin, no proprietary pieces, > > > > etc. > > > > > > > > > > There might be pipelines/color-ops on
Re: [RFC] Plane color pipeline KMS uAPI
On Tue, May 09, 2023 at 08:22:30PM +, Simon Ser wrote: > On Tuesday, May 9th, 2023 at 21:53, Dave Airlie wrote: > > > There are also other vendor side effects to having this in userspace. > > > > Will the library have a loader? > > Will it allow proprietary plugins? > > Will it allow proprietary reimplementations? > > What will happen when a vendor wants distros to ship their > > proprietary fork of said library? > > > > How would NVIDIA integrate this with their proprietary stack? > > Since all color operations exposed by KMS are standard, the library > would just be a simple one: no loader, no plugin, no proprietary pieces, > etc. > There might be pipelines/color-ops only exposed by proprietary out of tree drivers; the operation types and semantics should ideally be defined upstream, but the code paths would in practice be vendor specific, potentially without any upstream driver using them. It should be clear whether an implementation that makes such a pipeline work is in scope for the upstream library. The same applies to the kernel; it must be clear whether pipeline elements that potentially will only be exposed by out of tree drivers will be acceptable upstream, at least as documented operations. Jonas
Re: [RFC] Plane color pipeline KMS uAPI
n't set policy and there are > cases where it can't act as an abstraction layer (like where you need > a compiler), but I'm not sold that this case is one of those yet. I'm > open to being educated here on why it would be. It would still be an abstraction of the hardware, just that the level of abstraction is a bit "lower" than your intuition currently tells you we should have. IMO it's not too different from the kernel providing low level input events describing what what the hardware can do and does, with a rather massive user space library (libinput) turning all of that low level nonsense to actual useful abstractions. In this case it's the other way around, the kernel provides vendor independent knobs that describe what the output hardware can do, and exactly how it does it, and a userspace library turns that into a different and perhaps more useful abstraction. I realize input and output is dramatically different, just making a point about the level of abstraction that is ideal is not necessary "the more the better". > > > > > The second answer is that we want to provide a user space library > > which takes a description of a color pipeline and tries to map that to > > the available KMS color pipelines. If there is a novel color > > operation, adding support in this library would then make it possible > > to offload compatible color pipelines on this new hardware for all > > consumers of the library. Obviously there is no guarantee that > > whatever color pipeline compositors come up with can actually be > > realized on specific hardware but that's just an inherent hardware > > issue. > > > > Why does this library need to be in userspace though? If there's a > library making device dependent decisions, why can't we just make > those device dependent decisions in the kernel? Compositors will want to switch between using the KMS color pipeline and using shaders without visible differences at any point in time, or predictable visible differences. Lets say for example you are playing a video, and everything bypasses the GPU, and we're saving important power and all that. Suddenly the user moves the mouse or touches the screen and we'll suddenly have overlays that make it necessary to stop bypassing the GPU and start compositing. These transitions should not result in any visible difference, and that is hard/impossible to do perfectly if the level of abstraction is too high, as implementation details of the pipeline would be hidden. The decisions the kernel had to make to turn the descriptive declaration into actual hardware configuration wouldn't be predictable or known. Userspace needs to know how the kernel implements a pipeline, so that it can decide if it's "good enough" or perhaps even adapt its compositing to match it so that it can implement non-glitchy offloading. The compositor should make the decision if pixel perfect transitions is mandatory or not, it shouldn't be a policy implemented inside the kernel. It is also within scope of a library that provides the descriptive API to also know how to handle the fallback, e.g. by providing shaders that compositors can use when compositing. The kernel is the wrong place to generate shaders. > > This feels like we are trying to go down the Android HWC road, but we > aren't in that business. > > My thoughts would be userspace has to have some way to describe what > it wants anyways, otherwise it does sound like I need to update > mutter, kwin, surfaceflinger, chromeos, gamescope, every time a new HW > device comes out that operates slightly different to previously > generations. This isn't the kernel doing hw abstraction at all, it's > the kernel just opting out of designing interfaces and it isn't > something I'm sold on. It is true that for a new generation of hardware that changes the color pipeline in a way that makes existing userspace no longer able to off-load compositing, needs an updated userspace, but the grand long term idea is that one wouldn't update all those compositors, but only the shared library that provides the descriptive API they all (ideally) make use of. The compositors still handle interacting with KMS themselves, but would share this helper library that can help configuring a subset of the knobs KMS provide to their individual needs. So indeed the kernel isn't doing all the abstraction, it'd be the kernel together with a userspace library. Jonas > > Dave. >
Re: Wayland protocol clarification questions
On Tue, May 02, 2023 at 11:50:55AM +0300, Pekka Paalanen wrote: > On Sun, 30 Apr 2023 10:29:31 +0200 > Tarek Sander wrote: > > > Hello, > > > > I want to write a Wayland compositor and while reading the protocol > > specification, I noticed some things that aren't clear to me: > > Hi! > > > - How does the input and opaque region of a surface behave on a resize? > > Do the additional pixels get automatically added for the input region? > > Resize works by the client sending requests to change the wl_surface > size. If it also wants to change input or opaque regions, it must do so > explicitly. Automatic changes to these regions do not exist, both > requests have the wording: > > Otherwise, the pending and current regions are never changed... > > > > > - Is it valid for the wp_presentation_feedback::kind bitfield to contain > > no flag at all? > > Yes. > > > > > - What exactly is the anchor rectangle of an xdg_positioner? > > The compositor decides the positioning of popups in order to keep them > from going e.g. off-screen, and the positioner gives the rules how such > surface can be positioned without breaking the UI look. Personally I've > never looked at the details, so maybe someone else will answer this. The anchor rectangle for a positionar and a popup is the rectangle on the parent surface the popup will positioned against, given all the rules set up using the xdg_positioner interface. It could for example be the rectangle corresponding to the hamburger menu button where the popup opening above or below (in y-coordinates). The gtk4 docs for GdkPopupLayout has some illustrations that might help: https://docs.gtk.org/gdk4/struct.PopupLayout.html Jonas > > > Thanks, > pq
Re: Thumb detection at upper side of the touchpad (patch)
On Fri, Mar 03, 2023 at 10:37:45AM +0100, Roemer Claasen wrote:
> Apologies, should have mentioned this concerns *libinput.* Hope this is the
> right way to do things here.
The right thing would be to open a merge request with your suggested
change on the libinput project. You can find it here:
https://gitlab.freedesktop.org/libinput/libinput.
Jonas
>
> On Fri, Mar 3, 2023 at 10:29 AM Roemer Claasen
> wrote:
>
> > Hi all,
> >
> > I would like your opinion about the following: thumb detection on the
> > upper side of the touchpad.
> >
> > Here's the story. I recently bought a new laptop (T14s AMD gen3) with
> > pretty shallow keys. I use the touchpad buttons quite often, and with the
> > shallower trackpad buttons, my thumb is detected as a pointer movement
> > every now and then.
> >
> > My proposed solution: copy the thumb detection areas to the top as well.
> >
> > The attached patch does this (at least, I tried to do this in a clean
> > way). Feedback is more than welcome, I would love to clean this up and
> > submit it for merging.
> >
> > Thanks for your time,
> >
> > Roemer
> >
> >
> >
> >
> >
> >
> >
> > -
> >
> > diff --git a/src/evdev-mt-touchpad-thumb.c b/src/evdev-mt-touchpad-thumb.c
> > index ceb123ef..d3d3aae3 100644
> > --- a/src/evdev-mt-touchpad-thumb.c
> > +++ b/src/evdev-mt-touchpad-thumb.c
> > @@ -85,11 +85,20 @@ static bool
> > tp_thumb_in_exclusion_area(const struct tp_dispatch *tp,
> > const struct tp_touch *t)
> > {
> > - return (t->point.y > tp->thumb.lower_thumb_line &&
> > + return ((t->point.y > tp->thumb.lower_thumb_line ||
> > +t->point.y < tp->thumb.upper_top_thumb_line) &&
> > tp->scroll.method != LIBINPUT_CONFIG_SCROLL_EDGE);
> >
> > }
> >
> > +static bool
> > +tp_thumb_in_main_area(const struct tp_dispatch *tp,
> > + const struct tp_touch *t)
> > +{
> > +return (t->point.y < tp->thumb.upper_thumb_line &&
> > +t->point.y > tp->thumb.lower_top_thumb_line);
> > +}
> > +
> > static bool
> > tp_thumb_detect_pressure_size(const struct tp_dispatch *tp,
> >const struct tp_touch *t)
> > @@ -114,9 +123,9 @@ tp_thumb_detect_pressure_size(const struct tp_dispatch
> > *tp,
> > static bool
> > tp_thumb_needs_jail(const struct tp_dispatch *tp, const struct tp_touch
> > *t)
> > {
> > - if (t->point.y < tp->thumb.upper_thumb_line ||
> > -tp->scroll.method == LIBINPUT_CONFIG_SCROLL_EDGE)
> > - return false;
> > + if (tp_thumb_in_main_area(tp, t) ||
> > +tp->scroll.method == LIBINPUT_CONFIG_SCROLL_EDGE)
> > +return false;
> >
> > if (!tp_thumb_in_exclusion_area(tp, t) &&
> > (tp->thumb.use_size || tp->thumb.use_pressure) &&
> > @@ -360,7 +369,8 @@ tp_thumb_update_multifinger(struct tp_dispatch *tp)
> >
> > if (newest &&
> > (newest->initial_time - oldest->initial_time) < THUMB_TIMEOUT &&
> > -first->point.y < tp->thumb.lower_thumb_line) {
> > +(first->point.y < tp->thumb.lower_thumb_line &&
> > +first->point.y > tp->thumb.upper_top_thumb_line)) {
> > tp_thumb_lift(tp);
> > return;
> > }
> > @@ -417,7 +427,16 @@ tp_init_thumb(struct tp_dispatch *tp)
> > edges = evdev_device_mm_to_units(device, &mm);
> > tp->thumb.lower_thumb_line = edges.y;
> >
> > - quirks = evdev_libinput_context(device)->quirks;
> > +/* ThinkPad trackpad button fix */
> > +mm.y = h * 0.15;
> > +edges = evdev_device_mm_to_units(device, &mm);
> > +tp->thumb.lower_top_thumb_line = edges.y;
> > +
> > +mm.y = h * 0.08;
> > +edges = evdev_device_mm_to_units(device, &mm);
> > +tp->thumb.upper_top_thumb_line = edges.y;
> > +
> > +quirks = evdev_libinput_context(device)->quirks;
> > q = quirks_fetch_for_device(quirks, device->udev_device);
> >
> > if (libevdev_has_event_code(device->evdev, EV_ABS, ABS_MT_PRESSURE)) {
> > diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
> > index c99b190f..c46a3edc 100644
> > --- a/src/evdev-mt-touchpad.h
> > +++ b/src/evdev-mt-touchpad.h
> > @@ -489,6 +489,10 @@ struct tp_dispatch {
> > int upper_thumb_line;
> > int lower_thumb_line;
> >
> > +/* ThinkPad trackpad button fix */
> > +int upper_top_thumb_line;
> > +int lower_top_thumb_line;
> > +
> > bool use_pressure;
> > int pressure_threshold;
> >
[ANNOUNCE] wayland-protocols 1.31
wayland-protocols 1.31 is now available. This release introduces a new staging protocol: fractional scaling. Without going into details, this protocol allows compositor to communicate a scale with more precision than an integer. Clients can then use this together with the wp_viewporter protocol to allocate more appropriately sized buffers. The other protocol related change in this release involves adding a new error enum value to xdg-shell. Since the last release, a new member, Smithay/cosmic-comp, was added, represented by Victoria Brekenfeld. Some clarifications to the governence about about protocol ACKs requirements was also done. Enjoy! Jonas Ådahl (2): Add Victoria as Smithay/cosmic-comp member build: Bump version to 1.31 Kenny Levinsen (1): wp-fractional-scale-v1: new protocol Kirill Primak (1): xdg-shell: add defunct_role_object error Simon Ser (1): governance: improve consistency of ACK requirements git tag: 1.31 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.31/downloads/wayland-protocols-1.31.tar.xz SHA256: a07fa722ed87676ec020d867714bc9a2f24c464da73912f39706eeef5219e238 wayland-protocols-1.31.tar.xz SHA512: 402ce1915300e29afe554d77965ee0a28a5f22fdb5b901c4c640e59b9f3a9c11094e1edae87eea1e76eea557f6faf0c34a0c28ee7f6babb4dc3719329c4e25bf wayland-protocols-1.31.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.31/downloads/wayland-protocols-1.31.tar.xz.sig
[ANNOUNCE] wayland-protocols 1.30
wayland-protocols 1.30 is now available. This release introduces a new staging protocol extension aiming for letting clients communicate to compositors that they allow their content to "tear" (screen showing part old, part new content). See the protocol extension specification for details. Jonas Ådahl (1): build: Bump version to 1.30 Xaver Hugl (1): staging: add tearing control protocol git tag: 1.30 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.30/downloads/wayland-protocols-1.30.tar.xz SHA256: 3c1498fb65fd2b80b0376d7e87cf215e6ae957b2ccdba5da45a448718831bc60 wayland-protocols-1.30.tar.xz SHA512: e1e5648387e821c190058b390d7120c06c2767b644caf2644f05a280e0fe300b677545fbb9537839d8bc569a0cc7fb51190963421281e2557d1680767899b743 wayland-protocols-1.30.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.30/downloads/wayland-protocols-1.30.tar.xz.sig
[ANNOUNCE] wayland-protocols 1.29
wayland-protocols 1.29 is now available. This release contains a bug fix to the 'content-type' protocol extension, where an incorrect enum name was previously used. See [1] for more information how it eventually can be avoided in the future. Apart from this, the linux-dmabuf extension saw documentation fixes. Enjoy! [1] https://gitlab.freedesktop.org/wayland/wayland/-/issues/336 Jonas Ådahl (1): build: Bump version to 1.29 Manuel Stoeckl (1): linux-dmabuf: fix references to tranche_formats i509VCB (1): content-type: fix enum name in wp_content_type_v1.set_content_type git tag: 1.29 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.29/downloads/wayland-protocols-1.29.tar.xz SHA256: e25e9ab75ac736704ddefe92e8f9ac8730beab6f564db62f7ad695bba4ff9ed8 wayland-protocols-1.29.tar.xz SHA512: 6482bdc6a6cd759ffd7dd1d28ba40a2df8f9174c6055ea25582f984a1545411576fab16827e1f80e4b61a2d2235bbfb20ac382a5ba216fa9b4231c605217873d wayland-protocols-1.29.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.29/downloads/wayland-protocols-1.29.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] wayland-protocols 1.28
wayland-protocols 1.28 is now available. This release includes one new staging protocol: * Xwayland shell This protocol is intended to exclusively be used by Xwayland to allow a race condition free method for associating an X11 window with a wl_surface in a compositor, and is intended to replace the old WL_SURFACE_ID atom based method. Apart from this, xdg-shell saw some new error codes for already existing error conditions. Demi Marie Obenour (4): xdg-shell: Replace an HTTP link with HTTPS xdg-shell: window menus are optional xdg-shell: Add specific errors Add xdg-shell.unresponsive error Jonas Ådahl (1): build: Bump version to 1.28 Joshua Ashton (1): xwayland_shell_v1: New protocol git tag: 1.28 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.28/downloads/wayland-protocols-1.28.tar.xz SHA256: c7659fb6bf14905e68ef605f898de60d1c066bf66dbea92798573dddec1535b6 wayland-protocols-1.28.tar.xz SHA512: 092454c6a7e5cc47729de49e9061fb91dfdc5610859e17c495642806ca14dcfb3850a5d3a7459ddb70b2adb08d2590d4b0f92c3a97600e48598682d59adb102f wayland-protocols-1.28.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.28/downloads/wayland-protocols-1.28.tar.xz.sig signature.asc Description: PGP signature
[ANNOUNCE] wayland-protocols 1.27
wayland-protocols 1.27 is now available. This release includes two new staging protocols: * Content type hint This protocol enables clients to provide hints to the compositor about what kind of content it provides, allowing compositors to optionally adapt its behavior accordingly. * Idle notify This extension allows compositors to notify clients about when the user is idle. Apart from these two new extensions, this release also brings the usual clarifications, cleanups and fixes. Enjoy! Daniel Stone (1): xdg-shell: ack_configure must be strictly monotonic Emmanuel Gil Peyrot (1): staging/content-type: Content type hint support Isaac Freund (1): ext-session-lock: add note on client termination Jonas Ådahl (1): build: Bump version to 1.27 Simon Ser (3): xdg-shell: forbid loops in set_parent ext-idle-notify: new protocol build: alphabetically sort list of staging protocols git tag: 1.27 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.27/downloads/wayland-protocols-1.27.tar.xz SHA256: 9046f10a425d4e2a00965a03acfb6b3fb575a56503ac72c2b86821c69653375c wayland-protocols-1.27.tar.xz SHA512: c0a49bc46c663c9f602998dfe2e184c09756790fbcc7acbc2bf9d9cf8f7d6dcdd00259b768222a30e5d134e6f97f7f4faf252947b544e8b32f53278b70da0390 wayland-protocols-1.27.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.27/downloads/wayland-protocols-1.27.tar.xz.sig signature.asc Description: PGP signature
Re: Absolute mouse position
On Mon, Sep 19, 2022 at 11:43:47AM +, Jesse Van Gavere wrote: > > > -Original Message- > From: Simon Ser > Sent: Monday, 19 September 2022 13:31 > To: Jesse Van Gavere > Cc: wayland-devel@lists.freedesktop.org > Subject: Re: Absolute mouse position > > On Monday, September 19th, 2022 at 13:19, Jesse Van Gavere > wrote: > > > Is it possible to somehow get the absolute mouse position relative to > > a screen from Wayland as was possible in X11? It is something an > > application of ours relies on to work properly and we’ve been trying > > to see if we can make this work in both X11 and Wayland. > > No, this isn't possible, by design. > > Can you explain your use-case? Then maybe we can suggest a way to make it > work on Wayland. > > Simon > > Hello Simon, > > Thank you for responding, and certainly. > We have in essence a KVM device that can control some local connected > servers/computers, it has a sort of composition of the connected computers so > you can control each server simultaneously and we achieve this by tracking > the mouse position to know when to go to another server (basically a mouse > event that goes over a servers border within the composition to another > server), we have an absolute/relative mouse mode on this, in the absolute > mouse mode knowing the position at the server side is not important because > our KVM always sends Absolute/TS events so it's always aware and in control > of its position, however in the relative mode we do not, there might be mouse > acceleration, mouse warping (a primary use case for why we would use a > relative mode on our KVM) and all kinds of things going on at the server side > we have no control over. > > To compensate for this we made a small tool that currently interrogates the X > server for its mouse position, it communicates this back to our KVM and that > way our KVM can keep an up to date internal position of the mouse. > > But we keep running into issues because everything is moving to Wayland and > our application is only able to receive mouse positions if the mouse is on an > application using the X server and this creates undesirable behavior, so > we're looking to fix this by having a way to receive the mouse no matter if > the mouse is on an application using X or Wayland. > > Do you have an idea on how this would be possible? We are allowed to > install/use almost anything to get this working so any ideas, no matter how > exotic, is welcome. What it sounds like is something rather similar to Input Leap (https://github.com/input-leap/input-leap) which roughly aims to provide a way to use the same mouse/keyboard device on multiple computers, also by finding out when a pointer touches the edge of a screen that logically bridges to some other machine. There are a couple approaches to get this kind of functionality to a Wayland session: One is the "input capture" XDG Desktop portal (https://github.com/flatpak/xdg-desktop-portal/pull/714) that aims to provide a sandbox friendly way to let applications capture input without allowing arbitrary applications to eaves drop on input events all the time. It uses libei (https://gitlab.freedesktop.org/libinput/libei) as a method of input event transfer. As for the receiving side, the aim is to tie the knot together with using libei for transmitting events in the other direction via the remote desktop XDG desktop portal (https://github.com/flatpak/xdg-desktop-portal/pull/762). The other approach focuses is as far as I know for the receiving end of the problem, and uses various wlroots Wayland protocols for injecting input events (https://github.com/r-c-f/waynergy). I'm sure others are more aware of the details, and whether it aims to solve the input capture side of this as well. Jonas > > Thanks. > > Regards, > Jesse
Re: I'm adding features to VKMS! What would you like to see?
On Fri, Jul 29, 2022 at 12:07:20PM -0400, Alex Deucher wrote: > On Fri, Jul 29, 2022 at 3:30 AM Jim Shargo wrote: > > > > Hi Wayland folks! > > > > TL;DR: I'm working on extending VKMS and wanted feedback from other > > compositor/wayland devs. > >> // Background > > > > I work on the ChromeOS compositor, and recently I've been doing a > > bunch of stuff to improve our testing setup. At the moment, my main > > focus is improving our ability to write integration tests against > > DRM/KMS. > > > > It's pretty tricky to get right. Working with mocks of DRM loses all > > the useful helpers that live within the kernel, which would need to be > > rewritten (and kept up-to-date) in userspace. Stuff like writeback > > support would be even harder. > > > > Earlier this year, VKMS came up as a potential solution. I was happy > > to see that Weston is already using it. I've started thinking about > > what features from the wild we'd need, and started digging into the > > code. > > > > // Current Status > > > > I recently sent out my first patchset, which will let userspace build > > their own DRM drivers with ConfigFS. This implicitly adds support for > > multi-display setups which were impossible to test before. This also > > allows for multiple virtual DRM drivers to be created and used at the > > same time, which may increase test parallelism? Haven't tried it yet. > > > > v1 patchset: > > https://patchwork.kernel.org/project/dri-devel/list/?series=662676 > > cover letter: > > https://lists.freedesktop.org/archives/dri-devel/2022-July/365647.html > > > > // Rough Plans > > > > The big features I want to target with this work are: > > - Multi-display and movable planes. This is mostly covered by the > > ConfigFS changes. > > - Hot plugging. > > - Color, color management and HDR. Loads of new formats, support for > > color properties not currently implemented. Making sure writeback > > buffers are useful for this. > > - Improve IGT testing for VKMS (for new features and existing skipped > > tests) > > > > // Questions > > > > - What VKMS features could help your testing the most? > > - How much do you care about writeback buffer support vs CRC checks > > in tests atm? > > - What kinds of bugs do you get around DRM/KMS? > > - Any thoughts in general? > > Hey, nice work! > > So, not really related to wayland, but it would be cool if we could > add a generic vkms helper library for drivers to use for virtual > display functionality. E.g., for headless GPUs in data centers or for > virtualization. With a risk of continuing being a bit off topic... What use cases is there a need to pass this functionality via virtual mode setting to implement virtual monitors in display servers, for headless and virtualization? I realize that there is a use case for virtual mode setting outputs for virtual machines meant to e.g. test run distributions while imitating real hardware as close as possible, but for actual intended remote access to headless machines or virtual machines, compositors can just render to offscreen framebuffers and communicate in whatever way, e.g. using DMA buffers via some IPC, with the software solution intended to provide the actual access. Jonas
Re: I'm adding features to VKMS! What would you like to see?
On Fri, Jul 29, 2022 at 12:09:27PM +0100, Daniel Stone wrote: > Hi Jim, > > On Fri, 29 Jul 2022 at 08:30, Jim Shargo wrote: > > TL;DR: I'm working on extending VKMS and wanted feedback from other > > compositor/wayland devs. > > Awesome! :) Glad to see it, and yeah, I second everything Pekka said. > Having hotplug in particular would be really great. Enabling multi monitor and hotplug testing would be on my top wish list too. > > > // Questions > > > > - What VKMS features could help your testing the most? > > - How much do you care about writeback buffer support vs CRC checks > > in tests atm? > > - What kinds of bugs do you get around DRM/KMS? > > - Any thoughts in general? > > One thing I've really wanted is corner-case handling which just can't > be done in generic code. Weston is really aggressive at trying to get > things into planes, but we can only test those on actual systems with > particular semantics. > > I'd love to be able to programmatically fake those to be able to check > our fallbacks in an automatic way. About the best idea I've come up > with for that is being able to attach an eBPF hook to atomic_check. > The absolute MVP would be no arguments and an errno return; if you > completely control the environment, then you can store a counter in a > map and return a particular error for the n'th attempt. But a better > one would allow you to inspect the properties on each object in the > atomic state, and also things like framebuffer attributes (dimensions, > format, modifier, etc) so you could take action accordingly. Being able to queue errors would be great indeed. So far I've done this by mocking a subset of the libdrm API, which I could use to test e.g. failed commits handling: https://gitlab.gnome.org/jadahl/mutter/-/commit/93995754484536c61c7ddeffa2e50e4aef092a78 Jonas > > Thanks for taking this on! Really looking forward to it. > > Cheers, > Daniel
[ANNOUNCE] wayland-protocols 1.26
wayland-protocols 1.26 is now available. This release introduces the new staging protocol single pixel buffer, which together with the viewporter extension enables clients to easily create arbitrarily sized single color surfaces. Xdg-shell now also supports compositors announcing to surfaces some window management capabilities it supports. The text input protocol saw a clarification to an easily misinterpreted paragraph, which if interpreted in a different way than the new clarification makes clear hindered correct behavior from being implemented. This is also the first release which mandates new protocol extensions to follow RFC 2119 wording. Apart from has so far been mentioned, this release also comes with the usual clarifications, improved annotations, and other minor fixes. Alexandros Frantzis (1): readme: Mandate proper use of RFC 2119 keywords Carlos Garnacho (1): text-input: Reword the interpretation of serials to be more specific Daniel Stone (1): xdg-shell: Delete duplicate paragraph in xdg_popup Jonas Ådahl (1): build: Bump version to 1.26 Kenny Levinsen (1): viewport: Remove mention of wl_surface.attach x/y Kirill Primak (1): xdg-shell: clarify setting the parent to an unmapped toplevel Peter Hutterer (1): tablet: fix a copy/paste error Simon Ser (7): ci: add meson-logs artifacts ci: upgrade wayland to 1.20.0 members: say goodbye to Drew DeVault members: add Simon Zeni for wlroots/Sway build: stop using deprecated Meson functions xdg-shell: introduce toplevel wm_capabilities single-pixel-buffer: new protocol Tadeo Kondrak (5): build: Bump wayland-scanner version to 1.20.0 presentation-time: Annotate destructor events fullscreen-shell: Annotate destructor events linux-explicit-synchronization: Annotate destructor events staging/drm-lease: Annotate destructor event git tag: 1.26 http://wayland.freedesktop.org/releases/wayland-protocols-1.26.tar.xz MD5: 0c6b3e037f3881650d9a53610dd235c7 wayland-protocols-1.26.tar.xz SHA1: 8aeb1a629d847ec26e26d5a59c150add41e482bd wayland-protocols-1.26.tar.xz SHA256: c553384c1c68afd762fa537a2569cc9074fe7600da12d3472761e77a2ba56f13 wayland-protocols-1.26.tar.xz PGP: http://wayland.freedesktop.org/releases/wayland-protocols-1.26.tar.xz.sig signature.asc Description: PGP signature
Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
the VM stack to commandeer > cursor planes, and guest userspace must opt-in for that. > > How you design that is up to you. Maybe a new client cap, or maybe you > inspect every atomic commit did the userspace set the hotspot > properties this time or not. The main thing is that this has been > thought about and documented. > > I really do not see why adding that detail is so big deal, while not > adding that will leave virtual drivers fundamentally broken (incorrect > behaviour resulting from violating the KMS UAPI contract) for cursor > planes. > > - > > Maybe we need to take another step back. Why are virtual drivers > specifically DRM KMS drivers? Was the idea not that if virtual drivers > pretend to be KMS drivers, we would not need to patch userspace? But > now we need to patch userspace anyway, so why bother with KMS and its > design limitations that are well appropriate for hardware drivers but > not for virtual drivers? If you had your own winsys virtualization > protocol, you could do so much more than KMS is ever going to allow > you, and so much better. >From a user space perspective and distribution developer perspective, having virtual machines virtualize not only disks, memory and network cards but also GPUs and input devices is very helpful. Naturally there are alternative methods to getting content of a graphical session from a virtualized environment, e.g. RDP, without involving KMS, but when a virtual machine is used for running arbitrary distributions, e.g. for testing purposes, one wouldn't test the actual distribution if the graphical session didn't use the APIs otherwise used, so discussing whether we need this or not seems quite orthogonal to the issue at hand. I get that using the cursor plane the way virtual machines use them is problematic right now and method to get the expected behavior from both sides is needed, but the fact that there is minor differences in how hardware is virtualized and how it behaves in the real world (the same applies to e.g. pointer devices) is not a reason to say virtualization via KMS and evdev isn't needed, and it should be unblocked to allow using atomic mode setting to get the expected behavior. No matter what, to use atomic mode setting together with virtual machines, user space needs patching, but patching by enabling a client cap or equivalent is not comparable to introducing a whole new subsystem using something other than KMS. >From mutter's perspective, all we need is a way to set hotspots on cursor planes, and we can use atomic mode setting instead of the non-atomic paths that we currently fall back to for virtual machine drivers. Simon's suggestion of using a client capability for exposing the hotspot property, and not exposing the x,y coordinate of the cursor plane would be a completely acceptable, as it'd allow us to eventually migrate away from the deny list we have in place. Jonas > > Or just, you know, use RDP, VNC, and whatnot there already exists. > > Why KMS? > > That's probably obvious to you, but not me. > > I would also like to point out that I am not a kernel developer and I > have no NAK/veto rights on any kernel patches. I can only explain how > things look like from userspace perspective. > > I suspect there is nothing more I can say. Those were my opinions, but > the decisions are up to kernel maintainers. Hence, I can agree to > disagree with you. > > > Thanks, > pq
[ANNOUNCE] wayland-protocols 1.25
wayland-protocols 1.25 is now available. Apart from minor fixes and clarifications, this release also adds a new staging protocol for session locking, as well as a 'bounds' event to the xdg_toplevel interface. See the individual commits and protocol specifications for details. Isaac Freund (2): ext-session-lock-v1: new protocol xdg-shell: add invalid_resize_edge error value Jonas Ådahl (2): xdg-shell: Add toplevel "bounds" configure event build: Bump version to 1.25 Max Ihlenfeldt (1): xdg-shell: clarify conditions for remapping unmapped surfaces Simon Ser (1): linux-dmabuf: fix typo in dev_t example code git tag: 1.25 http://wayland.freedesktop.org/releases/wayland-protocols-1.25.tar.xz MD5: 0c192bf32de09ec30de4a82d1c65329c wayland-protocols-1.25.tar.xz SHA1: 275298332d124e40e345aa82bc8f48ef8cad3480 wayland-protocols-1.25.tar.xz SHA256: f1ff0f7199d0a0da337217dd8c99979967808dc37731a1e759e822b75b571460 wayland-protocols-1.25.tar.xz PGP: http://wayland.freedesktop.org/releases/wayland-protocols-1.25.tar.xz.sig signature.asc Description: PGP signature
Re: Should I draw menu by myself?
On Tue, Jan 18, 2022 at 01:12:19PM +0800, mx wrote: > Hi, > I want to know if I should draw menu by myself. And if I do > that, how could compositor like gnome or kde know my menu? What menu are you talking about here? If this is about popup menus, e.g. right click menu, "hamburger" menu, etc, these are all surfaces drawn by the client (yourself), and mapped using "xdg_popup" role (part of the xdg-shell protocol extension). If this is about the "window menu" which is usually what shows up when you right click on the title bar, this is (optionally) drawn by the compositor, e.g. done by kwin or gnome-shell. This menu is shown by the client issuing the "show_window_menu" request on the xdg_toplevel object. Jonas
Re: Absolute mouse position retrieval
The way this seems to be implemented seems quite similar to screen casting. With screen casting you can get per screen cast stream absolute cursor positions "streamed" via the PipeWire metadata, only that it will be alongside actual screen content as well, which I imagine is not something you need. Maybe it could be explored whether it makes sense to do this via the screen casting API, i.e. via PipeWire stream negotiation, by making it possible to not including the actual screen content when streaming. It might be a bit "overkill" but it'd have the benefit of being able to reuse all the sandbox permission management, portal dialog implementations, and related things that this involves. Jonas On Mon, Dec 06, 2021 at 11:19:06AM +, Jesse Van Gavere wrote: > We're not using a device driver, it's a very small application that uses > XInput2 to wait for mouse events using XNextEvent and when it sees a mouse > event it gets the current position through XQueryPointer and transmits that > over a serial link to our device. I was just wondering if a similar feature > on Wayland exists or it's a feature that will be added/can be added by us one > way or another. > > -Original Message- > From: Simon Ser > Sent: Monday, 6 December 2021 12:10 > To: Jesse Van Gavere > Cc: wayland-devel@lists.freedesktop.org > Subject: Re: Absolute mouse position retrieval > > > For a device we’re making, it’s necessary to have a daemon running on > > servers which frequently polls the absolute mouse location and > > transmits this to our device, this is a necessary feature to have > > correct operation of our device. > > Can you expand on this? > > Writing a device driver in user-space which connects to X11 or Wayland is not > the right way to do it.
[ANNOUNCE] wayland-protocols 1.24
wayland-protocols 1.24 is now available. This release adds feedback to the DMA buffer protocol, allowing smarter and more dynamic DMA buffer allocation semantics. Other changes include documentation improvements and improved testing infrastructure. This is also the first release of wayland-protocols that do not include a autotools build description. Alex Richardson (2): tests: allow cross-compiling the tests tests: check whether -Wl,--unresolved-symbols=ignore-all is supported Demi Marie Obenour (2): Use “software” instead of “user space” Improve tiled_* enum summary Fabrice Fontaine (1): meson.build: wayland-scanner is only needed for tests Jonas Ådahl (1): build: Bump version to 1.24 Simon Ser (4): Drop autotools linux-dmabuf: add note about pre-multiplied alpha unstable/linux-dmabuf: add wp_linux_dmabuf_feedback linux-dmabuf: send protocol error on invalid format/modifier git tag: 1.24 http://wayland.freedesktop.org/releases/wayland-protocols-1.24.tar.xz MD5: a66fa869543707279fb78a24d42cbb1d wayland-protocols-1.24.tar.xz SHA1: c695d37f75414b10e7e1ef8d67120332d4955586 wayland-protocols-1.24.tar.xz SHA256: bff0d8cffeeceb35159d6f4aa6bab18c807b80642c9d50f66cba52ecf7338bc2 wayland-protocols-1.24.tar.xz PGP: http://wayland.freedesktop.org/releases/wayland-protocols-1.24.tar.xz.sig signature.asc Description: PGP signature
Re: xdg-shell-client-protocol.h
On Thu, Nov 11, 2021 at 04:15:16PM +, Edgar Mobile wrote: > Greetings, > > I work my way through this Wayland tutorial: > > https://wiki.tizen.org/Wayland_xdg-shell_protocol > > To compile the example, I need a certain header allegedly in the Weston > source tree: > > xdg-shell-client-protocol.h > > But I can't find it. What should I do to make it appear? It's generated from 'xdg-shell.xml'[0] using 'wayland-scanner'. wayland-scanner is part of the wayland repository, and can be found via your distribution, e.g. the 'wayland-devel' package on Fedora. Jonas [1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml > > Regards
[ANNOUNCE] wayland-protocols 1.23
wayland-protocols 1.23 is now available. This release adds the new gesture "hold" to the pointer gesture protocol. David Edmundson (1): Set Vlad Zahorodnii as kwin maintainer Jonas Ådahl (1): build: Bump version to 1.23 Peter Hutterer (1): pointer-gestures: add hold gestures git tag: 1.23 http://wayland.freedesktop.org/releases/wayland-protocols-1.23.tar.xz MD5: 31a6c469718db37d2688109e548506e4 wayland-protocols-1.23.tar.xz SHA1: 8c4ebdce35953b1e2af458c139a432a308af6f50 wayland-protocols-1.23.tar.xz SHA256: 6c0af1915f96f615927a6270d025bd973ff1c58e521e4ca1fc9abfc914633f76 wayland-protocols-1.23.tar.xz PGP: http://wayland.freedesktop.org/releases/wayland-protocols-1.23.tar.xz.sig
[ANNOUNCE] wayland-protocols 1.22
wayland-protocols 1.22 is now available.
This release includes a new staging protocol: DRM object leasing.
Besides that, various test and build system improvements are included, as
well as a set of clarifications to the xdg-activation protocol and other
protocols.
Daniel Stone (2):
xdg-shell: Make xdg_surface fail when surface has role
tests: Include libwayland cflags/ldflags
Issam E. Maghni (1):
tests: use dynamic python path
Jonas Ådahl (1):
build: Bump version to 1.22
Manuel Stoeckl (1):
xdg-output: fix minor calculation error
Roman Gilg (4):
xdg-activation: use rst link
xdg-activation: use rst inline code
xdg-activation: correct sequence when X11 client spawns Wayland client
xdg-activation: rewrite and move description of token forwarding
Simon Ser (8):
members: add GitLab usernames
readme: mention the DCO
xdg-activation-v1: clarify set_{serial,surface}
presentation-time: use enum entry description tags
readme: fix unformatted label references
build: declare dependency for use as a subproject
build: fix indentation in tests/meson.build
build: only require C/C++ compilers for host
Vlad Zahorodnii (1):
xdg-activation: Fix an inconsistency
Xaver Hugl (1):
staging/drm-lease: DRM lease protocol support
Xavier Claessens (1):
tests: Fix build with -Wextra
git tag: 1.22
http://wayland.freedesktop.org/releases/wayland-protocols-1.22.tar.xz
MD5: 05aac9a9a9447225769f993cf673c5bd wayland-protocols-1.22.tar.xz
SHA1: 059507ebbb8a32a4caa537600ff31397ff34e995 wayland-protocols-1.22.tar.xz
SHA256: 96e7cf03524995a47028236c6d6141c874e693cb80c0be8dabe15455cdd5a5a7
wayland-protocols-1.22.tar.xz
PGP: http://wayland.freedesktop.org/releases/wayland-protocols-1.22.tar.xz.sig
signature.asc
Description: PGP signature
Re: Proxying Wayland for security
On Wed, Jul 28, 2021 at 01:36:54PM +, Alyssa Ross wrote: > Jonas Ådahl writes: > > > On Wed, Jul 28, 2021 at 11:06:43AM +, Alyssa Ross wrote: > >> Daniel Stone writes: > >> > >> >> One big issue for us is protecting the system against potentially > >> >> malicious Wayland clients. It's important that a compartmentalized > >> >> application can't read from the clipboard or take a screenshot of the > >> >> whole desktop without user consent. (The latter is possible in > >> >> wlroots compositors with wlr-screencopy.) > >> >> > >> >> So an idea I had was to was to write a proxy program that would sit > >> >> in front of the compositor, and receive connections from clients. If > >> >> a client sent a wl_data_offer::receive, for example, the proxy could > >> >> ask for user confirmation before forwarding that to the compositor. > >> > > >> > As you've noted, the core protocol doesn't offer any way to scrape > >> > these contents without additional extension protocols, which are not > >> > implemented by all compositors. Generally speaking, GNOME's Mutter and > >> > Weston tend not to implement these protocols, and wlroots-based > >> > compositors tend to implement them. > >> > >> That's true for screenshots, but it's not true for clipboard contents, > >> right? As I understand it, any application can paste, with the only > >> restriction being that it has to be in the foreground at the time, and > >> wl-clipboard[1] seems to demonstrate that it's possible to fulfill that > >> requirement without being visible to the user at all. > > > > Getting things from the clipboard is generally supposed to require an > > interaction of some sort, e.g. a button press, key press, touch down, > > etc, but it might be not properly implemented here and there. > > wl-clipboard relies on this not being done good enough, and will > > eventally stop working, unless there exist some global state like > > clipboard manager protocol that bypasses any content restrictions that > > wl_data_device and friends apply. > > That's good to know, but even so, there's no way for the compositor to > know that the interaction corresponds to a user intent to paste. So an > application could still abuse a mouseover, or just some unrelated typing > in its window, to read the clipboard contents when the user wasn't > expecting it to. That is indeed not possible, and likely very hard to get right. E.g. a simple click or arbitrary key press might mean intent to paste, e.g. press a "Paste" button. It's far from only related to Ctrl+V. Only solution I see is only allow clipboard for sandboxed clients, and explicitly grant access on a per application basis via some dialog querying the user, similar to how audio/camera/... is granted in Flatpak. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wed, Jul 28, 2021 at 11:06:43AM +, Alyssa Ross wrote: > Daniel Stone writes: > > >> One big issue for us is protecting the system against potentially > >> malicious Wayland clients. It's important that a compartmentalized > >> application can't read from the clipboard or take a screenshot of the > >> whole desktop without user consent. (The latter is possible in > >> wlroots compositors with wlr-screencopy.) > >> > >> So an idea I had was to was to write a proxy program that would sit > >> in front of the compositor, and receive connections from clients. If > >> a client sent a wl_data_offer::receive, for example, the proxy could > >> ask for user confirmation before forwarding that to the compositor. > > > > As you've noted, the core protocol doesn't offer any way to scrape > > these contents without additional extension protocols, which are not > > implemented by all compositors. Generally speaking, GNOME's Mutter and > > Weston tend not to implement these protocols, and wlroots-based > > compositors tend to implement them. > > That's true for screenshots, but it's not true for clipboard contents, > right? As I understand it, any application can paste, with the only > restriction being that it has to be in the foreground at the time, and > wl-clipboard[1] seems to demonstrate that it's possible to fulfill that > requirement without being visible to the user at all. Getting things from the clipboard is generally supposed to require an interaction of some sort, e.g. a button press, key press, touch down, etc, but it might be not properly implemented here and there. wl-clipboard relies on this not being done good enough, and will eventally stop working, unless there exist some global state like clipboard manager protocol that bypasses any content restrictions that wl_data_device and friends apply. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Multihead with wayland, similar to
On Tue, Jun 01, 2021 at 11:57:50AM +0200, Pietro Battiston wrote: > Sorry if I'm bothering again with non-dev questions, but this should be > my last mail on the topic. I've more or less understand where we stand > but I need one further clarification: > > Il giorno gio, 27/05/2021 alle 08.23 +0200, Jonas Ådahl ha scritto: > > [...] > > * Introduce "virtual" monitor screen recording to > > org.freedestop.portal.ScreenCast > > (https://github.com/flatpak/xdg-desktop-portal) and the portal > > backend relevant to you. > > > > Can you tell me if my understanding is correct? > > - (starting with Mutter 40.0) GNOME can work on headless/virtual > monitors Correct. > - ... so it can also work across a headless/virtual monitor and a real > one Correct in theory; there seems to be an issue when mixing that I haven't fixed yet. > - ... but PipeWire is unable to isolate one monitor out of a multi- > monitor desktop if such monitor is a virtual one With PipeWire, every streamed monitor is streamed in isolation, and be it virtual or not makes no difference; what needs to know how to select "virtual" vs "physical" is the entity that creates the streams. For the portable approach, what is lacking is the API in org.freedesktop.portal.ScreenCast to request screen casting of a virtual monitor, and in the GNOME case, the hooks to org.gnome.Mutter.ScreenCast (implemented in xdg-desktop-portal-gtk) to record from a virtual monitor instead of a real one. If you're interested in prototyping that let me know, so I can describe in detail how it could work. > - ... and so the same applies to GNOME Remote Desktop? Currently GNOME Remote Desktop can run headlessly with a pre-created virtual (headless) monitor; it doesn't yet know how to create them itself. > > (because my understanding of > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698#note_1023317 > is that GNOME Remote Desktop should be perfectly able to stream a > single Wayland-GNOME virtual monitor...) In theory, yes it can. For "remote login" (compared to "remote assistance" which is what it's capable of now) it'll use these virtual monitors and "configure" them depending on the capbilities and state of the remote desktop clients. However, right now there is no patch that does s/RecordMonitor/RecordVirtual/ however, more work is needed her than switching method to record, as e.g. the size needs to come from the client, as well as login session management etc. Jonas > > Thanks again, > > Pietro > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Multihead with wayland, similar to
On Thu, May 27, 2021 at 08:01:39AM +0200, Pietro Battiston wrote: > Dear devs, > > (not being an expert in Wayland at all) I have been trying in vain to > find a solution to use another device as an additional monitor for my > desktop. > > Other people seem to have tried, too¹ (trying to port to Wayland > different approaches which could be used with Xorg), and at least at > first glance, it doesn't seem like the found a solution. > > Is there one? I don't know of any ready (portable) solutions for this, but with a bit of plumbing work, it could be possible. The building blocks I'm thinking of is Miracast and screen casting with a virtual monitor. A rough summary what would be needed is: * Introduce "virtual" monitor screen recording to org.freedestop.portal.ScreenCast (https://github.com/flatpak/xdg-desktop-portal) and the portal backend relevant to you. * Teach e.g. GNOME Network Displays (https://gitlab.gnome.org/GNOME/gnome-network-displays) how to use virtual monitor recording. * Install a "Miracast sink" app on your device (TVs often have it built in) You could probably replace the second two steps with some VNC/RDP thing, but that will not work for many types of devices where Miracast do. Jonas > > Thank you - for your answers, and for this great piece of software. > > Pietro Battiston > > > ¹ > https://superuser.com/questions/1434779/using-a-tablet-as-a-second-monitor-with-wayland > https://www.reddit.com/r/wayland/comments/623los/distributed_multi_head_like_using_wayland_similar/ > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] wayland-protocols 1.21
wayland-protocols 1.21 is now available. This release introduces support for installing using meson instead of autotools. The aim is to in a later release remove support for installing using autotools. Also new with this release is the introduction of a new protocol phase that replaces the old "unstable" phase: "staging". The main purpose of this is making it more painless to transition a protocol from it's testing-in-production phase to declaring it stable. See README.md for details. This release also introduces a new staging protocol: xdg-activation, meant to enable transferring focus between different toplevel surfaces. For example from a launcher to a launchee, or one focused application to another. A handful of cleanups, clarifications, and fixes has seen the light of day as well, see the included shortlog for details. Aleix Pol (1): Include a new xdg_activation protocol Bhushan Shah (1): text-input: document behavior regarding multiple text-inputs Carlos Garnacho (1): staging/xdg-activation: Describe interoperation with X11 Jonas Ådahl (11): README.md: Add some merge request triaging conventions Add meson build system support tests: Add compile tests ci: Switch to upstream ci-templates and use Debian bullseye ci: Add test-meson step build: Fix wayland-protocols.pc when using autotools ci: Use ci-fairy to check for Signed-off-by ci: Make the FDO_UPSTREAM_REPO variable global Replace `unstable` with `staging` Makefile.am: Include meson-only files build: Bump version to 1.21 Pekka Paalanen (1): linux-dmabuf: no buffer errors on device disappearance Peter Hutterer (1): pointer-gestures: correct description of pinch Roman Gilg (1): Update point-of-contact for KDE Simon Ser (4): xdg-shell: describe how to re-map an unmapped toplevel xdg-shell: explain how clients need to perform an initial commit linux-dmabuf: clarify what mixed valid/INVALID modifiers mean xdg-foreign: add error enums Vlad Zahorodnii (2): Use correct indefinite article before "xdg" fullscreen-shell: Clarify that present requests assign a surface role onox (5): presentation-time: Add enum attribute to 'flags' pointer-constraints: Add enum attribute to 'lifetime' linux-dmabuf: Add enum attribute to 'flags' fullscreen-shell: Add enum attributes to various arguments text-input: Add enum attributes to various arguments git tag: 1.21 http://wayland.freedesktop.org/releases/wayland-protocols-1.21.tar.xz MD5: 8196416baac07cd833bcb86b69da41a7 wayland-protocols-1.21.tar.xz SHA1: 6e0e2a05edb43d32e3b2e3f681ef266a287a186e wayland-protocols-1.21.tar.xz SHA256: b99945842d8be18817c26ee77dafa157883af89268e15f4a5a1a1ff3ffa4cde5 wayland-protocols-1.21.tar.xz PGP: http://wayland.freedesktop.org/releases/wayland-protocols-1.21.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Submit Code about weston
On Fri, Apr 30, 2021 at 10:31:03AM +0300, Pekka Paalanen wrote: > On Fri, 30 Apr 2021 09:11:18 +0200 > Jonas Ådahl wrote: > > > On Fri, Apr 30, 2021 at 11:53:16AM +0800, kai.x...@thundercomm.com wrote: > > > Hello wayland community， > > > > > > At present, we use open source mail(kx...@codeaurora.org) to submit code. > > > Error log: > > > jeff@001:~/test/test/xxx/weston$ git push origin main > > > Username for 'https://gitlab.freedesktop.org': kxing > > > Password for 'https://kx...@gitlab.freedesktop.org': > > > remote: You are not allowed to push code to this project. > > > fatal: unable to access > > > 'https://gitlab.freedesktop.org/wayland/weston.git/': The requested URL > > > returned error: 403 > > > > > > Thanks for your support. > > > > What you should do is fork the weston repository to your own account on > > freedesktop.org. You'll find a button labeled "Fork" on the top right of > > the page https://gitlab.freedesktop.org/wayland/weston/ > > > > After having forked, add the address to that fork as a new remote to > > your locally cloned checkout, and push your changes to some branch > > there, and create a merge request using that branch. > > > > See > > https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html > > and > > https://docs.gitlab.com/ee/user/project/merge_requests/getting_started.html > > > > for further instructions. > > Weston also has > https://gitlab.freedesktop.org/wayland/weston/-/blob/master/CONTRIBUTING.md > > Do we need to clarify things there? Seems the URL the "GitLab merge requests" link points to in that document doesn't work anymore. Jonas > > > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Submit Code about weston
On Fri, Apr 30, 2021 at 11:53:16AM +0800, kai.x...@thundercomm.com wrote: > Hello wayland community， > > At present, we use open source mail(kx...@codeaurora.org) to submit code. > Error log: > jeff@001:~/test/test/xxx/weston$ git push origin main > Username for 'https://gitlab.freedesktop.org': kxing > Password for 'https://kx...@gitlab.freedesktop.org': > remote: You are not allowed to push code to this project. > fatal: unable to access 'https://gitlab.freedesktop.org/wayland/weston.git/': > The requested URL returned error: 403 > > Thanks for your support. What you should do is fork the weston repository to your own account on freedesktop.org. You'll find a button labeled "Fork" on the top right of the page https://gitlab.freedesktop.org/wayland/weston/ After having forked, add the address to that fork as a new remote to your locally cloned checkout, and push your changes to some branch there, and create a merge request using that branch. See https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html and https://docs.gitlab.com/ee/user/project/merge_requests/getting_started.html for further instructions. Jonas > > BRs > Kai Xing > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to make infinite-scrolling GUI widgets under Wayland ?
On Mon, Apr 26, 2021 at 04:57:01PM +0200, Jean-Michaël Celerier wrote: > Hello, > I am working on the multimedia sequencer ossia score (https://ossia.io). > > I am trying to make sure that it works fine for Linux users under wayland. > > For audio (and in general multimedia) apps, there is a very common family > of GUI widget which allows to scroll a value "infinitely" (or at least much > more than the height of the screen) - the usual user interaction is : > * User clicks on the widget : the mouse cursor disappears (some apps will > give a kind of highlight to the widget to indicate that it is being acted > upon) > * User moves their mouse upwards or downwards to increase the value > * At some point they reach the top or the bottom of the screen : to > continue scrolling transparently, the app translates the mouse cursor to > the top of the screen > * When the user releases the mouse the cursor reappears at the position > where it was clicked. > > This is needed in two case : > - To make sliders / knobs with easily adjustable values > - To implement infinite- or at least very long scrolling in minimaps. > > I made a few videos: > - Video 1: example of slider with the feature in Ableton Live (one of the > most used music making app) : https://streamable.com/ecepvc > > - Video 2 : example of minimap in Ableton Live : > https://streamable.com/epc7r1 > > - Video 3 : Example of the pain induced by software that do not support the > feature: here I want to change the tempo but cannot because the mouse hits > the top of the screen. Thus I have to release and go click on it again : > https://streamable.com/bniht5 > > Thus, my question is : what must I do as the developer of such an app to > make sure that my users will have widgets that will work "as expected" for > people in the media creation field, whatever the wayland compositor my > users are using (KDE Plasma, GNOME, sway...). I don't want them to have an > inferior user experience on Linux when compared to other operating systems. > > The googling I've done so far seems to say that there is no way to position > the cursor absolutely directly through wayland, but the only other way > seems to be through /dev/uinput which needs root permissions to write to > (and my userbase are artists who generally don't have the technical > skillset to know that they must mark things as root; I could always check > and show a popup that requests the user to do chmod u+rwx on /dev/uinput on > startup but that would be my last resort...) To implement the behavior shown in video 1 and 2, the "Wayland" way is depends on two protocols extension: * Pointer locking extension[0] * Relative pointer motions extension[1] With the core wl_pointer protocol object, you can control when the pointer cursor sprite is showing or not; with the pointer locking extension, you can effectively lock the pointer position to its position, meaning it will stay put and won't "escape" your application window; and lastly, with the relative pointer motions extension, you can receive pointer motions that are not affected by actual movement of the pointer cursor sprite, i.e. even if the pointer hit an edge or doesn't move, you'll still receive the motions as sent from the device. I think most compositors support these two protocol extensions as they are a corner stone in how e.g. 3D FPS games work. Jonas [0] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml [1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/unstable/relative-pointer/relative-pointer-unstable-v1.xml > > Thanks ! > Jean-Michaël > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Change default Wayland branches to 'main'
On Thu, Apr 08, 2021 at 03:03:08PM +0300, Pekka Paalanen wrote: > On Thu, 8 Apr 2021 12:20:46 +0100 > Daniel Stone wrote: > > > Hi all, > > Going with a lot of other Git-based projects (and following the leads of > > e.g. GitHub and GitLab), freedesktop.org is planning to change the default > > branch name for its new projects to 'main' rather than 'master'. > > > > Mesa is already migrating, and they have helpfully prepared a small Python > > script which will retarget open MRs from 'master' to 'main'. > > > > I propose that we do this for all the wayland/* repositories, either this > > weekend or next; I'm happy to make the changes (rename 'master' to 'main' > > and retarget all open MRs). Does anyone have any opinions or suggestions? > > Hi, > > fine by me. No objections from me either. Jonas > > > Thanks, > pq > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Wed, Apr 07, 2021 at 10:59:18AM +, Simon Ser wrote: > FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd > definitely be interested in using such as library. A C API with no > dependencies is pretty important from my point-of-view. > > I'd prefer if C++ was not used at all (and could almost be baited into > doing the work if that were the case), but it seems that ship has > sailed already. The same for Mutter / GNOME, not having to maintain a EDID parser would be great. Though personally I don't care if it's implemented in C++, C or whatever, as long as there is a C API to use. Jonas > > Simon > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, Feb 22, 2021 at 01:56:46PM +0200, Pekka Paalanen wrote: > On Mon, 22 Feb 2021 12:10:08 +0100 > Jonas Ådahl wrote: > > > On Mon, Feb 22, 2021 at 10:49:33AM +, Simon Ser wrote: > > > > I'd like to avoid making this general, if we go down this road. Make it > > > specific to the win32 API and wine. Wayland-native toolkits don't need > > > it. > > > > Sounds potentially not horrible in theory, but is it remotely possible? > > There are these approaches I can think of: > > > > * Add a "wl_win32" to wayland-protocols > > > > Adoption by anyone wanting to bypass the Wayland windowing model can use > > it trivially, and we have a X11 like situation where everything grabs > > everything and arbitrary client driven window self management. > > While this is definitely a concern, I wouldn't be that pessimistic. The > interface can be named e.g. ext_win32_foreign_window_system to make it > feel awkward to be used in normal apps. (Not wp_ namespace, either.) I don't think any prefixing makes any difference if it's widely available enough (or anywhere, and just broken experience where it's not), for anyone that just wants to get the job done. > > Also, if tailored specifically for Wine and Win32 to fill in gaps, maybe > it is not generally that useful. It might be easier for normal apps to > just play by the book than try to twist that to do their bidding. I don't believe that will help. If it quacks like a duck, it's a duck, even if it has a win95 theme. And I naively assume that the things that some apps want to do that is not possible on Wayland, is quite similar to these missing wine features. Then again, I'm also just speculating. > > I'd still put it in wayland-protocols. > > > So, how would we make it not de-facto general? > > I would hope that happens by tailoring it specifically for Wine, using > Win32 and Wine terminology. > > > Not to meantion the head ache of letting clients in on configuring their > > window positions when any kind of HiDPI scaling, fractional or nat, is > > done. > > I haven't yet seen anyone say that if a coordinate system is exposed, > it must cover the outputs exactly and it must be at output pixel scale > or whatever. It only needs to be just enough from a client perspective > and for an existing application. > > Maybe it is enough to create a new coordinate system object, and make > it the size of the "desktop application area" rather than output size > or desktop size. That is, the area normally taken by a maximized app, > for instance. Then, one could register xdg_toplevels with that > coordinate system object so they can see and set their position with > respect to that coordinate system. A bit like rootful Xwayland or the > Wine virtual desktop, except without the actual root window. Maybe or > maybe not allow other windows in between in the z-order. Always-on-top > semantics would be restricted within the coordinate system object. And > so on? > > A coordinate system itself could perhaps be tied to one specific > xdg_toplevel, using the surface coordinate system of it as the basis. > > Obviously you can't make a real fullscreen window, or maybe not even a > real maximized window, with just position and size in this design, or > obscure all other windows. Maybe it's also restricted to a single > Wayland output at a time, too. The compositor would be free to decide > the size and positioning of this 2D coordinate space. > > But that's is quite far in the general direction hand waving, because I > don't know what Wine specifically would need. TBH, this just sounds like a dumbed down X11 like window management with a few limitations. But it's too speculative for me to make any actual sense of, I don't know what kind of wine problems you intend to solve with all of that. I'd rather we look at each particular case that comes up in detail that comes up, that require some X11 style control, and look at how it can be emulated, instead of speculating about how much X11 semantics needs to be ported over to make wine feature complete enough. Jonas > > > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, Feb 22, 2021 at 11:21:04AM +, Simon Ser wrote: > On Monday, February 22nd, 2021 at 12:10 PM, Jonas Ådahl > wrote: > > > Sounds potentially not horrible in theory, but is it remotely possible? > > There are these approaches I can think of: > > > > * Add a "wl_win32" to wayland-protocols > > > > Adoption by anyone wanting to bypass the Wayland windowing model can use > > it trivially, and we have a X11 like situation where everything grabs > > everything and arbitrary client driven window self management. > > > > * Make "wine" distribute a "wl_win32.xml" and make compositors depend on > >on wine-devel, implementing the protocol. > > > > Practically the same as above, just a 'cp ~/wine/protocols/wl-win32 > > protocols' away, and we're back with wierd grabs and client managing > > their own surfaces again. > > I like to have wayland-protocols as a space shared between client and > compositor developers. Having the protocol in a client code-base > doesn't make it clear that the compositor folks need to ack new > versions. This idea would be a bit like the `xwayland_output` replacing parts of `xdg_output` that has been discussed, where xwayland itself is the owner and distributor of this protocol file. Just because it'd be the only potential user. I agree it's not a good fit here. > > > * A libwine-wayland, a wineBindWaylandDisplay() with some kind of half > >assed authentication. > > > > I assume noone wants this (including me). But client developers would > > have to be really obnoxious to work around it which might be enough to > > not make it general. > > Hm, right, I'd really like to avoid this. The authentication would be > useless anyways. > > > A "allow/deny" nag/query (aka "Do you want this application you > > installed to work or want me to break it for you?") I wouldn't call a > > reasonable option either. > > > > So, how would we make it not de-facto general? > > > > Not to meantion the head ache of letting clients in on configuring their > > window positions when any kind of HiDPI scaling, fractional or nat, is > > done. > > Maybe use e.g. security-context [1] or similar to be able to hide > wine-specific Wayland interfaces from applications that don't need it. > Would need some kind of metadata in Flatpak and friends to allow win32 > apps to opt-in. Would would be quite similar to a "Would you like me to stop breaking your application?" approach, except moved to packagers and angry users not using Flatpak like setups that has to find the "Unbreak my system" setting. > > But before anything happens, try to make win32 work as much as possible > with just xdg-shell. Alexandros Frantzis seems to have made good > progress [2] on that front already. > > [1]: > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68 > [2]: > https://www.collabora.com/news-and-blog/news-and-events/wayland-on-wine-an-exciting-first-update.html Right, and it's nice to see steps are taken to try to translate what was previously done the X11 way e.g using viewports instead of changing the monitor resolution, and parent relative surface positioning for menus etc, but one will have to accept it's not likely possible to be completely feature complete using the "Wayland windowing model" as a backbone, as some of those features are considered anti-fatures in that model. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, Feb 22, 2021 at 10:49:33AM +, Simon Ser wrote: > On Monday, February 22nd, 2021 at 11:44 AM, Carsten Haitzler > wrote: > > > I also would want to avoid baking explicit absolute positioning into wayland > > protocol - be it as a core agreed to add-on to xdg-shell or even a "commonly > > supported extension". What I'd like it some better solution. For example - > > if > > an app wants to absolute position a window because it's doing a custom "my > > own > > notification popup" much like Chrome and Firefox now like to do in X11, > > then I'd > > prefer this be explicitly exposed as a "notification surface with requested > > screen location hints" and so the compositor can decide to do something more > > intelligent with it. I am sure this list of use cases will probably be > > extensive and also depend on the API in wine that is being wrapped and > > intercepted - the higher level it is, the more it knows about the intended > > use > > case. > > I'd like to avoid making this general, if we go down this road. Make it > specific to the win32 API and wine. Wayland-native toolkits don't need > it. Sounds potentially not horrible in theory, but is it remotely possible? There are these approaches I can think of: * Add a "wl_win32" to wayland-protocols Adoption by anyone wanting to bypass the Wayland windowing model can use it trivially, and we have a X11 like situation where everything grabs everything and arbitrary client driven window self management. * Make "wine" distribute a "wl_win32.xml" and make compositors depend on on wine-devel, implementing the protocol. Practically the same as above, just a 'cp ~/wine/protocols/wl-win32 protocols' away, and we're back with wierd grabs and client managing their own surfaces again. * A libwine-wayland, a wineBindWaylandDisplay() with some kind of half assed authentication. I assume noone wants this (including me). But client developers would have to be really obnoxious to work around it which might be enough to not make it general. A "allow/deny" nag/query (aka "Do you want this application you installed to work or want me to break it for you?") I wouldn't call a reasonable option either. So, how would we make it not de-facto general? Not to meantion the head ache of letting clients in on configuring their window positions when any kind of HiDPI scaling, fractional or nat, is done. > > Notifications popups are part of the desktop environment and clients > shouldn't try to display them directly. Agreed. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland crashes when label size in Gtk is large
On Mon, Feb 08, 2021 at 01:45:37PM +, Irene Kravets wrote: > I am using Wayland/Weston. Running a simple Python script that uses Gtk to > display a couple of labels. If the size of the label font goes past a certain > size (nothing unreasonable), Wayland crashes with error message "Error 71 > (Protocol error) dispatching to Wayland display". I enabled WAYLAND_DEBUG and > I see "xdg_surface buffer does not match the configured state" in the log. > If the text of the label is truly too large to fit (which it's not), I would > expect it to be clipped or perhaps not be displayed, but I wouldn't expect a > crash. How do I fix this issue? This sounds like the gtk window is e.g. maximized, or fullscreen, but ignores the configuration it received to fulfill those states. Ignoring that state is a violation of the protocol specification, and thus a bug in gtk. I suggest opening a bug in the gtk issue tracker: https://gitlab.gnome.org/GNOME/gtk/issues/new Jonas > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Foreign surface
On Thu, Nov 26, 2020 at 02:53:05PM -0500, gherissi ayachi wrote: > Hi, > > Background: our library allow to grab video to a supplied windows handle, > When using X11 the user pass the XID to the lib > > and we can paint to this Window and do some interaction (pointer), All is > done in the same process. > > In Wayland, The user has to provide us with his wl_display and wl_surface > and we have to use subsurface to do the paint right ? By using subsurfaces, you can tie one surface to anothor, making them appear as one, and it sounds like this is something that would fit your use case. Note that both your library, and the user of the library must share the same wl_display connection; you cannot tie one surface of one client with a surface of another, using subsurfaces, if they don't share the same Wayland connection. > > what about pointer events (motion and button). Each subsurface can set their own input region, and the compositor will route the input events accordingly. Do make note of things like implicit pointer button grabs, that may apply. If this is not enough, you need some way to pass internal input event within your process, not involving Wayland. For example if your parent window receives all input events, and the subsurfaces none, the framework managing the main surface needs to pass some internal input event representation to the owner of the subsurface using some API understood by both parties. Jonas > > Thank's > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: multiple wl surfaces commit in one client
On Fri, Nov 06, 2020 at 07:51:26AM +, Simon Ser wrote: > Hi, > > On Friday, November 6, 2020 3:14 AM, zou lan wrote: > > > Hi Simon & pekka > > > > Thank you for your reply! > > > > >>The OS could pre-empt the client after > > >>the first wl_surface_commit is flushed on the wire and before the > > >>second one is. > > > > I want to ask if after first wl_surface_commit, but I don't call > > wl_display_flush/wl_display_dispatch, is the first wl_surface_commit > > flushed to server because out buffer of the connection is full? > > That is correct. > > > https://github.com/wayland-project/wayland/blob/master/src/connection.c, > > can we increase the buffer size in this structure wl_buffer to reduce > > the possibility of this? > > I'd rather not. This would not fix the issue, and it's unclear if it'd > really help. > > > By the way, for the WIP protocol, > > https://gitlab.freedesktop.org/jadahl/wayland-protocols/-/blob/wip/transactions/unstable/transactions/transactions-unstable-v1.xml, > > do we have any patchset in weston to implement it? I don't find it in > > weston master branch. > > I'm not aware of any Weston implementation as of yet. As you can see, > the protocol hasn't yet been merged in wayland-protocols. Writing a new > implementation would certainly help getting the protocol merged. weston, mutter and gtk implementations are linked to from this comment: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26#note_554405 Jonas > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC: libei - emulated input in Wayland compositors
en should be shared. > > > > Right, what the basic idea of the portals is, is pretty clear to me. > > Basically it pipes requests of sandboxed apps through an > > authentication and permission system in case they want to interact > > with outside their sandbox. It's more about the cases where they > > don't. A Wayland client in a sandbox interacts via Wayland protocol > > with the outside of their sandbox, but that's not going through > > xdg-portals, or is there a permission to block it from that? > > For flatpak at least, you need to explicity allow wayland access > (--socket=wayland) at which point it's basically a wayland-sized hole in the > sandbox. > > > > 3) It manages remembered access, using a common permission store[0]. For > > > example if an application was permanently denied camera access, the > > > portal will know about this and not query the portal backend. > > > > Yea, I quickly did an online search for a GUI to it and found [2] > > which looks awesome. Also answers my question above: there exist > > permissions to block a sandboxed app from Wayland or X11. But I assume > > a user won't be asked for every new GUI app he installs if it is > > allowed to show some pixels and instead the permission is by default > > set to allowed. Looking back at it the GUI app should set this as a > > permission in their Manifest file, which is like a default on install. > > It does indeed ask, or at least tell you: > > $ flatpak install --user org.gimp.GIMP > Looking for matches… > Found similar ref(s) for ‘org.gimp.GIMP’ in remote ‘flathub’ (user). > Use this remote? [Y/n]: y > > org.gimp.GIMP permissions: > ipc network x11 file access [1] dbus access [2] > tags [3] > > [1] /tmp, host, xdg-config/GIMP, xdg-config/gtk-3.0, xdg-run/gvfs > [2] org.freedesktop.FileManager1, org.gtk.vfs, org.gtk.vfs.* > [3] stable > > ... > > Proceed with these changes to the user installation? [Y/n]: > > > So the built-in permissions for gimp include x11 and direct access to the > org.freedesktop.FileManager1 DBus API. To re-iterate my above point - > because gimp has x11 access, the sandbox cannot stop it from emulating input > via XTEST. Likewise, if wayland was parts of the permission you cannot > arbitrate access to wayland protocols through a portal. > > For the rest I'm going let Jonas answer since there are some questions in > there where I'm not sure my answer would be correct :) > > Cheers, >Peter > > > > > In the diagram you can see 5 "interactions" between different components > > > that takes place, (1), (2), (3), (4) and (5), resulting in the side > > > channel (C). > > > > > > (1) is the application making a request to be able to inject input > > > events. > > > > > > (2) is the portal, having authenticated the application the request came > > > from and verified the metadata, does a method call on behalf of the > > > application to the portal backend implementation to check with the user > > > then maybe open an Ei session. > > > > > > (3) is the portal backend, possibly having queried the user about > > > permissions, opening a new Ei session. > > > > > > (4) is the backend returning from the method call done in (2), possibly > > > with an open file descriptor to a Eis session. > > > > The portal backend creates the open file descriptor, something the > > sandboxed app can't do per se. In general a sandboxed app can not > > create arbitrary sockets, correct? The portal backend would create a session of whatever service that provides a by-default blocked functionality. The fact that it involves opening file descriptors is just because passing such objects around is a convenient way to open up channels that can be passed across the sandbox barrier. A sandbox can do pretty much anything inside the sandbox, including creating or connecting to arbitrary sockets, but it has limited view and effect on anything outside of the sandbox. It would for example not be able to see /run/user/1000/ei-0 to open it directly, it needs the portal to open that socket, and pass the open file descriptor, after having authenticated and authorized the request. Or in D-Bus terms, a sandbox wouldn't, unless explicitly allowed, be able to see e.g. a org.freedesktop.Ei D-Bus API on e.g. the org.gnome.Mutter name on the bus, which e.g. a GNOME portal backend might use to open the Ei socket. > > > > > (5) the portal responds to the requests made from the application in > > > step (1). This
Re: RFC: libei - emulated input in Wayland compositors
s a sandbox aware session manager. In both of these two, however, PipeWire is a side channel, that was not established until it was clear that all parts (portal, portal backend and resource source (e.g. pipewire or compositor)) had agreed upon it. In the libei/libeis case, it could work very similarly. Here is a rough diagram of how it could be structured: Sandbox barrier System || Sandbox || - || | Permission| || | Store | || >| |<- || / | | \ || / | | \ (p) || | -\|| | \ || | v || | - --- | - | Portal proc. | | | | |Portal | (2) | deny/grant 8-<| (1) | | | |Backend|<|- - -[auth] - -|<-| Application | | | - - |-|- - - - - - - -|->| | | | deny/ 8-|Compositor .lib\__/ \__/ . | | .eis ___/ || \___ libei . | | . . / || \ . | | | || |. . . . | | | || | | - || ___ || || In the diagram you can see 5 "interactions" between different components that takes place, (1), (2), (3), (4) and (5), resulting in the side channel (C). (1) is the application making a request to be able to inject input events. (2) is the portal, having authenticated the application the request came from and verified the metadata, does a method call on behalf of the application to the portal backend implementation to check with the user then maybe open an Ei session. (3) is the portal backend, possibly having queried the user about permissions, opening a new Ei session. (4) is the backend returning from the method call done in (2), possibly with an open file descriptor to a Eis session. (5) the portal responds to the requests made from the application in step (1). This response is then used to establish (C). See below. (C) is the newly established Eis channel where the application can inject input using libei, and the compositor being able to process injected input in a similar way to how it processes libinput events. (p) and (p') corresponds to permission store interaction (where p' is optional but recommended). Either up front by the portal, or e.g. a compositor may be permission store aware, so that it can terminate a session that changes permission after access was originally granted. This is for example how PipeWire handles camera access being revoked. Today, unsandboxed applications are treated on a per case basis. In some cases (e.g. screen casts, screenshots), the only effect is that the name of the application is not presented as part of a dialog, while in other cases it simply defaults to some policy e.g. deny or grant. The permission store itself doesn't require entries to have a sandboxed application ID, but the portal itself currently doesn't have a way to identify an application that isn't running inside a sandbox. Thus, if a Ei session policy default is to ask, for a portal to be able to remember the permission for an unsandboxed application, we would have to add a way for the portal to blindly trust some ID or key of some sort the application provides. Xwayland would be considered an unsandboxed application, even if the application a XTEST request came from was sandboxed. Exactly how to deal with this, is an open question, e.g. whether to treat all "X11" applications as one giant blob, or whether to distinguish between them, depends on in what ways we would be able to let the portal trust metadata coming from unsandboxed applications. Jonas [0] https://github.com/flatpak/xdg-desktop-portal/wiki/The-Permission-Store > > [1] https://gitlab.com/romangg/kwinft/-/commits/libei > [2] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/431 > [3] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/465 > > > The aim is that a client can simply iterate through all of the options until > > finds a connection. Once that's found, the actual code for emulating input > > is > > always the same so it's trivial to implement a client that works on any > > compositor that supports some backend of libeis. > > The server part only needs to care about the negotiation mechanisms it > > allows, i.e. GNOME will only have dbus/portal, sway will only have... dunn
Re: RFC: libei - emulated input in Wayland compositors
On Fri, Jul 31, 2020 at 11:00:53AM +0300, Vlad Zahorodnii wrote: > Howdy, > > On 7/31/20 8:13 AM, Peter Hutterer wrote: > > I've been working on a new approach for allowing emulated input devices in > > Wayland. Or in short - how can we make xdotool and synergy work? And > > eventually replace them. > > ++, it would be nice to have something that is supported by all major > compositors + working synergy on Wayland. :-) > > > The proposal I have is a library for Emulated Input, in short libei. > > https://gitlab.freedesktop.org/whot/libei/ > > > > libei has two parts, the client side (libei) for applications and > > a server side (libeis) for the compositor. The two libraries communicate > > with each other (how? doesn't matter, it's an implementation detail) to > > negotiate input devices. > > > > The process is roughly: > > - the libei client connects and says "I am org.freedesktop.SomeApplication > > and I want a pointer and a keyboard device" > > - the libeis server says "ok, you can have a pointer device and a keyboard > > device" > > - the libei client says 'move the pointer by 1/1', etc. and the server does > > just that. or not, depending on context. > > > > There are more details, see the README in the repo and the libei.h and > > libeis.h header files that describe the API. > > > > The sticking point here is: emulated input comes via a separate channel. > > The server a) knows it's emulated input, b) knows who it is coming from and > > c) has complete control over the input. > > > > a) is interesting because you can differ between the events internally. The > > API right now is very similar to libinput's events so integrating it into a > > compositor should be trivial. > > > > b) is somewhat handwavy if an application runs outside a sandbox - any > > information will be unreliable. Flatpak gives you an app-id though and > > with that we can (eventually) do things like storing the allow/deny > > decisions of the user in the portal implementation. > > > > c) allows you to e.g. suspend the client when convenient or just ignore > > certain sequences altogether. The two made-up examples are: suspend EI > > during a password prompt, or allow EI from the software yubikey *only* > > during a password prompt. > > We don't want any application be able to inject input events. How should > a program such as synergy authenticate itself? or is it completely up to > the compositor to decide what the authentication process looks like? The currently available method for application authenticaion is using portals from an application sandbox. The portal will know from what application a request to open a channel comes from without having to trust the application to tell the truth, and provide user facing ways for potentially limiting access. In other words, it'd be blocked before ever reaching the display server would so be needed. What this proposal aims is to create is (among other things) a portal (i.e. an API on org.freedesktop.portal.*) that does this. Other ways would be to make it slightly harder for applications to get access, e.g. only provide a socket name to certain ones, but that'd rely on trusting applications not to try bad things, and may have other limitations. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
On Wed, Apr 22, 2020 at 04:34:01PM -0400, Ray Strode wrote: > Hi, > > On Tue, Apr 21, 2020 at 8:21 AM Benjamin Berg wrote: > > Yes, I agree that "user" is very similar. However, it cannot currently > > convey any information about whether a graphical session is already > > running or whether it is capable of spanning multiple logind sessions. > why does that information need to be conveyed? who would consume it? > > > > I don't think gnome-session needs to do much beyond what it's already > > > doing. It just needs to make sure systemd is told what services to > > > start, if they aren't already started (which target to reach) > > Well, you need some mechanism to attach the new session/seat to the > > running graphical session and then watch for it to be released again > > And yes, the session leader process could be the one taking care of > > that. > So to be clear, I've been advocating for mutter/gnome-shell to do the > attaching *themselves*. We don't need any new api for them to do > that. > > If mutter is already running, it just needs to set up a sd_login_monitor > to detect when a new session for the user show up. As soon as a > new session is registered with logind, that new session is announced. > > mutter can then check the session type of the newly registered session > and see if it needs to add a new output (to e.g. pipewire or to kms). > > This can be done using api that exists today (well we need a new > session type, right now there's only tty, x11, wayland, mir, unspecified, > we need pipewire too) Can't the remote login session still be "wayland", but without being able to be drm master? We still need API to manage the pipewire streams (add/remove/change virtual outputs, inject input, i.e. something like org.gnome.Mutter.RemoteDesktop/ScreenCast); would adding a new session type bring us anything useful? We wouldn't just implicitly spit out a pipewire stream for some made up output, I assume we still want it to be managed some how by the remote desktop service. Jonas > > > But, the other part of this is that the situation is confusing. Right > > now we assign "user" processes to one of the logind sessions by doing a > > best guess. That works great as long as the user has one graphical > > logind session. But, if this graphical session starts spanning multiple > > logind sessions, then the choice becomes more relevant as each of the > > sessions might for example have a different "Active" state. > Right, mutter shouldn't be guessing which session to use. it should use > all of them! it may use some logic to figure out where window go (e.g, > last that went active wins), but all active sessions should get chrome. > > > So, having something that represents the combination of all of them > > could bypass that problem in an elegant way. We would never need to > > "guess" the session, we would just always return the combined "user" > > session. This user session would for example be considered "Active" as > > lone as any of the underlying logind sessions are active. > Totally agree with these words, but I also think that's precisely what a > "user" is in logind. i don't see any advantage to having something between > user and session that's basically the same as user. > > > Sorry, I meant the desktop here. > ah okay. > > > So if KDE and GNOME have incompatible > > implementation then we may run into odd error scenarios should the user > > try to change the session type while they are logged in already. > You're saying a user wants to log into KDE on X11 and GNOME on wayland > at the same time, and both use systemd --user? > > First, I think that's a fairly niche use case that cause problems for the user > (e.g., what if they try to run firefox in both?) > > But I don't think there's anything that would prevent it from working. > > logind lets a display server query whether or not a session is KDE or GNOME. > See sd_session_get_desktop . Each display server, should clearly only > manage sessions registered for their own desktop. > > > > > 3. we would likely get different implementations with varying degree > > > > of brokenness. > > > Not sure what you're saying here, can you reiterate? > > I think the above captures it well enough. > I still don't understand. Is this in the context of KDE and GNOME ? > > --Ray > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
On Wed, Apr 08, 2020 at 11:17:14AM -0700, Erik Jensen wrote: > On Wed, Apr 8, 2020 at 2:02 AM Jonas Ådahl wrote: > > Either multiple separate units (e.g. GDM and Chrome Remote Desktop login > > manager) needs to both try to manage the same sessions via logind, which > > sounds fragile and unlikely to be able to cope with the various security > > policies mentioned above; or an session management API, using the D-Bus > > system bus, needs to be added and implemented by the relevant display > > managers. This API would need to handle things like opening headless > > sessions without making them DRM master; handing over control of a > > headless session if the session is supposed to be turned into a local > > one, then hand it back etc, with all the various policy related to e.g. > > when to show the lock screen or not taken into account. > > It sounds like this would require a few new pieces: > * The session management API you mentioned for coordinating sessions. > * Compositor support for launching without DRM master. > * Compositor support for offscreen rendering when DRM master is > revoked. (Presumably grant and revocation of DRM master is already > handled due to VT switching? Do any compositors already support this > if there's an ongoing PipeWire capture when they are put in the > background?) DRM master and input device revocation should be handled more or less already by most if not all compositors, by closing devices, by then going dorment until access is returned to the compositor. I don't know if there is any compositor that can already handle continuing it's session headless with an active PipeWire stream. > * A solution for input injection. > > A remote desktop tool like Chrome Remote Desktop would then be > responsible for using the new API to launch a new session without DRM > master or revoke DRM master from an existing session (presumably > returning the local display to the login screen), and then connecting > to the appropriate Wayland session to initiate video capture and input > injection. > > Does that accurately reflect your suggested solution? More or less, yes. Launching sessions without DRM master and going headless is probably things we can add capability fields for in the session .desktop files, and show dialogs like "Wait" or "Terminate session" if a conflict appears (as mentioned in the linked GDM bug). All of this would also not need be specific to a certain windowing system, so that you we can use the same APIs for handling both Wayland sessions, X11 sessions, and whatever more types that may eventually appear. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
Even if that's what was done, you need to be careful to not diminish the > potential efficiency advantages we get by using KMS ourselves, which mostly > involves hardware overlay planes. > > The nested compositor needs to be capable of using wl_subsurfaces and > interfaces like wp_viewporter to at least give the parent compositor the > opportunity to use overlays, and I'm not aware of any nested compositor that > currently does that. > > It also gets more complex when you want to start talking about extra KMS > features like variable refresh rate, which the nested compositor ideally > wants to know about and have control over in this situation. I agree that going down the nested compositor path is not feasible. Display servers will most likely want to continue to work directly on top of KMS and libinput, and not use a proxy compositor. > > --- > > An alternative solution is to try and do some of this stuff in logind. > > logind does half of this work already in a sense, and AFAIK every compositor > is capable of using it, including Xorg. It controls access to KMS and input > devices, and can grant/revoke access to them at will. It doesn't do anything > graphical, instead leaving it to the compositor and display manager; it's > merely resource management and allows us to run as the user instead of as > root. > > Just as a quick overview, there are 'seats' and 'sessions'. > > - A seat is basically the representation of at least one GPU and some input > devices; the place the user sits at the computer. There is usually only one, > but multiple is possible. > > - A session is an instance of the user "logging in". It may or may not be > attached to a seat, but the no seat case is not interesting here; it's > currently used for SSH logins. If a session is the active session on a seat, > we get access to the devices for that seat. If it's not (e.g. VT switched > away), we don't. > > Perhaps logind could be extended to provide some extra way to enforce > external policy and help with your goals, instead of coming up with > something completely original. E.g. if you don't want something being > displayed on the monitor, you make the session non-active on its seat. > > With seamlessly switching sessions between local and remote, that's a bit > trickier. The compositor needs to be able to switch between KMS and > off-screen rendering, passing that off-screen rendering to something else > (e.g. Pipewire), as well as having input-injection. Some input-injection > things have been discussed before, but I personally haven't been keeping up > with it. Switching between local and virtual is FWIW what is the plan for how GNOME intends to handle cases like this. Not only for headless sessions, but for switching the monitor of an active session to output e.g. via Miracast[0]. > > wlroots is flexible enough (in theory) to allow for that, but I don't know > the software architecture of other compositors and how easy it is for them. Lets say the ultimate goal is being able to log in remotely after boot, then continue locally at a later point. Multiple isolated and separated general purpose sessions has fundamental flaws, as discussed above, so lets ignore that for a bit. Lets assume that compositors will continue to access KMS directly, and that there will be no system compositor that acts as a proxy for session compositors. Lets also assume we have a way to get the pixel content from the compositor into the remote desktop service and input back into the compositor (e.g. via PipeWire, etc.), the complex issues left to is not related to Wayland at all, but with display manager and logind integration. Either multiple separate units (e.g. GDM and Chrome Remote Desktop login manager) needs to both try to manage the same sessions via logind, which sounds fragile and unlikely to be able to cope with the various security policies mentioned above; or an session management API, using the D-Bus system bus, needs to be added and implemented by the relevant display managers. This API would need to handle things like opening headless sessions without making them DRM master; handing over control of a headless session if the session is supposed to be turned into a local one, then hand it back etc, with all the various policy related to e.g. when to show the lock screen or not taken into account. I think this is a discussion that primarily needs to be held with the display manager developers, as in those is where things need to be tied together. Jonas [0] https://github.com/benzea/gnome-network-displays > > That's my two cents. > > Scott > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
all on another thread/process may occur at any time. As we move > > > > to more and more multi-threaded programming this synchronization (on > > > > the client-side especially) becomes more and more painful. > > > > > > > > > > > > ## Current status in Linux > > > > > > > > Implicit synchronization in Linux works via a the kernel's internal > > > > dma_buf and dma_fence data structures. A dma_fence is a tiny object > > > > which represents the "done" status for some bit of work. Typically, > > > > dma_fences are created as a by-product of someone submitting some bit > > > > of work (say, 3D rendering) to the kernel. The dma_buf object has a > > > > set of dma_fences on it representing shared (read) and exclusive > > > > (write) access to the object. When work is submitted which, for > > > > instance renders to the dma_buf, it's queued waiting on all the fences > > > > on the dma_buf and and a dma_fence is created representing the end of > > > > said rendering work and it's installed as the dma_buf's exclusive > > > > fence. This way, the kernel can manage all its internal queues (3D > > > > rendering, display, video encode, etc.) and know which things to > > > > submit in what order. > > > > > > > > For the last few years, we've had sync_file in the kernel and it's > > > > plumbed into some drivers. A sync_file is just a wrapper around a > > > > single dma_fence. A sync_file is typically created as a by-product of > > > > submitting work (3D, compute, etc.) to the kernel and is signaled when > > > > that work completes. When a sync_file is created, it is guaranteed by > > > > the kernel that it will become signaled in finite time and, once it's > > > > signaled, it remains signaled for the rest of time. A sync_file is > > > > represented in UAPIs as a file descriptor and can be used with normal > > > > file APIs such as dup(). It can be passed into another UAPI which > > > > does some bit of queue'd work and the submitted work will wait for the > > > > sync_file to be triggered before executing. A sync_file also supports > > > > poll() if you want to wait on it manually. > > > > > > > > Unfortunately, sync_file is not broadly used and not all kernel GPU > > > > drivers support it. Here's a very quick overview of my understanding > > > > of the status of various components (I don't know the status of > > > > anything in the media world): > > > > > > > > - Vulkan: Explicit synchronization all the way but we have to go > > > > implicit as soon as we interact with a window-system. Vulkan has APIs > > > > to import/export sync_files to/from it's VkSemaphore and VkFence > > > > synchronization primitives. > > > > - OpenGL: Implicit all the way. There are some EGL extensions to > > > > enable some forms of explicit sync via sync_file but OpenGL itself is > > > > still implicit. > > > > - Wayland: Currently depends on implicit sync in the kernel (accessed > > > > via EGL/OpenGL). There is an unstable extension to allow passing > > > > sync_files around but it's questionable how useful it is right now > > > > (more on that later). > > > > - X11: With present, it has these "explicit" fence objects but > > > > they're always a shmfence which lets the X server and client do a > > > > userspace CPU-side hand-off without going over the socket (and > > > > round-tripping through the kernel). However, the only thing that > > > > fence does is order the OpenGL API calls in the client and server and > > > > the real synchronization is still implicit. > > > > - linux/i915/gem: Fully supports using sync_file or syncobj for > > > > explicit sync. > > > > - linux/amdgpu: Supports sync_file and syncobj but it still > > > > implicitly syncs sometimes due to it's internal memory residency > > > > handling which can lead to over-synchronization. > > > > - KMS: Implicit sync all the way. There are no KMS APIs which take > > > > explicit sync primitives. > > > > > > Correction: Apparently, I missed some things. If you use atomic, KMS > > > does have explicit in- and out-fences. Non-atomic users (e.g. X11) > > > are still in trouble but most Wayland compo
[ANNOUNCE] wayland-protocols 1.20
wayland-protocols 1.20 is now available. This release is a brown paper bag release adding the missing README.md, GOVERNANCE.md and MEMBERS.md files to the tarball. Distributions that distribute one or more of these files should ignore the 1.19 release and move directly to 1.20. Jonas Ådahl (2): Makefile.am: Also distribute README.md, GOVERNANCE.md and MEMBERS.md configure.ac: Bump version to 1.20 git tag: 1.20 http://wayland.freedesktop.org/releases/wayland-protocols-1.20.tar.xz MD5: b0836533a3f2dc6585b1dae00341157f wayland-protocols-1.20.tar.xz SHA1: e78c739a3a85477ed524b81e8bb75efe7f8bf4df wayland-protocols-1.20.tar.xz SHA256: 9782b7a1a863d82d7c92478497d13c758f52e7da4f197aa16443f73de77e4de7 wayland-protocols-1.20.tar.xz PGP: http://wayland.freedesktop.org/releases/wayland-protocols-1.20.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] wayland-protocols 1.19
wayland-protocols 1.19 is now available. This release is the first to include the new governance document, describing how to introduce and update Wayland protocols in wayland-protocols. See the GOVERNANCE.md file for details. This release also includes a new xdg-shell protocol that adds support for repositioning already mapped popups. Methods of doing so with inter-surface synchronization has been left out, with the intention of addressing this with a protocol at a lower level. Both the presentation time and xdg-shell protocol also got new attributes added meaning bindings using the enum and bitfield attributes will generate better result. Ivan Molodetskikh (2): presentation-time: add missing bitfield marker xdg-shell: add missing enum attribute to resize Johan Klokkhammer Helsing (1): Update point-of-contact for Qt Jonas Ådahl (4): xdg-shell: Remove left-over paragraph from pre positioner versions xdg-shell: Add support for implicit popup repositioning xdg-shell: Add support for explicit popup repositioning configure.ac: Bump version to 1.19 Simon Ser (5): Add governance document Add .editorconfig readme: changes should be submitted via GitLab Add .gitlab-ci.yml Convert plaintext documents to Markdown git tag: 1.19 http://wayland.freedesktop.org/releases/wayland-protocols-1.19.tar.xz MD5: 95817e531928405134be2ce5a0163548 wayland-protocols-1.19.tar.xz SHA1: 67d0f54050fe403f3bfe9b5a87b2aa6982863963 wayland-protocols-1.19.tar.xz SHA256: c09e03178499faa427689662a2422c6dcaf837654fdb346dc985733dec53f002 wayland-protocols-1.19.tar.xz PGP: http://wayland.freedesktop.org/releases/wayland-protocols-1.19.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Batching text input protocol changes
On Tue, Feb 18, 2020 at 04:14:50PM +0100, Dorota Czaplejewicz wrote: > On Tue, 18 Feb 2020 10:12:11 +0200 > Pekka Paalanen wrote: > > > On Mon, 17 Feb 2020 19:58:43 +0100 > > Dorota Czaplejewicz wrote: > > > > > Hi all, > > > > > > over the past month, the zwp_text_input_v3 protocol has moved to real > > > devices and had seen unprecedented usage. Together with that, it also > > > got a reality check, from which it didn't come unscathed. There are > > > some issues identified: > > > > > > - a hint that there's no need for an on-screen keyboard > > > - allow deleting text even when surrounding text is unknown > > > - making it harder for compositors to send uninformed updates > > > https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests/16 > > > - possibly graceful switching within text inputs > > > https://gitlab.gnome.org/GNOME/gtk/issues/2437 > > > - sending control events (submit, next field, undo) to gain > > > independence from a virtual keyboard protocol > > > > > > I might have left something out. > > > > > > Since they are all relatively unrelated, they can thankfully be > > > discussed separately. But merging them in separately would create > > > needlessly many combinations of possible supported versions. > > > > > > A new integration branch on gitlab would keep related merge requests > > > on the wayland-protocols repo, and it could be merged as one large > > > update once it's sufficiently hardened. Or is there another way to do > > > this? > > > > Hi Dorota, > > > > sounds like you have a good reason to have an upstream branch like > > that, so that the work in progress won't stop the master branch from > > releasing. I would be fine with that. > > > > Another way could be to start a new major version XML file, and exclude > > it from install by default. No-one could use it until you make it > > installable, so there would be no need to maintain implementations of > > the intermediate steps. > > > > Mind the wayland-protocols governance rules. > > > > > > Thanks, > > pq > > Hi, > > seeing the answers so far, I think starting a new branch is a good idea. In > case there are major changes, a new major version could be created out of the > new branch anyway. > > Currently, there's only one change that's important and potentially > backwards-incompatible, but that depends on the future discussion (deleting > text being broke), so a new version might not be necessary yet. > > Could someone with the permissions create such a branch? I created a branch called `wip/text-input-next`: https://gitlab.freedesktop.org/wayland/wayland-protocols/commits/wip/text-input-next Jonas > > Thanks, > Dorota > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Batching text input protocol changes
On Tue, Feb 18, 2020 at 10:12:11AM +0200, Pekka Paalanen wrote: > On Mon, 17 Feb 2020 19:58:43 +0100 > Dorota Czaplejewicz wrote: > > > Hi all, > > > > over the past month, the zwp_text_input_v3 protocol has moved to real > > devices and had seen unprecedented usage. Together with that, it also > > got a reality check, from which it didn't come unscathed. There are > > some issues identified: > > > > - a hint that there's no need for an on-screen keyboard > > - allow deleting text even when surrounding text is unknown > > - making it harder for compositors to send uninformed updates > > https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests/16 > > - possibly graceful switching within text inputs > > https://gitlab.gnome.org/GNOME/gtk/issues/2437 > > - sending control events (submit, next field, undo) to gain > > independence from a virtual keyboard protocol > > > > I might have left something out. > > > > Since they are all relatively unrelated, they can thankfully be > > discussed separately. But merging them in separately would create > > needlessly many combinations of possible supported versions. > > > > A new integration branch on gitlab would keep related merge requests > > on the wayland-protocols repo, and it could be merged as one large > > update once it's sufficiently hardened. Or is there another way to do > > this? > > Hi Dorota, > > sounds like you have a good reason to have an upstream branch like > that, so that the work in progress won't stop the master branch from > releasing. I would be fine with that. > > Another way could be to start a new major version XML file, and exclude > it from install by default. No-one could use it until you make it > installable, so there would be no need to maintain implementations of > the intermediate steps. Note that some users of wayland-protocols don't use the installed version, but manage wayland-protocols as a git submodule, thus just not installing would not be good enough for that. Also, if these additions are going to introduce a version 2 of the text-input unstable v3, it'd be awkward to keep the changes in a dummy file until merged back into the actual one. Thus, I think using a branch until the new version is settled is the best option here. You could still use merge requests, just that you target a 'wip/text-input-v3.2' branch we create instead of the master branch. Jonas > > Mind the wayland-protocols governance rules. > > > Thanks, > pq > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wl_output physical size when unknown
On Mon, Jan 13, 2020 at 05:14:28PM +, David Edmundson wrote: > I need to patch either a client toolkit or a compositor and I'm not sure > which. > > There are some cases where we don't have a physical size for an output. > For example projectors or headless virtual machines, > > Currently we (kwin) can send a physical size of 0,0 which is causing > some client issues which are calculating us as having 0 dots per inch > and doing something wrong. > > Should: > a) Compositors should generate something fake but sensible > b) Clients should handle this case > > I think there's a strong argument for either. What are others doing? The answer is b). See the specification for wl_output::geometry: The physical size can be set to zero if it doesn't make sense for this output (e.g. for projectors or virtual outputs). Jonas > > David > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: zwp_fullscreen_shell_v1
On Wed, Jan 08, 2020 at 10:11:40AM +, Alan Griffiths wrote: > On 08/01/2020 10:01, Jonas Ådahl wrote: > > This idea has more or less been abandoned however, so I'd say it's more > > likely we can "archive" it rather than marking it as stable, as there > > are as far as I know no real users of it. > > Thanks for that > > > For kiosk mode, you still probably want to use xdg-shell, as it's not > > unlikely the kiosk application still wants to use things like popup > > surfaces for drop down menus etc. Your compositor can, when in kiosk > > mode, for example only allow one client, with only a single toplevel, > > that is always configured as fullscreen. > > Yes, we do that already. I was looking for an approach that also allows > the app to configure, for example, the screen resolution. You could effectively achieve that by letting the application use the viewport extension to scale the surface in any way it sees fit; your compositor can then set the most appropriate resolution according to the actual surface dimensions. Jonas > > Alan > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: zwp_fullscreen_shell_v1
On Wed, Jan 08, 2020 at 09:46:13AM +, Alan Griffiths wrote: > Hi, > > with Mir's "mir-kiosk" being deployed for running single, fullscreen > apps there are requests for ways that the apps can control the output > mode. Looking at zwp_fullscreen_shell_v1 this appears to meet many of > these requirements. However, it is "unstable" and I don't see evidence > of it being widely used. > > So, what is the status of this extension protocol? Is it mostly > forgotten? Or just waiting for a final push to stable? The use case in mind when the fullscreen shell was written was making it possible for compositors to outsource KMS and evdev integration to a parent compositor, making it possible to write a compositor with only a Wayland backend, then using e.g. weston and its fullscreen shell implementation to make it possible to run seemingly native. Input would be routed as regular wl_pointer, wl_keyboard events etc, and things like plane assignment would be done by having the nested compositor use subsurfaces. This idea has more or less been abandoned however, so I'd say it's more likely we can "archive" it rather than marking it as stable, as there are as far as I know no real users of it. For kiosk mode, you still probably want to use xdg-shell, as it's not unlikely the kiosk application still wants to use things like popup surfaces for drop down menus etc. Your compositor can, when in kiosk mode, for example only allow one client, with only a single toplevel, that is always configured as fullscreen. Jonas > > Thanks, > Alan > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libwayland surface coordinate question
On Thu, Nov 21, 2019 at 07:17:11PM -0800, Ken C wrote:
> That is going to be it. The client happens to be a minimal gtk3 app.
> Thank-you so much for the pointer towards
> weston_desktop_surface_get_geometry().
FWIW, you should be able to make the gtk3 application not include any
pixels outside the window geometry by making it maximized. You should be
able to accomplish this by calling
weston_desktop_surface_set_maximized() with true on the corresponding
desktop surface instance.
Jonas
>
>
> On Thu, Nov 21, 2019 at 5:52 PM Scott Anderson
> wrote:
> >
> > On 22/11/19 2:40 pm, Ken C wrote:
> > > I am just starting out with libweston and have a beginner question
> > > regarding surface/view coordinates. I am looking to implement
> > > something along the lines of issue #277 on gitlab[1], "New shell
> > > plugin for single-app usecases". I have swapped out
> > > weston-desktop-shell with a toy client just to get grounded, and am
> > > using the X11 and RDP backends for testing. I can see where the
> > > initial client position gets set up in
> > > weston_view_set_initial_position() in shell.c. However I am finding
> > > that even if weston_view_set_position() is called with {0,0}, the
> > > resulting window on output is offset by ~32ish pixels. I've also
> > > started from westiny[2], which is about as simple as it gets, but find
> > > the same mysterious (to me) offset. I can set the initial position to
> > > a negative x,y value in weston_view_set_initial_position(), forcing
> > > the window into the corner. Maximizing the toy client interestingly
> > > enough fills the screen (a single head).
> > >
> > > I've looked high and low for where that ~32 pixel offset comes from,
> > > but have not had luck. While I look some more maybe someone has a
> > > quick pointer. If I can set a breakpoint I'm sure it will become
> > > obvious.
> > >
> > > [1] https://gitlab.freedesktop.org/wayland/weston/issues/277
> > > [2] https://gitlab.freedesktop.org/daniels/westiny/blob/master/westiny.c
> >
> > Hi,
> >
> > It may be because of the client's "window geometry"[1]. There may be
> > some drop shadows or otherwise transparent border around the client's
> > contents, and the window geometry will tell you which part of the
> > surface you should consider to be the client's contents.
> >
> > If you'll excuse the terrible ASCII drawing:
> >
> > (0,0)
> > +---+ <--- Surface
> > | (32,32) |
> > | +-+<--- Geometry
> > | | |# |
> > | | |# |
> > | | |# |
> > | +-+# |
> > | |
> > +---+
> >
> > When a client is maximized or fullscreened, they're asked to not draw
> > these kinds of things, and should fill the entire surface with their
> > window's contents.
> >
> > weston_desktop_surface_get_geometry is the function you call to get this
> > information.
> >
> > Scott
> >
> >
> > [1]:
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/blob/master/stable/xdg-shell/xdg-shell.xml#L445-476
> >
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add governance document
On Fri, Nov 15, 2019 at 12:10:58AM +, Simon Ser wrote: > The idea of a better-defined governance model for wayland-protocols has > been discussed for quite a while [1]. > > A new GOVERNANCE document describes how changes to the wayland-protocols > repository are accepted. A set of members representing projects can vote > on merge requests sent via GitLab. The initial list of members is > available in the MEMBERS file. > > [1]: > https://lists.freedesktop.org/archives/wayland-devel/2019-February/040076.html > > Signed-off-by: Drew DeVault > Signed-off-by: Simon Ser > Acked-by: Daniel Stone > Acked-by: Pekka Paalanen > Acked-by: Johan Helsing > Acked-by: Roman Gilg > Cc: Mike Blumenkrantz > Cc: Jonas Ådahl > Cc: Carlos Garnacho > Cc: David Edmundson > Cc: Christopher James Halse Rogers > Cc: Alan Griffiths Acked-by: Jonas Ådahl Jonas > --- > GOVERNANCE | 149 + > MEMBERS| 11 > 2 files changed, 160 insertions(+) > create mode 100644 GOVERNANCE > create mode 100644 MEMBERS > > diff --git a/GOVERNANCE b/GOVERNANCE > new file mode 100644 > index ..912ae5bb8808 > --- /dev/null > +++ b/GOVERNANCE > @@ -0,0 +1,149 @@ > + wayland-protocols governance > + > +This document governs the maintenance of wayland-protocols and serves to > outline > +the broader process for standardization of protocol extensions in the Wayland > +ecosystem. > + > + 1. Membership > + > +Membership in wayland-protocols is offered to stakeholders in the Wayland > +ecosystem who have an interest in participating in protocol extension > +standardization. > + > + 1.1. Membership requirements > + > +a. Membership is extended to projects, rather than individuals. > +b. Members represent general-purpose projects with a stake in multiple > Wayland > + protocols (e.g. compositors, GUI toolkits, etc), rather than > special-purpose > + applications with a stake in only one or two. > +c. Each project must provide one or two named individuals as > points-of-contact > + for that project who can be reached to discuss protocol-related matters. > +d. During a vote, if two points-of-contact for the same member disagree, the > + member's vote is considered blank. > + > + 1.2. Becoming a member > + > +a. New members who meet the criteria outlined in 1.1 are established by > + invitation from an existing member. Projects hoping to join should reach > out > + to an existing member asking for this invitation. > +b. New members shall write to the wayland-devel mailing list stating their > + intention of joining and their sponsor. > +c. The sponsor shall respond acknowledging their sponsorship of the > membership. > +d. A 14 day discussion period for comments from wayland-protocols members > will > + be held. > +e. At the conclusion of the discussion period, the new membership is > established > + unless their application was NACKed by a 1/2 majority of all existing > members. > + > +1.3. Ceasing membership > + > +a. A member may step down by writing their intention to do so to the > + wayland-devel mailing list. > +b. A removal vote may be called for by an existing member by posting to the > + wayland-devel mailing list. This begins a 14 day voting & discussion > + period. > +c. At the conclusion of the voting period, the member is removed if the votes > + total 2/3rds of all current members. > +d. Removed members are not eligible to apply for membership again for a > period > + of 1 year. > +e. Following a failed vote, the member who called for the vote cannot > + call for a re-vote or propose any other removal for 90 days. > + > + 2. Protocols > + > +2.1. Protocol namespaces > + > +a. Namespaces are implemented in practice by prefixing each interface name > in a > + protocol definition (XML) with the namespace name, and an underscore (e.g. > + "xdg_wm_base"). > +b. Protocols in a namespace may optionally use the namespace followed by a > dash > + in the name (e.g. "xdg-shell"). > +c. The "xdg" namespace is established for protocols letting clients > + configure its surfaces as "windows", allowing clients to affect how they > + are managed. > +d. The "wp" namespace is established for protocols generally useful to > Wayland > + implementations (i.e. "plumbing" protocols). > +e. The "ext" namespace i
Re: wayland-protocols scope and governance
On Tue, Nov 12, 2019 at 08:13:58PM +, Daniel Stone wrote: > Hi, > > On Thu, 10 Oct 2019 at 16:12, Simon Ser wrote: > > This document governs the maintenance of wayland-protocols and serves to > > outline > > the broader process for standardization of protocol extensions in the > > Wayland > > ecosystem. > > OK, we're approaching the nine-month anniversary of this discussion. I > think it would be good to merge it before it would've been born. > > We seem to have a unanimous set of agreed-upon initial members with > defined points of contact (listed below). : EFL, Enlightenment, GTK, > KWin, Mutter, Qt, Weston, wlroots (also as a proxy for the wider > phosh/Sway/way-cooler/etc projects using wlroots). > > I think there's a good case to be made for adding Chromium/Exosphere > to the list, since they are actively involved in protocol development > and a few of their protocols have already found their way upstream. > Other major users include GStreamer, Kodi, and VLC, but it doesn't > seem like they participate too much in protocol development, and it's > not clear to me whether or not they'd want to be involved. I don't > have a strong opinion on whether or not they should be in the > membership group. Similarly, you could add Firefox and perhaps even > Mesa to that list; I remember others suggesting GLFW, SDL, maybe even > imgui, mpv? > > I would suggest that we push the patch with the following initial > member projects and their points of contact defined, and finally > enable MRs: > * EFL/Enlightenment: Mike Blumenkrantz @zmike > * GTK/Mutter: Jonas Ådahl @jadahl I'd like to add Carlos Garnacho @garnacho here as well as an additional point of contact. Jonas > * KWin: Roman Gilg @romangg > * Qt: Johan Helsing @johanhelsing > * Weston: Daniel Stone @daniels, Pekka Paalanen @pq > * wlroots (& its users): Drew DeVault @ddevault, Simon Ser @emersion > > If we find interest from other projects, we can use their membership > applications as a first test of our governance procedures. > > Cheers, > Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Getting a compositor display name?
On Wed, Nov 13, 2019 at 11:00:05AM +, Simon Ser wrote: > On Wednesday, November 13, 2019 11:11 AM, Pekka Paalanen > wrote: > > > However, my fear with adding such information is that then clients > > might start adding conditional code paths based on the Wayland > > compositor name or version, which is an incorrect approach. Client > > behaviour that depends on the particular compositor must be keyed by > > the available global Wayland interfaces and their versions, not by the > > compositor identity. > > > > OTOH, Wayland is a few years old by now and developers should have > > learnt better, so maybe that fear is no longer relevant. > > I share this fear as well. IMHO `ps` is good enough. You could > also use something like `lsof /dev/dri/card0` to get the DRM > master. There is also $XDG_CURRENT_DESKTOP specified in the desktop-entry-spec[0]. Jonas [0] https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wl_subsurace position - double buffered state?
On Tue, Oct 29, 2019 at 10:41:08PM +0100, Martin Stransky wrote: > Hi Guys, > > while solving a FF bug [1] I'm unable to figure out why a subsurface has > wrong offset. There's the related part of wayland-debug log: > > [1622539.791] -> wl_compositor@53.create_surface(new id wl_surface@61) > > [1622539.821] -> wl_subcompositor@57.get_subsurface(new id > wl_subsurface@62, wl_surface@61, wl_surface@42) > > gdk_window_get_position 26 23 > > [1622539.857] -> wl_subsurface@62.set_position(26, 23) > > [1622539.868] -> wl_subsurface@62.set_desync() > > [1622539.874] -> wl_compositor@53.create_region(new id wl_region@63) > > [1622539.882] -> wl_surface@61.set_input_region(wl_region@63) > > [1622539.889] -> wl_region@63.destroy() > > [1622539.904] -> wl_surface@61.set_buffer_scale(2) > > [1622539.912] -> wl_surface@61.commit() > > > but I still see the sub surface on old initial position (0,0). It's moved to > correct position imediately when I try to resize the window. (full log is > attached). > > Sometimes it happens that the surface is on correct position right after > start - but I don't see any difference in the log. > > It's on Fedora 30 / mutter-3.32.2-4.fc30.x86_64. > > Any idea what can be wrong? Hi, Quoting the specification of the set_position request: The scheduled coordinates will take effect whenever the state of the parent surface is applied. When this happens depends on whether the parent surface is in synchronized mode or not. See wl_subsurface.set_sync and wl_subsurface.set_desync for details. In short, you need to commit the parent surface for the new position to take effect. The reason for this is that the position of the surface is more of a state of the parent surface rather than the subsurface itself, and it is likely that if you move the subsurface, something on the parent surface needs to be updated at the same time in order to avoid intermediate incorrectly rendered frames. Jonas > > Thanks, > Martin > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1592350 > > -- > Martin Stransky > Software Engineer / Red Hat, Inc > [1621949.941] -> wl_display@1.get_registry(new id wl_registry@2) > [1621950.003] -> wl_disp...@1.sync(new id wl_callback@3) > [1621950.163] wl_display@1.delete_id(3) > [1621950.182] wl_registry@2.global(1, "wl_drm", 2) > [1621950.206] wl_registry@2.global(2, "wl_compositor", 4) > [1621950.226] -> wl_regis...@2.bind(2, "wl_compositor", 3, new id > [unknown]@4) > [1621950.261] wl_registry@2.global(3, "wl_shm", 1) > [1621950.279] -> wl_regis...@2.bind(3, "wl_shm", 1, new id [unknown]@5) > [1621950.403] -> wl_shm@5.create_pool(new id wl_shm_pool@6, fd 12, 2304) > [1621950.638] -> wl_shm_pool@6.resize(6912) > [1621950.793] -> wl_shm_pool@6.resize(16128) > [1621951.043] -> wl_shm_pool@6.resize(34560) > [1621951.524] -> wl_shm_pool@6.resize(71424) > [1621954.076] -> wl_shm_pool@6.resize(145152) > [1621954.198] -> wl_shm_pool@6.resize(292608) > [1621955.727] -> wl_shm_pool@6.resize(587520) > [1621959.196] -> wl_shm_pool@6.resize(1177344) > [1621975.710] wl_registry@2.global(4, "wl_output", 2) > [1621975.733] -> wl_regis...@2.bind(4, "wl_output", 2, new id [unknown]@7) > [1621975.796] -> wl_disp...@1.sync(new id wl_callback@8) > [1621975.806] wl_registry@2.global(6, "zxdg_output_manager_v1", 1) > [1621975.817] -> wl_regis...@2.bind(6, "zxdg_output_manager_v1", 1, new id > [unknown]@9) > [1621975.831] -> zxdg_output_manager_v1@9.get_xdg_output(new id > zxdg_output_v1@10, wl_output@7) > [1621975.840] -> wl_disp...@1.sync(new id wl_callback@11) > [1621975.847] wl_registry@2.global(7, "wl_data_device_manager", 3) > [1621975.859] -> wl_regis...@2.bind(7, "wl_data_device_manager", 3, new id > [unknown]@12) > [1621975.872] wl_registry@2.global(8, "gtk_primary_selection_device_manager", > 1) > [1621975.882] -> wl_regis...@2.bind(8, > "gtk_primary_selection_device_manager", 1, new id [unknown]@13) > [1621975.896] wl_registry@2.global(9, "wl_subcompositor", 1) > [1621975.906] -> wl_regis...@2.bind(9, "wl_subcompositor", 1, new id > [unknown]@14) > [1621975.920] wl_registry@2.global(10, "xdg_wm_base", 2) > [1621975.930] wl_registry@2.global(11, "zxdg_shell_v6", 1) > [1621975.939] wl_registry@2.global(12, "wl_shell", 1) > [1621975.949] wl_registry@2.global(13, "gtk_shell1", 3) > [1621975.959] -> wl_regis...@2.bind(13, "
[PATCH wayland-protocols v2] xdg-shell: Add support for synchronized popup moving
This commit adds protocol additions making it possible to reposition an already mapped popup. Repositioning can be done in two ways: implicit and explicit. Implicit popup moving is done by setting a adjustment flag on the positioner used to create it that will cause the compositor to adjust the position as the conditions used to constrain it change. These changes may include, for example, changes in the position of the parent window or the geometry of the work area. To allow the client to update its content in response to the updated position, the client must ack the configure event, optionally with new content. Until the client acks this configure event, the existing positioner will continue to be used. Explicit popup moving is done using a new request on xdg_popup: xdg_popup.reposition. What it does is change the parameters used for positioning a popup by providing a new xdg_positioner object. This request is coupled with a new event; xdg_popup.repositioned, sent together with the configure events (xdg_popup.configure and xdg_surface.configure) to notify about the completion of the reposition request. The reposition request also takes a token that is later passed via the repositioned event; this is done so that a client may determine for which reposition request the compositor has sent configure events. Both these methods by themself are racy regarding inter-surface synchronization. In order to avoid race conditions when applying new states, a new request is also added to xdg_surface: xdg_surface.sync_with_popup. This request is a one-shot request to defer application of the to be committed surface state until the state of the passed popup surface is applied. Lastly, a request to couple a xdg_positioner object with a configure event is added in order for a compositor to pair a popup reposition request with a pending configure event. This is necessary to, for example, properly constrain a popup given a yet-to-be-applied parent state. An example of when this may be necessary is an interactive resize where both the toplevel position and the relative popup position changes. Signed-off-by: Jonas Ådahl Reviewed-by: Mike Blumenkrantz --- Changes since v1: - Renamed move to reposition, and moved to repositioned, to not be confused with xdg_toplevel.move. (David) - Added invalid_popup error sent sync_with_popup() is passed an invalid popup. - Clarify that multiple calls to sync_with_popup() is accumulacitve. Jonas stable/xdg-shell/xdg-shell.xml | 86 -- 1 file changed, 81 insertions(+), 5 deletions(-) diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml index 3a87a9e..3ee13de 100644 --- a/stable/xdg-shell/xdg-shell.xml +++ b/stable/xdg-shell/xdg-shell.xml @@ -29,7 +29,7 @@ DEALINGS IN THE SOFTWARE. - + The xdg_wm_base interface is exposed as a global object enabling clients to turn their wl_surfaces into windows in a desktop environment. It @@ -115,7 +115,7 @@ - + The xdg_positioner provides a collection of rules for the placement of a child surface relative to a parent surface. Rules can be defined to ensure @@ -357,9 +357,32 @@ + + + + + + When set reactive, the surface is reconstrained if the conditions used + for constraining changed, e.g. the parent window moved. + + When set reactive, an xdg_popup.configure event is sent with updated + geometry, followed by an xdg_surface.configure event, which will + reflect the newly-calculated constrained geometry for the popup. + + + + + + Set the serial of a xdg_surface.configure event this positioner will be + used in response to. The compositor can use this to make assumptions about + how the popup will be positioned on the next commit. + + + - + An interface that may be implemented by a wl_surface, for implementations that provide a desktop-style user interface. @@ -406,6 +429,7 @@ + @@ -526,9 +550,25 @@ + + + + + + Defer applying this surface's state until the state of the specified + xdg_popup surface is next applied. + + Repeatedly calling this method has no additional effect until after the + next commit. + + The direct parent of the popup must be this surface. If it is not, a + invalid_popup error is raised. + + + - + This interface defines an xdg_surface role which allows a surface to, among other things, set window-like properties such as maximize, @@ -1019,7 +1059,7 @@ - + A popup surface is a short-lived, temporary surface. It can be used to implement for example menus, popovers, tooltips and other similar user @@ -1143,5 +11
Re: [PATCH wayland-protocols] xdg-shell: Add support for synchronized popup moving
On Tue, Aug 27, 2019 at 11:47:25PM +0100, David Edmundson wrote: > set_reactive > > Everything about this part makes sense. > +1 > > > - > > move request + moved > > Concept of having explicit updating makes sense. > Might be worth considering calling it xdg_popup.reposition as > xdg_toplevel.move is very different "reposition" sounds like a good name, thanks! Maybe it should be "repositioned" too then. > > Would it be valid to re-use the same positioner object each time? I think so. A positioner is just a dump container of numbers and what not, and when it's used, the contents are copied. Whether the client want to reuse or destroy should be fine IMO. > > Could we repurpose wl_display.sync as an alternative for the moved > signal? Simply for code re-use. I don't think so; the sync is replied to immediately by libwayland-server, while a move may go through various hoops before being processed. > It slightly reverses the logic, but after your callback a client knows > it definitely has the latest configure event for your move request. The problem is consecutive reposition requests, where the compositor may ignore one if another came after. Tying it to the configure_ack serial helps dealing with all that. > > - > > sync_with_popup > > In example A > > --> xdg_toplevel.configure(200, 600) > --> xdg_popup_surface.configure(3) > <-- xdg_popup_surface.ack_configure(3) > <-- xdg_popup_surface.sync_with_popup(xdg_popup) > > Should this be xdg_toplevel_surface? Yes, indeed. Well spotted. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Sat, Sep 21, 2019 at 11:57:45PM -0400, Drew DeVault wrote: > On Thu Sep 19, 2019 at 9:02 PM Jonas Ådahl wrote: > > I think that if there is a consensus that it's within the correct scope > > and no-one nacks it, there shouldn't need be any artifical bureaucratic > > road blocks in the way. > > I mean, I'm not in any particular hurry to get any particular protocol > through the process. An implementation is a key part of the development > of a protocol and almost always reveals flaws in the protocol that a > human reading alone wouldn't. The difference between client and server > implementations can be similarly revealing, and it's nice to have more > people looking at a protocol with this degree of care. > > However, I agree with your reasoning that multiple clients and a single > compositor still creates a system of stakeholders which would benefit > from this process. What if we required the sum of implementations > (client or server) to be 3 or more? Seems to me like a better alternative. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Thu, Sep 19, 2019 at 02:10:24PM -0400, Drew DeVault wrote: > On Tue Sep 17, 2019 at 7:53 PM Jonas Ådahl wrote: > > I think both for stable and unstable the same limitation can be > > as problematic. A protocol that fits in xdg/wp may still only be > > relevant for a single compositor and multiple toolkits, or vice versa, > > even when declared stable. Seems to me like the wrong method to keep > > quality of wp/xdg protocols high. > > If a protocol is only useful for one compositor, I think that compositor > ought to manage the stability and governance of that protocol itself. If > there aren't multiple stakeholders who need to be kept happy, then why > is it even necessary to bring that protocol into shared governance? It's > up to the single stakeholder to make any promises towards stability or > design that they see fit with those who depend on them. Well there could be multiple stake holders - multiple client toolkits. Lets pretend there is only a single tiling compositor. Why would tiling protocols be restricted from becoming part of xdg_*? Or lets pretend only wlroots had any intention of implementing the server side of xdg_toplevel_decoration, why would it be excluded, when Qt, gtk, GLFW, SDL, ... would implement? I think that if there is a consensus that it's within the correct scope and no-one nacks it, there shouldn't need be any artifical bureaucratic road blocks in the way. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Tue, Sep 17, 2019 at 05:46:49PM +, Simon Ser wrote: > On Friday, September 6, 2019 10:45 AM, Jonas Ådahl wrote: > > > > 2.2. Protocol inclusion requirements > > > > > > > > > a. All protocols found in the "xdg" and "wp" namespaces at the time of > > > writing > > > are grandfathered into their respective namespace without further > > > discussion. > > > b. Protocols in the "xdg" and "wp" namespace are eligible for inclusion > > > only if > > > ACKed by at least 3 members. > > > c. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion > > > if > > > if NACKed by any member. > > > d. Protocols in the "xdg" and "wp" namespaces must have at least one > > > open-source > > > client implementation & two open-source server implementations to be > > > eligible > > > for inclusion. > > > > Maybe this was discussed in the past, but why two? If we'd travel back > > in time, it'd stall the introduction of xdg-foreign (took quite a while > > for a second server implementation to show up), which falls within the > > xdg namespace scope, and it'd block addition of protocols only > > interesting to a single compositor but multiple clients/toolkits (e.g. > > something very tiling specific that maybe only wlroots would care about, > > or something currently in gtk-shell that may be relevant for GNOME > > Shell, gtk and Qt, but not for other compositors). > > > > Same for protocols like the tablet interface; I think it's too much of a > > requirement to require the protocol author to provide TWO > > implementations for such a protocol, and relying on others to implement > > your protocol in their own compositors is quite a lot to ask IMHO. The > > end result is more likely we end up with more things like > > `gtk_primary_selection` instead of going upstream first. > > That's a very fair point. I think it would make sense to require more > implementations for unstable → stable upgrades (which are very > important, we can't fix those later). But for unstable protocols, you > do have a point. > > I guess the original intention was to make a difference between xdg/wp > inclusion and other namespaces: it should be harder to get a protocol > merged in xdg/wp. > > Thoughts? I think both for stable and unstable the same limitation can be as problematic. A protocol that fits in xdg/wp may still only be relevant for a single compositor and multiple toolkits, or vice versa, even when declared stable. Seems to me like the wrong method to keep quality of wp/xdg protocols high. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v6] unstable/drm-lease: DRM lease protocol support
On Fri, Sep 13, 2019 at 09:32:01AM -0400, Drew DeVault wrote: > On Thu Sep 12, 2019 at 2:42 PM Pekka Paalanen wrote: > > > This was resolved by choosing to have multiple drm_lease_manager > > > globals, one for each DRM device. No reworking should be necessary. > > > > in that case, document it in the XML please. > > ack > If one global corresponds to a single drm device, why not call it "_device" instead of "_manager"? Usually there is only one "manager" object, and it'd be confusing to have multiple manager objects without it being clear that it's per device. Being globals it's prone to race conditions as well (I'd expect to see leasable devices to come and go, especially with eGPU's being a thing). Then again, with wl_global_remove() it's not *that* bad. The alternative is to make the _manager object an actual manager object that has 'added' and 'removed' events with the "_device" containing the actual lease request. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Thu, Sep 05, 2019 at 09:34:59PM +, Simon Ser wrote: > This is v3 of the proposal. > > Changes from v2 to v3: > - Use Jonas' definition of the "xdg" namespace (Jonas) > - Amendments to existing protocols require no minimum discussion period > (Jonas) > - Specify the requirements for declaring a protocol stable (Jonas) > > Diff: https://sr.ht/lIEx.patch > > I'm not sure what you mean by this, Jonas: > > > The usage of a dash instead of underscore is what the name as well as > > file name should use. The underscore is for protocol interface, requests and > > events only. > > The current proposal already specifies this, what am I missing? Can't remember what I was referring to, but it looks correct in this version. > > Re: open-source server & client implementation: should we add a > requirement that maintainers ack the implementation? (Just like kernel > uAPI changes require) Not sure about this one. An implementation could very well be a thin wrapper around more complex infrastructure that would take a large effort to understand for someone not familiar with the code base. > > * * * > > wayland-protocols governance > > This document governs the maintenance of wayland-protocols and serves to > outline > the broader process for standardization of protocol extensions in the Wayland > ecosystem. > > 1. Membership > > Membership in wayland-protocols is offered to stakeholders in the Wayland > ecosystem who have an interest in participating in protocol extension > standardization. > > 1.1. Membership requirements > > a. Membership is extended to projects, rather than individuals. > b. Members represent general-purpose projects with a stake in multiple Wayland >protocols (e.g. compositors, GUI toolkits, etc), rather than > special-purpose >applications with a stake in only one or two. > c. Each project must provide one or two named individuals as points-of-contact >for that project who can be reached to discuss protocol-related matters. > > 1.2. Becoming a member > > a. New members who meet the criteria outlined in 1.1 are established by >invitation from an existing member. Projects hoping to join should reach > out >to an existing member asking for this invitation. > b. New members shall write to the wayland-devel mailing list stating their >intention of joining and their sponsor. > c. The sponsor shall respond acknowledging their sponsorship of the > membership. > d. A 14 day discussion period for comments from wayland-protocols members will >be held. > e. At the conclusion of the discussion period, the new membership is > established >unless their application was NACKed by a 1/2 majority of existing members. > > 1.3. Ceasing membership > > a. A member may step down by writing their intention to do so to the >wayland-devel mailing list. > b. A removal vote may be called for by an existing member by posting to the >wayland-devel mailing list. This begins a 14 day voting & discussion >period. > c. At the conclusion of the voting period, the member is removed if the votes >total 2/3rds of members. > d. Removed members are not eligible to apply for membership again for a period >of 1 year. > e. Following a failed vote, the member who called for the vote cannot >call for a re-vote or propose any other removal for 90 days. > > 2. Protocols > > 2.1. Protocol namespaces > > a. Namespaces are implemented in practice by prefixing each interface name in > a >protocol definition (XML) with the namespace name, and an underscore (e.g. >"xdg_wm_base"). > b. Protocols in a namespace may optionally use the namespace followed by a > dash >in the name (e.g. "xdg-shell"). > c. The "xdg" namespace is established for protocols letting clients >configure its surfaces as "windows", allowing clients to affect how they >are managed. > d. The "wp" namespace is established for protocols generally useful to Wayland >implementations (i.e. "plumbing" protocols). > e. The "ext" namespace is established as a general catch-all for protocols > that >fit into no other namespace. > > 2.2. Protocol inclusion requirements > > a. All protocols found in the "xdg" and "wp" namespaces at the time of writing >are grandfathered into their respective namespace without furthe
Re: [PATCH wayland-protocols] presentation-time: add missing bitfield marker
On Tue, Aug 20, 2019 at 10:48:40AM +, Simon Ser wrote: > That's a good catch. > > However I don't know if this can be considered backwards-compatible. > For wayland-scanner it doesn't make a difference, but what about other > scanners? I don't think it's reasonable to avoid using any new XML format features to protocols that was initially introduced early than those features; it should be required that scanners handle unknown attributes by ignoring them, just as wayland-scanner does when not passing --strict. Jonas > > The commit introducing bitfields in the DTD predates presentation-time. > > commit e65aed46168fc86a7e78db071472278ea533f526 > Author: Peter Hutterer > Date: Tue Nov 10 09:34:32 2015 +1000 > > protocol: add the new bitfields to the dtd > > See 851614fa78862499e016c5718e730fefbb8e3b73 > > commit 95e7f445edbc8ea52b6f4d22ae1ee514b2323895 > Author: Pekka Paalanen > Date: Wed Feb 17 16:32:05 2016 +0200 > > stable: add presentation-time draft > > This XML file has been copied verbatim from Weston 1.10.0 release, > protocol/presentation_timing.xml. The last behavioral change to that > file was in December 2014, so the behaviour is considered stable. > > Interfaces still need to be renamed according wayland-protocols policy. > That will be done in a follow-up patch to clearly show the changes. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols] xdg-shell: Add support for synchronized popup moving
This commit adds protocol additions making it possible to move an already mapped popup. Moving can be done in two ways: implicit and explicit. Implicit popup moving is done by setting a adjustment flag on the positioner used to create it that will cause the compositor to adjust the position as the conditions used to constrain it change. These changes may include, for example, changes in the position of the parent window or the geometry of the work area. To allow the client to update its content in response to the updated position, the client must ack the configure event, optionally with new content. Until the client acks this configure event, the existing positioner will continue to be used. Explicit popup moving is done using a new request on xdg_popup: xdg_popup.move. What it does is change the parameters used for positioning a popup by providing a new xdg_positioner object. This request is coupled with a new event; xdg_popup.moved, sent together with the configure events (xdg_popup.configure and xdg_surface.configure) to notify about the completion of the move request. The move request also takes a token that is later passed via the moved event; this is done so that a client may determine for which move request the compositor has sent configure events. Both these methods by themself are racy regarding inter-surface synchronization. In order to avoid race conditions when applying new states, a new request is also added to xdg_surface: xdg_surface.sync_with_popup. This request is a one-shot request to defer application of the to be committed surface state until the state of the passed popup surface is applied. Lastly, a request to couple a xdg_positioner object with a configure event is added in order for a compositor to pair a popup move request with a pending configure event. This is necessary to, for example, properly constrain a popup given a yet-to-be-applied parent state. An example of when this may be necessary is an interactive resize where both the toplevel position and the relative popup position changes. Signed-off-by: Jonas Ådahl Reviewed-by: Mike Blumenkrantz --- Hi, These additions aims to make it possible to move a xdg_popup in relation to its parent in a way that creates a synchronized update between both the parent and child. A couple of examples of use cases this is needed for: * Popover surfaces A popover in Gtk can, in contrast to GtkMenu, move around. These include the popover itself changing size, the widget it is aligned to moves or changes size, the parent window is resized causing the widget the popover is aligned to moving along with it. In Gtk3 popovers has been implemented using subsurfaces, but this means we don't get the constraint logic resulting in popovers tending to end up outside of the screen estate. * Auto-completion surfaces In GNOME Builder there has been a long standing issue regarding popups due to their inability to move once mapped. The currently available work-arounds for these types issues are currently either to use subsurfaces, or remapping with a new positioner object. Both these work-arounds are of course inadequate. They way moving intends to be done depends on how the move is initiated. A couple of examples describing how moving is intended to be performed to get a synchronized result: Example A: (1) Consider the following window (illustrated with ASCII graphics). Assume the widget is aligned to the right edge of the parent window. The popover is positioned so that it pops up south of the widget, horizontally centered to it. +-+ | Toplevel ___. . . . Widget || | | |--- | |_^_ | +---| |-+ | |. . . Popover --- (2) If the toplevel is resized horizontally, the widget moves as it is resized. A final or intermediate result may be: +---+ | Toplevel ___. . . . Widget | | | | | --- | | _^_ | +-| |-+ | |. . . Popover --- The protocol flow for this could, seen from a clients perspective be: --> xdg_toplevel.configure(200, 600) --> xdg_popup_surface.configure(3) <-- xdg_popup_surface.ack_configure(3) <-- xdg_popup_surface.sync_with_popup(xdg_popup) <-- xdg_positioner = xdg_wm_base.create_positioner() ... set positioner parameters ... <-- xdg_positioner.set_parent_configure_serial(3) <-- xdg_popup.move(xdg_positioner, 0) ... draw and attach new toplevel state ... <-- wl_toplevel_surface.commit() --> xdg_popup.moved(0) --> xdg_popup.configure(520, 20, 100, 200) --> xdg_popup_surface.configure(2) <-- xdg_popup_surface.ack_configure(2) .. draw and attach new popup state ... <-- wl_popup_surface.commit() As
[ANNOUNCE] wayland-protocols 1.18
wayland-protocols 1.18 is now available. This version comes with documentational clarifications, bug fixes and minor additions to existing protocols. See the commit log for details. Alexandros Frantzis (3): linux-explicit-synchronization: Allow fences with opaque EGL buffers linux-explicit-synchronization: Warn about using the protocol while using graphics APIs linux-explicit-synchronization: Clarify implicit synchronization guarantees of release events Chia-I Wu (1): linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID Jan-Marek Glogowski (1): xdg-shell: use case to change the app ID at runtime Jonas Ådahl (2): xdg-shell/README: Update E-mail address configure.ac: Bump version to 1.18 Sebastian Krzyszkowiak (1): xdg-shell: fix a typo Simon Ser (3): xdg-output: deprecate the xdg_output.done event pointer-gestures: add a release request xdg-output: make xdg_output.description mutable git tag: 1.18 http://wayland.freedesktop.org/releases/wayland-protocols-1.18.tar.xz MD5: af38f22d8e233c2f2e00ddc8dcc94694 wayland-protocols-1.18.tar.xz SHA1: aa2f132c082f3c790bd046283b3ef7ce3fb11370 wayland-protocols-1.18.tar.xz SHA256: 3d73b7e7661763dc09d7d9107678400101ecff2b5b1e531674abfa81e04874b3 wayland-protocols-1.18.tar.xz PGP: http://wayland.freedesktop.org/releases/wayland-protocols-1.18.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3] xdg-shell: use case to change the app ID at runtime
On Wed, Jul 17, 2019 at 12:12:37PM +0200, Jan-Marek Glogowski wrote: > Am 15.07.19 um 16:20 schrieb glo...@fbihome.de: > > From: Jan-Marek Glogowski > > > > LibreOffice is one big binary with explicit brandings for different > > application modules. This is represented in X11 by a different > > WM_CLASS setting for a window. The WM_CLASS is changed based on the > > loaded document at runtime. As a result LibreOffice already offers > > multiple desktop files with different icons, StartupWMClass > > entries and application names. > > > > This amendment of the set_app_id request just explicitly specifies > > the use case to change a surfaces' app ID at runtime, so a compositor > > implementor is made aware of it. Just as the WM_CLASS, a change of > > the app ID should result in an update of the propertes of a surface > > depending on the app ID, like the window icon specified in the > > desktop file or a re-grouping of the surfaces in a task manager. > > Signed-off-by: Jan-Marek Glogowski Thanks, this has now landed. Jonas > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2] xdg-output: make xdg_output.description mutable
On Wed, Jul 17, 2019 at 08:25:59AM +, Simon Ser wrote:
> The output description is a human-readable text describing the output. Unlike
> the name which uniquely identifies the output, it's intended to be displayed
> to
> the user.
>
> It might be desirable for a compositor to update an output's description. For
> instance, when only one output is plugged in, it's not necessary to dump make,
> model, serial and connector to the description, something like "Dell U2717D"
> is
> enough. However when two identical outputs are plugged in it's necessary to
> add
> e.g. the connector type to tell them apart ("Dell U2717D on HDMI"). See [1]
> for
> a discussion about this.
>
> This commit bumps xdg_output's version to allow compositors to update the
> property.
>
> [1]: https://github.com/swaywm/wlroots/issues/1623
>
> Signed-off-by: Simon Ser
Now pushed with my Reviewed-by and Oliviers Acked-by.
Jonas
> ---
>
> The version isn't bumped because this has already been done in the previous
> patch.
>
> Changes in v2: rebased on top of HEAD
>
> unstable/xdg-output/xdg-output-unstable-v1.xml | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
> b/unstable/xdg-output/xdg-output-unstable-v1.xml
> index 9efb7a40417b..fe3a70aab0d2 100644
> --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -206,10 +206,12 @@
> output via :1'.
>
> The description event is sent after creating an xdg_output (see
> - xdg_output_manager.get_xdg_output). This event is only sent once per
> + xdg_output_manager.get_xdg_output) and whenever the description
> + changes. The description is optional, and may not be sent at all.
> +
> + For objects of version 2 and lower, this event is only sent once per
> xdg_output, and the description does not change over the lifetime of
> - the wl_output global. The description is optional, and may not be sent
> - at all.
> + the wl_output global.
>
>
>
> --
> 2.22.0
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2] xdg-output: make xdg_output.description mutable
On Wed, Jul 17, 2019 at 08:25:59AM +, Simon Ser wrote:
> The output description is a human-readable text describing the output. Unlike
> the name which uniquely identifies the output, it's intended to be displayed
> to
> the user.
>
> It might be desirable for a compositor to update an output's description. For
> instance, when only one output is plugged in, it's not necessary to dump make,
> model, serial and connector to the description, something like "Dell U2717D"
> is
> enough. However when two identical outputs are plugged in it's necessary to
> add
> e.g. the connector type to tell them apart ("Dell U2717D on HDMI"). See [1]
> for
> a discussion about this.
>
> This commit bumps xdg_output's version to allow compositors to update the
> property.
>
> [1]: https://github.com/swaywm/wlroots/issues/1623
>
> Signed-off-by: Simon Ser
Thanks for the rebase.
Reviewed-by: Jonas Ådahl
Jonas
> ---
>
> The version isn't bumped because this has already been done in the previous
> patch.
>
> Changes in v2: rebased on top of HEAD
>
> unstable/xdg-output/xdg-output-unstable-v1.xml | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
> b/unstable/xdg-output/xdg-output-unstable-v1.xml
> index 9efb7a40417b..fe3a70aab0d2 100644
> --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -206,10 +206,12 @@
> output via :1'.
>
> The description event is sent after creating an xdg_output (see
> - xdg_output_manager.get_xdg_output). This event is only sent once per
> + xdg_output_manager.get_xdg_output) and whenever the description
> + changes. The description is optional, and may not be sent at all.
> +
> + For objects of version 2 and lower, this event is only sent once per
> xdg_output, and the description does not change over the lifetime of
> - the wl_output global. The description is optional, and may not be sent
> - at all.
> + the wl_output global.
>
>
>
> --
> 2.22.0
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3] xdg-shell: use case to change the app ID at runtime
On Mon, Jul 15, 2019 at 04:20:10PM +0200, glo...@fbihome.de wrote: > From: Jan-Marek Glogowski > > LibreOffice is one big binary with explicit brandings for different > application modules. This is represented in X11 by a different > WM_CLASS setting for a window. The WM_CLASS is changed based on the > loaded document at runtime. As a result LibreOffice already offers > multiple desktop files with different icons, StartupWMClass > entries and application names. > > This amendment of the set_app_id request just explicitly specifies > the use case to change a surfaces' app ID at runtime, so a compositor > implementor is made aware of it. Just as the WM_CLASS, a change of > the app ID should result in an update of the propertes of a surface > depending on the app ID, like the window icon specified in the > desktop file or a re-grouping of the surfaces in a task manager. Just noted this is missing Signed-off-by. Mind if I help you add it? Jonas > --- > stable/xdg-shell/xdg-shell.xml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml > index 2e420c6..3a87a9e 100644 > --- a/stable/xdg-shell/xdg-shell.xml > +++ b/stable/xdg-shell/xdg-shell.xml > @@ -604,6 +604,9 @@ > For example, "org.freedesktop.FooViewer" where the .desktop file is > "org.freedesktop.FooViewer.desktop". > > + Like other properties, a set_app_id request can be sent after the > + xdg_toplevel has been mapped to update the property. > + > See the desktop-entry specification [0] for more details on > application identifiers and how they relate to well-known D-Bus > names and .desktop files. > -- > 2.20.1 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v3] pointer-gestures: add a release request
On Mon, Jan 28, 2019 at 10:05:55AM +, Simon Ser wrote: > This allows clients to destroy a gesture object before they disconnect. > > The request isn't named "destroy", as this would conflict with > wayland-scanner's auto-generated destructor (which just destroys the > client-side object without sending any request). > > Signed-off-by: Simon Ser > Reviewed-by: Jonas Ådahl Just saw this one never landed; but taken care of now! Jonas > --- > > Changes from v2 to v3: added a version separator > > .../pointer-gestures-unstable-v1.xml | 15 --- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml > b/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml > index 5b7132c..59502ac 100644 > --- a/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml > +++ b/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml > @@ -1,7 +1,7 @@ > > > > - > + > >A global interface to provide semantic touchpad gestures for a given >pointer. > @@ -37,9 +37,18 @@ > > > > + > + > + > + > + > + Destroy the pointer gesture object. Swipe and pinch objects created via > this > + gesture object remain valid. > + > + > > > - > + > >A swipe gesture object notifies a client about a multi-finger swipe >gesture detected on an indirect input device such as a touchpad. > @@ -102,7 +111,7 @@ > > > > - > + > >A pinch gesture object notifies a client about a multi-finger pinch >gesture detected on an indirect input device such as a touchpad. > -- > 2.20.1 > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3] xdg-shell: use case to change the app ID at runtime
On Mon, Jul 15, 2019 at 04:20:10PM +0200, glo...@fbihome.de wrote: > From: Jan-Marek Glogowski > > LibreOffice is one big binary with explicit brandings for different > application modules. This is represented in X11 by a different > WM_CLASS setting for a window. The WM_CLASS is changed based on the > loaded document at runtime. As a result LibreOffice already offers > multiple desktop files with different icons, StartupWMClass > entries and application names. > > This amendment of the set_app_id request just explicitly specifies > the use case to change a surfaces' app ID at runtime, so a compositor > implementor is made aware of it. Just as the WM_CLASS, a change of > the app ID should result in an update of the propertes of a surface > depending on the app ID, like the window icon specified in the > desktop file or a re-grouping of the surfaces in a task manager. Reviewed-by: Jonas Ådahl Jonas > --- > stable/xdg-shell/xdg-shell.xml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml > index 2e420c6..3a87a9e 100644 > --- a/stable/xdg-shell/xdg-shell.xml > +++ b/stable/xdg-shell/xdg-shell.xml > @@ -604,6 +604,9 @@ > For example, "org.freedesktop.FooViewer" where the .desktop file is > "org.freedesktop.FooViewer.desktop". > > + Like other properties, a set_app_id request can be sent after the > + xdg_toplevel has been mapped to update the property. > + > See the desktop-entry specification [0] for more details on > application identifiers and how they relate to well-known D-Bus > names and .desktop files. > -- > 2.20.1 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] xdg-output: make xdg_output.description mutable
On Sat, Apr 27, 2019 at 08:16:04AM +, Simon Ser wrote:
> The output description is a human-readable text describing the output. Unlike
> the name which uniquely identifies the output, it's intended to be displayed
> to
> the user.
>
> It might be desirable for a compositor to update an output's description. For
> instance, when only one output is plugged in, it's not necessary to dump make,
> model, serial and connector to the description, something like "Dell U2717D"
> is
> enough. However when two identical outputs are plugged in it's necessary to
> add
> e.g. the connector type to tell them apart ("Dell U2717D on HDMI"). See [1]
> for
> a discussion about this.
>
> This commit bumps xdg_output's version to allow compositors to update the
> property.
Seems fine to me. Want to rebase on top of the deprecation of
xdg_output.done?
Jonas
>
> [1]: https://github.com/swaywm/wlroots/issues/1623
>
> Signed-off-by: Simon Ser
> ---
> unstable/xdg-output/xdg-output-unstable-v1.xml | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
> b/unstable/xdg-output/xdg-output-unstable-v1.xml
> index ccbfe1c..86216a7 100644
> --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -54,7 +54,7 @@
> reset.
>
>
> -
> +
>
>A global factory interface for xdg_output objects.
>
> @@ -77,7 +77,7 @@
>
>
>
> -
> +
>
>An xdg_output describes part of the compositor geometry.
>
> @@ -197,10 +197,12 @@
> output via :1'.
>
> The description event is sent after creating an xdg_output (see
> - xdg_output_manager.get_xdg_output). This event is only sent once per
> + xdg_output_manager.get_xdg_output) and whenever the description
> + changes. The description is optional, and may not be sent at all.
> +
> + For objects of version 2 and lower, this event is only sent once per
> xdg_output, and the description does not change over the lifetime of
> - the wl_output global. The description is optional, and may not be sent
> - at all.
> + the wl_output global.
>
>
>
> --
> 2.21.0
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v3] xdg-output: deprecate the xdg_output.done event
On Fri, Jul 12, 2019 at 03:42:52PM +, Simon Ser wrote: > This commit makes it so a wl_output.done event is guaranteed to be sent with a > xdg_output.done event. > > This protocol change has been discussed in a recent xorg-devel discussions > [1]. > > First let's recap why a change is needed: Xwayland listens to both wl_output > and > xdg_output changes. When an output's properties change, Xwayland expects to > receive both a wl_output.done event and an xdg_output.done event. If that's > not > the case, Xwayland doesn't update its state (so old state is still exposed to > X11 clients). > > Most of the time, both objects will be updated at the same time (e.g. the > current mode is changed, so both wl_output.mode and xdg_output.logical_size > are > sent) so this won't be an issue. However in some situations only one of > wl_output or xdg_output changes. For instance: > > - The mode is changed at the same time as the scale, resulting in the same > logical_size. > - The compositor doesn't expose the outputs' position via wl_output, so > whenever > the position changes only xdg_output is updated. > > Both KDE [2] and wlroots [3] have experienced this issue. > > For this reason, I'd like to update the xdg-output protocol to make it > mandatory > to always send a wl_output.done event after xdg_output changes. This > effectively > makes wl_output.done atomically apply all output state (including the state of > add-on objects like xdg_output). This approach is pretty similar to > wl_surface.commit: this request will atomically apply surface state including > the state of e.g. the xdg_surface object tied to the wl_surface. > > To update the protocol to reflect this new requirement we can either: > > - **Bump xdg_output version**. The current protocol doesn't specify that > wl_output.done must be sent, adding this new requirement would be a breaking > change. We need to fix Xwayland for the current xdg_output version (maybe > make > it non-atomic for the current version, atomic for the new one?). Should we > deprecate xdg_output.done in the new version? > - **Don't bump xdg_output version**. This clarifies what is expected in > practice > by Xwayland, a major xdg_output consumer, and what is currently implemented > by > all compositors. > > There's one issue with the "don't bump" approach: indeed in practice > compositors > always send wl_output.done and xdg_output.done in pairs, however the ordering > between those two events is not guaranteed. This means some compositors might > send this sequence: > > wl_output.geometry(…) > wl_output.done() > xdg_output.logical_position(…) > xdg_output.done() > > In this case the wl_output.done event fails to atomically apply the xdg_output > state. > > For this reason, I think bumping the version is a better approach. > > This commit also deprecates xdg_output.done, which doesn't have any purpose > anymore. > > [1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html > [2]: https://phabricator.kde.org/D19253 > [3]: https://github.com/swaywm/sway/issues/4064 > > Signed-off-by: Simon Ser > Reviewed-by: Olivier Fourdan Lets go with this! Reviewed-by: Jonas Ådahl Jonas > --- > > Changes from v2 to v3: in xdg_output's description, mention wl_output.done is > guaranteed to be sent only from version 3. > > unstable/xdg-output/xdg-output-unstable-v1.xml | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml > b/unstable/xdg-output/xdg-output-unstable-v1.xml > index ccbfe1c9a955..9efb7a40417b 100644 > --- a/unstable/xdg-output/xdg-output-unstable-v1.xml > +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml > @@ -54,7 +54,7 @@ > reset. > > > - > + > >A global factory interface for xdg_output objects. > > @@ -77,12 +77,17 @@ > > > > - > + > >An xdg_output describes part of the compositor geometry. > >This typically corresponds to a monitor that displays part of the >compositor space. > + > + For objects version 3 onwards, after all xdg_output properties have > been > + sent (when the object is created and when properties are updated), a > + wl_output.done event is sent. This allows changes to the output > + properties to be seen as atomic, even if they happen via multiple > events. > > > > @@ -157,6 +162,10 @@ > > This allows changes to the xdg_output properties to
Re: [PATCH] xdg-shell: add use case to handle change of app_id
On Sun, Jul 07, 2019 at 04:27:54PM +0200, Jan-Marek Glogowski wrote: > Am 07.07.19 um 16:11 schrieb Simon Ser: > >> @@ -604,6 +604,11 @@ > >>For example, "org.freedesktop.FooViewer" where the .desktop file is > >>"org.freedesktop.FooViewer.desktop". > >> > >> + This request can be used to change the icon of a window at runtime by > >> + providing different desktop files and changing the app_id. > > > > I'm not sure this change is necessary. Nothing says this request can't be > > sent > > after the toplevel has been setup. Other requests don't explicitly specify > > they > > can be sent after setup. > > It's just that I was told by multiple people "app_id maps to WM_CLASS, so > should > be considered static". And IMHO it's uncommon / unexpected to change the > app_id, > so I wanted to mention this use case explicitly so Wayland implementors will > be > aware of it. > > >> Windows of > >> + the same app_id will still be grouped together, as they are expected > >> + to represent the same application from the users point of view. > > > > This should be left out, because this is compositor policy. Some compositors > > don't group by app_id. > > My intention was to express, that if you change the app_id to change the icon, > don't expect that the previous grouping will persist. This is obvious, and > from > LO POV I want the document windows grouped by type, eventually, so I'm fine > skipping it. The compositor may do whatever it want based on the app_id, but > LO > will be able to offer the correct grouping "hint". I think it's fine to mention that it may change, and elaborate more verbosely in the commit message about the LibreOffice use case, but I don't think it should mention anything about icons, grouping and what not since, as Simon said, that is compositor policy and not relevant here. Jonas > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2] xdg-output: deprecate the xdg_output.done event
On Tue, Jul 02, 2019 at 03:33:00PM +, Simon Ser wrote: > This commit makes it so a wl_output.done event is guaranteed to be sent with a > xdg_output.done event. > > This protocol change has been discussed in a recent xorg-devel discussions > [1]. > > First let's recap why a change is needed: Xwayland listens to both wl_output > and > xdg_output changes. When an output's properties change, Xwayland expects to > receive both a wl_output.done event and an xdg_output.done event. If that's > not > the case, Xwayland doesn't update its state (so old state is still exposed to > X11 clients). > > Most of the time, both objects will be updated at the same time (e.g. the > current mode is changed, so both wl_output.mode and xdg_output.logical_size > are > sent) so this won't be an issue. However in some situations only one of > wl_output or xdg_output changes. For instance: > > - The mode is changed at the same time as the scale, resulting in the same > logical_size. > - The compositor doesn't expose the outputs' position via wl_output, so > whenever > the position changes only xdg_output is updated. > > Both KDE [2] and wlroots [3] have experienced this issue. > > For this reason, I'd like to update the xdg-output protocol to make it > mandatory > to always send a wl_output.done event after xdg_output changes. This > effectively > makes wl_output.done atomically apply all output state (including the state of > add-on objects like xdg_output). This approach is pretty similar to > wl_surface.commit: this request will atomically apply surface state including > the state of e.g. the xdg_surface object tied to the wl_surface. > > To update the protocol to reflect this new requirement we can either: > > - **Bump xdg_output version**. The current protocol doesn't specify that > wl_output.done must be sent, adding this new requirement would be a breaking > change. We need to fix Xwayland for the current xdg_output version (maybe > make > it non-atomic for the current version, atomic for the new one?). Should we > deprecate xdg_output.done in the new version? > - **Don't bump xdg_output version**. This clarifies what is expected in > practice > by Xwayland, a major xdg_output consumer, and what is currently implemented > by > all compositors. > > There's one issue with the "don't bump" approach: indeed in practice > compositors > always send wl_output.done and xdg_output.done in pairs, however the ordering > between those two events is not guaranteed. This means some compositors might > send this sequence: > > wl_output.geometry(…) > wl_output.done() > xdg_output.logical_position(…) > xdg_output.done() > > In this case the wl_output.done event fails to atomically apply the xdg_output > state. > > For this reason, I think bumping the version is a better approach. > > This commit also deprecates xdg_output.done, which doesn't have any purpose > anymore. > > [1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html > [2]: https://phabricator.kde.org/D19253 > [3]: https://github.com/swaywm/sway/issues/4064 > > Signed-off-by: Simon Ser > Reviewed-by: Olivier Fourdan > --- > > Changes from v1 to v2: state in xdg_output's description that wl_output.done > is sent after properties have been sent (Jonas) > > unstable/xdg-output/xdg-output-unstable-v1.xml | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml > b/unstable/xdg-output/xdg-output-unstable-v1.xml > index ccbfe1c9a955..e3ed58766d17 100644 > --- a/unstable/xdg-output/xdg-output-unstable-v1.xml > +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml > @@ -54,7 +54,7 @@ > reset. > > > - > + > >A global factory interface for xdg_output objects. > > @@ -77,12 +77,17 @@ > > > > - > + > >An xdg_output describes part of the compositor geometry. > >This typically corresponds to a monitor that displays part of the >compositor space. > + > + After all xdg_output properties have been sent (when the object is > + created and when properties are updated), a wl_output.done event is > sent. > + This allows changes to the output properties to be seen as atomic, even > + if they happen via multiple events. This is a good description, but probably want to add that it's only after version 3 this is guaranteed. Jonas > > > > @@ -157,6 +162,10 @@ > > This allows changes to t
Re: [PATCH wayland-protocols] xdg-output: deprecate the xdg_output.done event
On Sat, Apr 27, 2019 at 07:44:39AM +, Simon Ser wrote: > This commit makes it so a wl_output.done event is guaranteed to be sent with a > xdg_output.done event. > > This protocol change has been discussed in a recent xorg-devel discussions > [1]. > > First let's recap why a change is needed: Xwayland listens to both wl_output > and > xdg_output changes. When an output's properties change, Xwayland expects to > receive both a wl_output.done event and an xdg_output.done event. If that's > not > the case, Xwayland doesn't update its state (so old state is still exposed to > X11 clients). > > Most of the time, both objects will be updated at the same time (e.g. the > current mode is changed, so both wl_output.mode and xdg_output.logical_size > are > sent) so this won't be an issue. However in some situations only one of > wl_output or xdg_output changes. For instance: > > - The mode is changed at the same time as the scale, resulting in the same > logical_size. > - The compositor doesn't expose the outputs' position via wl_output, so > whenever > the position changes only xdg_output is updated. > > Both KDE [2] and wlroots [3] have experienced this issue. > > For this reason, I'd like to update the xdg-output protocol to make it > mandatory > to always send a wl_output.done event after xdg_output changes. This > effectively > makes wl_output.done atomically apply all output state (including the state of > add-on objects like xdg_output). This approach is pretty similar to > wl_surface.commit: this request will atomically apply surface state including > the state of e.g. the xdg_surface object tied to the wl_surface. > > To update the protocol to reflect this new requirement we can either: > > - **Bump xdg_output version**. The current protocol doesn't specify that > wl_output.done must be sent, adding this new requirement would be a breaking > change. We need to fix Xwayland for the current xdg_output version (maybe > make > it non-atomic for the current version, atomic for the new one?). Should we > deprecate xdg_output.done in the new version? > - **Don't bump xdg_output version**. This clarifies what is expected in > practice > by Xwayland, a major xdg_output consumer, and what is currently implemented > by > all compositors. > > There's one issue with the "don't bump" approach: indeed in practice > compositors > always send wl_output.done and xdg_output.done in pairs, however the ordering > between those two events is not guaranteed. This means some compositors might > send this sequence: > > wl_output.geometry(…) > wl_output.done() > xdg_output.logical_position(…) > xdg_output.done() > > In this case the wl_output.done event fails to atomically apply the xdg_output > state. > > For this reason, I think bumping the version is a better approach. > > This commit also deprecates xdg_output.done, which doesn't have any purpose > anymore. Relying only on wl_output.done sounds good to me. Since the 'done' event here is eventally to go away, I think it'd be wise to state somewhere other than the 'done' documentation that the wl_output.done event is used to notify all changes have been communicated. Jonas (P.S. sorry for the ones in the To:/Cc: field for the multiple mails, for some reason mailman thinks I'm sending from my @redhat.com address, thus gets stuck on moderation. D.S.). > > [1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html > [2]: https://phabricator.kde.org/D19253 > [3]: https://github.com/swaywm/sway/issues/4064 > > Signed-off-by: Simon Ser > --- > unstable/xdg-output/xdg-output-unstable-v1.xml | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml > b/unstable/xdg-output/xdg-output-unstable-v1.xml > index ccbfe1c..01ac7a7 100644 > --- a/unstable/xdg-output/xdg-output-unstable-v1.xml > +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml > @@ -54,7 +54,7 @@ > reset. > > > - > + > >A global factory interface for xdg_output objects. > > @@ -77,7 +77,7 @@ > > > > - > + > >An xdg_output describes part of the compositor geometry. > > @@ -157,6 +157,10 @@ > > This allows changes to the xdg_output properties to be seen as > atomic, even if they happen via multiple events. > + > + For objects version 3 onwards, this event is deprecated. Compositors > + are not required to send it anymore and must send wl_output.done > + instead. > > > > -- > 2.21.0 > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] xdg-shell: remove constraints for fullscreen
On Fri, Jun 21, 2019 at 05:35:35PM -0700, Jasper St. Pierre wrote: > To be clear, the patch does break backwards compatibility with compositor > behavior -- it only weakens a guarantee by saying that transparent > fullscreen content is undefined. Existing compositor behavior is still > allowed. To weaken the guarantees previously defined is breaking backward compatibility. Clients that implemented its functionality given the promises defined by the specification would have to change according to the new promises. > > However, it does mean that clients might not get the output they desire > under new rules. It also does not make any new guarantees for a client -- a > fullscreen transparent terminal might show surfaces underneath, or it might > not. That hardly seems useful to me from a client perspective. > > That said, adding a new request does not seem like a good solution to me -- > if the user presses a compositor key shortcut, should the app be in > transparent or opaque fullscreen mode? It might make sense to have a > special "set_fullscreen_blend_mode" that clients can use to configure their > fullscreen appearance in all cases. I do not imagine this will change > often, so it likely does not need to be a state. Setting a fullscreen blend mode as part of configuring the fullscreen state seems more sane than a separate fullscreen request indeed. Probably want to enforce the configured size for non-opaque blend modes too, to not have to let the region outside the surface be undefined. Jonas > > On Fri, Jun 21, 2019, 8:43 PM Michael Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > > > Hi, > > > > Some compositors and client toolkits do rely on the existing wording. > > Occlusion culling is used for (obvious) performance reasons in fullscreen > > cases. If the fullscreen surface is not opaque, clients can still rely on > > the compositor's handling of fullscreen states using the current wording > > and prioritize resources for this fullscreen surface even if there are > > other surfaces which are visible behind it. This is especially true for > > embedded cases. > > > > Given that releases and products have already shipped that rely on this > > language, and that the terminology and language used here is a core > > functionality of the feature, it absolutely cannot be changed. > > > > > > Regards, > > Mike > > > > On Fri, 21 Jun 2019 14:32:34 -0400 > > "Drew DeVault" wrote: > > > > > On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote: > > > > This changes the semantics in a non-backward compatible way; clients > > > > relying on the currently defined behavior would break, so I'll have to > > > > nack this change. You'd have to add a `set_fullscreen_translucent` or > > > > something like that if the described behavior is needed. > > > > > > To re-use an argument that was brought up in the xdg-decoration > > > discussion: compositors are just going to do whatever they want here, > > > and this sets up expectations accordingly. Wayfire already disregards > > > this clause, and consider this an announcement of Sway's intentions do > > > to the same. > > > > > > In any case, I don't think this grossly affects the behavior clients > > > have come to rely on. I sought some feedback on this patch privately > > > before posting it to consider these concerns upfront. The main use-case > > > for the original wording was found to be media players which rely on > > > this behavior for letterboxing when the aspect ratio between the output > > > and the video differs - which is addressed in the proposed wording. > > > > > > Additionally, the original wording never made any promises as to the > > > relationship between the fullscreened surface and the output its shown > > > on. One notable example is that the unreliability of wl_output's > > > width/height specifications forces (correctly so) users to continue to > > > use configure events to communicate the desired size. This is especially > > > necessary with non-traditional outputs like VR headsets. Implementation > > > details like direct scan-out, which is only possible given the > > > constraints in the original wording, aren't actually guaranteed - but > > > are not ruled out by the new wording. > > > > > > What do you think? Does that rationale make more sense? > > > ___ > > > wayland-devel mailing list > > > wayland-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
omewhat more lenient than we have been in the past. That's a necessary > concession for this governance overhaul's success as a whole. I'm only arguing for keeping the xdg namespace something that will contain portable protocols, where portable here means usable for applications that want to function on "all" compositors. An application relying on wlr-foreign-toplevel-manamegement will never be portable. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] xdg-output: make xdg_output.description mutable
On Sun, Jun 23, 2019 at 10:05:09AM +, Simon Ser wrote:
> Hi Jonas,
>
> What do you think of this patch?
Maybe want to say something about how this interacts with 'done'?
Jonas
>
> Thanks,
>
> Simon
>
> On Saturday, April 27, 2019 11:16 AM, Simon Ser wrote:
> > The output description is a human-readable text describing the output.
> > Unlike
> > the name which uniquely identifies the output, it's intended to be
> > displayed to
> > the user.
> >
> > It might be desirable for a compositor to update an output's description.
> > For
> > instance, when only one output is plugged in, it's not necessary to dump
> > make,
> > model, serial and connector to the description, something like "Dell
> > U2717D" is
> > enough. However when two identical outputs are plugged in it's necessary to
> > add
> > e.g. the connector type to tell them apart ("Dell U2717D on HDMI"). See [1]
> > for
> > a discussion about this.
> >
> > This commit bumps xdg_output's version to allow compositors to update the
> > property.
> >
> > [1]: https://github.com/swaywm/wlroots/issues/1623
> >
> > Signed-off-by: Simon Ser
> > ---
> > unstable/xdg-output/xdg-output-unstable-v1.xml | 12 +++-
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
> > b/unstable/xdg-output/xdg-output-unstable-v1.xml
> > index ccbfe1c..86216a7 100644
> > --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> > +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> > @@ -54,7 +54,7 @@
> > reset.
> >
> >
> > -
> > +
> >
> >A global factory interface for xdg_output objects.
> >
> > @@ -77,7 +77,7 @@
> >
> >
> >
> > -
> > +
> >
> >An xdg_output describes part of the compositor geometry.
> >
> > @@ -197,10 +197,12 @@
> > output via :1'.
> >
> > The description event is sent after creating an xdg_output (see
> > - xdg_output_manager.get_xdg_output). This event is only sent once per
> > + xdg_output_manager.get_xdg_output) and whenever the description
> > + changes. The description is optional, and may not be sent at all.
> > +
> > + For objects of version 2 and lower, this event is only sent once per
> > xdg_output, and the description does not change over the lifetime of
> > - the wl_output global. The description is optional, and may not be sent
> > - at all.
> > + the wl_output global.
> >
> >
> >
> > --
> > 2.21.0
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] xdg-shell: remove constraints for fullscreen
On Wed, Jun 19, 2019 at 01:35:42PM -0400, Drew DeVault wrote: > Compositors are free to render surfaces at their discretion. This > change clarifies that for xdg-shell's fullscreen surfaces. > --- > This point has been a recurring cause for frustration in Sway > development, as users expect windows beneath transparent fullscreen > windows to be shown. The main use-case for this, for example, is working > in a transparent full-screen terminal while referencing docs in a web > browser underneath. We hit this again for a different reason when > discussing a patch which would allow the user to arrange fullscreen > windows in a manner other than by using the entire screen. > > At least one other compositor in the wild (Wayfire) is also not > respecting these constraints. It is my intent to loosen this restriction > and start considering sway patches which change the behavior of > fullscreen in a manner inconsistent with these constraints. > > Since it's the compositors privilege to do anything it wants with > client surfaces, this updates the protocol text to reflect that, while > still suggesting the desired behavior. > > stable/xdg-shell/xdg-shell.xml | 18 -- > 1 file changed, 8 insertions(+), 10 deletions(-) > > diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml > index 2e420c6..22ff93d 100644 > --- a/stable/xdg-shell/xdg-shell.xml > +++ b/stable/xdg-shell/xdg-shell.xml > @@ -926,16 +926,14 @@ > it's up to the compositor to choose which display will be used to map > this surface. > > - If the surface doesn't cover the whole output, the compositor will > - position the surface in the center of the output and compensate with > - with border fill covering the rest of the output. The content of the > - border fill is undefined, but should be assumed to be in some way that > - attempts to blend into the surrounding area (e.g. solid black). > - > - If the fullscreened surface is not opaque, the compositor must make > - sure that other screen content not part of the same surface tree (made > - up of subsurfaces, popups or similarly coupled surfaces) are not > - visible below the fullscreened surface. > + The compositor should interpret this as a suggestion that the > fullscreened > + surface should be shown across the entire output, however, the specific > + position and sizing of the client on-screen is undefined. When the > + aspect ratio of the fullscreened surface is not equal to the aspect > + ratio of the space allocated for its display, the compositor should fill > + the remaining space in with a neutral background (e.g. solid black). If > + the surface is not opaque, the content (e.g. other surfaces) shown below > + the fullscreened surface is undefined. This changes the semantics in a non-backward compatible way; clients relying on the currently defined behavior would break, so I'll have to nack this change. You'd have to add a `set_fullscreen_translucent` or something like that if the described behavior is needed. Jonas > > allow-null="true"/> > > -- > 2.22.0 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Wed, Jun 19, 2019 at 10:52:32AM -0400, Drew DeVault wrote: > On Wed Jun 19, 2019 at 8:38 AM Jonas Ådahl wrote: > > > I'm okay with this definition, but I'll again mention that this wording > > > makes a clear case for the wlr toplevel management protocol: > > > > > > https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml > > > > > > This is your chance to object to a wording that would include this > > > protocol. > > > > s/configure surfaces/configure its surfaces/ would rule out accidentally > > including external window manager like protocols into the xdg namespace. > > How does xdg-foreign fit into this definition? xdg-foreign is an edge case but IMHO it fits in the definition. xdg-shell deals with stacking order of the dialogs of an application. xdg-foreign extends this behaviour by allowing two clients to "act as one". The current users are the xdg-desktop-portal backend, but it's something that's needed for e.g. modal dialogs for out-of-process plugins and similar things. It's far from task bar like functionality, if that's what you are trying to compare it to. > > I see two courses of action for this problem: > > a. Don't weasel word the xdg shell definition and accept that >xdg-foreign-toplevel-management fits. "Universal acceptance" is the >bar for the wp- prefix, but not xdg-. Just because e.g. GNOME wouldn't >implement it doesn't necessarily mean it's not a good fit - see also >xdg-decoration. xdg-decoration is a perfectly good fit for "xdg-" IMO. Again, I believe the definition should make it clear that it's for applications, not desktop components. I'm not trying to weasel anything here, I'm trying to avoid making anyone believe writing a task bar is the same thing as writing an application that is expected to work everywhere. > b. Close the xdg namespace to new protocols. > > There's also option c, which is weasel word it until the protocols > anyone doesn't like aren't included and the protocols everyone does like > are included, but I don't think that's worth our time to try and > accomplish. Lets not be childish; noone is trying to weasel anything here, and I don't understand what you're trying to accomplish by implying that. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Tue, Jun 18, 2019 at 07:31:47PM -0400, Drew DeVault wrote: > On Mon Jun 17, 2019 at 9:55 AM Jonas Ådahl wrote: > > > a. Namespaces are implemented in practice by prefixing each interface > > > name in a > > >protocol definition (XML) with the namespace name, and an underscore > > > (e.g. > > >"xdg_wm_base"). > > > b. Protocols in a namespace may optionally use the namespace followed by > > > a dash > > >in the name (e.g. "xdg-shell"). > > > > The usage of a dash instead of underscore is what the name as well as > > file name should use. The underscore is for protocol interface, requests and > > events only. > > ACK > > > > c. The "xdg" namespace is established for protocols useful for > > > implementing > > >desktop-like systems. > > > > Usage in only 'desktop-like' systems is not how xdg based protocols are > > used today, so this definition is incorrect to begin with. A better > > definition might be > > > > c. The "xdg" namespace is established for protocols letting clients > > configure surfaces as "windows", allowing clients to affect how they > > are managed. > > I'm okay with this definition, but I'll again mention that this wording > makes a clear case for the wlr toplevel management protocol: > > https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml > > This is your chance to object to a wording that would include this > protocol. s/configure surfaces/configure its surfaces/ would rule out accidentally including external window manager like protocols into the xdg namespace. > > > > e. Protocols in the "ext" namespace are eligible for inclusion only if > > > ACKed by > > >at least one member. > > > > This effectively means that any member can add any protocol under the > > "ext" namespace without any limitations. Is this really the intention > > here? > > Yep. > > > > f. Protocols in the "ext" namespace must have at least one open-source > > > client & > > >one open-source server implementation to be eligible for inclusion. > > > > I see the point of this, philosophically, but is it really a restriction > > we want? Lets pretend some proprietary compositor shows up and wants to > > collaborate developing some kind of protocol that'd fit into the "ext" > > category. Maybe there are open source clients who are interested in this > > functionality, or maybe they provide their own proprietary client; would > > we really want to keep them out instead of working together? > > If the open source clients are interested in this functionality, they > can implement it before it's standardized in wayland-protocols. This is > already how most protocols are developed today. Nothing stops us from > collaborating on protocols which don't yet meet the requirements for > inclusion in wayland-protocols. > > > The availability of an "open source implementation" is also somewhat > > vague; does a "dummy implementation" count, or how fully featured must > > it be to be considered "good enough" for this requirement to be met? > > I think we ought to use our best judgement here, erring on the side of > "it counts" and making our arguments if we think an implementation does > not. > > > > 2.3. Introducing new protocols > > > > > > a. A new protocol may be proposed by submitting a merge request to the > > >wayland-protocols Gitlab repository. > > > b. Protocol proposal posts must include justification for their inclusion > > > in > > >their namespace per the requirements outlined in section 2.2. > > > c. An indefinite discussion period for comments from wayland-protocols > > > members > > >will be held, with a minimum duration of 30 days. Protocols which > > > require a > > >certain level of implementation status, ACKs from members, and so on, > > > should > > >use this time to acquire them. > > > d. When the proposed protocol meets all requirements for inclusion per > > > section > > >2.2, and the minimum discussion period has elapsed, the sponsoring > > > member may > > >push their changes to the wayland-protocol repository. > > > e. Amendments to existing protocols may be proposed by the same process. > > > &
Re: wayland-protocols scope and governance
.2. Changes to the adoption website > > a. This section is informational. > b. A new protocol is added to the website by the sponsoring member at the >conclusion of the discussion period (section 2.3.c). > c. During the discussion period (section 2.3.c), interested parties may > express >their approval status on the Gitlab merge request. The default approval >status for members who do not participate in the discussion is "NOPP". > d. Members may change their acknowledgement status or support statement at any >time after the discussion period (section 2.3.c) has closed by simply > pushing >their update to the wayland-protocols repository. > > 4. Amending this document > > a. An amendment to this document may be proposed any member by >submitting a merge request on Gitlab. > b. A 30 day discussion period for comments from wayland-protocols members will >be held. > c. At the conclusion of the discussion period, an amendment will become >effective if it's ACKed by at least 2/3rds of wayland-protocols members, > and >NACKed by none. The sponsoring member may push their change to the >wayland-protocols repository at this point. There are a few places that mentiones "pushing" to the repository. For changing changes to the adoption website/database it seems like a reasonable thing, but for protocol addition and amendments and amending this document, let's just use merge requests directly so that we can make use of CI to ensure things passes checks before reaching the master branch. Jonas > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Xwayland component in bugzilla
On Fri, May 10, 2019 at 11:29:50AM +0300, Pekka Paalanen wrote: > On Thu, 09 May 2019 14:03:52 -0400 > Adam Jackson wrote: > > > The Xwayland component of the Wayland product in bugzilla is still open > > for bug entry. Does anyone actually want this? I'm happy to migrate the > > remaining open bugs into xserver's gitlab issues where they belong, but > > I wanted to make sure nobody's still relying on bugzilla for this. > > Hi Adam, > > I don't recall why that even existed in the first place... maybe it was > from the time when xwayland was still a DDX module for Xorg? > > At least personally I don't see any use for that bz component anymore. I too think it's better to migrate to and use the xservers issue tracker. The only "downside" is the wayland-bugs mailing list not receiving those bugs anymore without further intervention. An Xwayland label will help a bit, but IIRC there is no way for random bug reporters to add labels, so it'll need work done by bug triagers. Jonas > > > Thanks, > pq > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The new release manager
On Fri, Apr 12, 2019 at 11:19:35AM +0300, Pekka Paalanen wrote: > On Mon, 08 Apr 2019 22:00:31 + > Simon Ser wrote: > > > On Monday, April 8, 2019 1:02 PM, Pekka Paalanen > > wrote: > > > Hi Simon, > > > > > > I would be happy to have you. Let's see till Friday if anyone else has > > > anything to say. > > > > Nice! > > Hi all, > > Daniel Stone, Derek Foreman and myself have supported Simon as the new > Wayland and Weston release manager, and no-one has objected in a week, > and also there were no other volunteers. > > Therefore let's make it official and say hi to our new release manager, > Simon Ser! :-) Thanks Derek for your all the releases you made, and thanks Simon for the future releases! :) Jonas > > I'll see about setting up the Gitlab access rights if they're not done > yet. > > > Thanks, > pq > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Thu, Feb 21, 2019 at 11:47:13AM -0500, Mike Blumenkrantz wrote: > Hello, > > On Thu, Feb 21, 2019 at 10:47 AM Daniel Stone wrote: > > > > > One of Weston's goals is to be a reference compositor. As an active > > implementation, it serves as a useful neutral ground for the rest of > > the ecosystem: we try to be exhaustively correct in what we do > > implement, and gets used as a litmus test for clients and compositors > > both to compare their behaviour against (who's interpreted the spec > > incorrectly?). We take that responsibility pretty seriously, which > > places a ceiling on the rate of change as well as the breadth of > > functionality we can implement. > > > > There used to be a rule (observed in all but extremis) that any common > > protocol had to have a Weston implementation, as the closest analogue > > we had to a conformance test suite. That was abandoned long ago, since > > there are some protocols for which it wasn't practical to do so. That > > was the point beyond which we moved from Weston being _the_ reference > > compositor for the entire ecosystem, to just being a useful resource. > > (I get that Weston's README still says 'Weston is the reference > > implementation of a Wayland compositor' as literally its first words. > > I'd personally be OK with changing that.) > > > > Weston is also useful as a demonstration vehicle for new low-level > > graphics functionality, particularly for EGL and KMS features. We were > > the first to do overlay planes, full damage tracking (and now > > per-plane KMS damage tracking), dmabuf, buffer modifiers, explicit > > fencing, atomic modesetting, same-CRTC clone mode (AFAIK), > > aspect-ratio modes, and so on. I'm pretty happy with how that's going, > > even if we do still have some feature gaps. > > > > > Speaking on an entirely personal level (i.e., unrelated to any project or > employer) and as someone who has spent an amount of time writing both > compositors and clients using Wayland protocols--and also writing those > protocols, I found this to be very accurate. My ability to successfully > implement protocols in compositors and clients has benefited tremendously > over the years from the existence of Weston and its clients, even despite > their noted shortcomings. I'll also go a step further and challenge anyone > who has done similar work to deny having similarly benefited from Weston. I too have spent years working on various sides of the Wayland world and can only repeat the usefullness of weston; the library, toy desktop envirnonment and sample clients. Both for help with understanding interaction with lower level APIs, and for having something to compare a protocol implementation with, and test clients on. I think the focus on correctness, both regarding protocol implementation and overall anchitecture (e.g. avoiding any UI rendering in the main thread/process), as well as show casing various KMS features, and anti-focus of end user facing features is key here. > > If anything, I think devoting more time and energy to improving Weston and > underlying layers would only serve to help the Wayland-using community. > Better documentation and better reference code lowers barriers to entry and > improves the ecosystem: this is something I know all too well from some of > the projects that I've worked on. Agreed. Jonas > > > Regards, > Mike > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
dn'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 it is > also not a compositor-specific extension. Bikeshedding the prefix to > use here would be welcome, as I don't have any good suggestions right > now. I think formalizing a set of categories, including wp_ and xdg_ and at least a third one is a good idea. I think that with a "free for all" method suggested by Pekka, where we put all the responsibility on everyone else to figure out what protocol fits under what category (because there will still, in practice, be categories, we just avoid spelling them out), we loose too much in terms of discoverability and perceived scope. It'll be harder to know what to expect. What I mean here is that it should be clear what protocols are "plumbing" (e.g. wp_viewporter), what protocols are for window management related tasks where the application aim to be portable in a sense that they will work on both fully integrated and non-integrated compositors (e.g. xdg-shell and xdg-decoration), as well what protocols are for applications that want to be a building block of a non-integrated compositor (e.g. the layer shell protocol). I don't think it's possible to avoid politics completely here, no matter how "annoying" it is, because protocol development is partly about that. There are most likely good reasons Khronos have chosen to work like this as well. A protocol support matrix will still be very useful here either way, and I expect all categories will include protocols with varying support, as so is the situation already, but it wouldn't be the only source of clarity of scope and potential adoption. We could also keep the door open for other groups of protocols, such as IVI and maybe even those for fully coupled systems like the content protection protocols that has been floating around, assuming those who write protocols agree to act as maintainers and use our versioning system. > > 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? There is also the question about what model of contribution and discussion we should use. Do we rely on merge requests, keeping discussions there, or do we stay on the mailing list using git-send-email? IMHO we should choose one or the other, not some combination where Gitlab sends E-mails to the mailing list for merge requests, as this would mean we'd end up with multiple diverging versions of the same discussion thread. Jonas > > Cheers, > Daniel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3] protocol: warn clients about some wl_output properties
On Mon, Feb 18, 2019 at 04:28:18PM +, Daniel Stone wrote: > Hi Simon, > > On Mon, 18 Feb 2019 at 16:22, Simon Ser wrote: > > On Friday, October 26, 2018 11:13 AM, Simon Ser wrote: > > > Compositors also expose output refresh rate, which shouldn't be used > > > for synchronization purposes. > > > > I'd like to bump this patch, because people apparently do use wl_output's > > refresh rate for synchronization purposes in Firefox [1]. I think it > > would be a good thing to make sure people are aware they should be using > > frame callbacks instead. > > Thanks a lot for bumping this. Patch is: > Reviewed-by: Daniel Stone This is Reviewed-by: Jonas Ådahl too. Jonas > > Cheers, > Daniel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
