[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 only exposed by proprietary out of > > > tree drivers; the operation types and semantics should ideally be &
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
On Mon, May 08, 2023 at 09:14:18AM +1000, Dave Airlie wrote: > On Sat, 6 May 2023 at 08:21, Sebastian Wick wrote: > > > > On Fri, May 5, 2023 at 10:40 PM Dave Airlie wrote: > > > > > > On Fri, 5 May 2023 at 01:23, Simon Ser wrote: > > > > > > > > Hi all, > > > > > > > > The goal of this RFC is to expose a generic KMS uAPI to configure the > > > > color > > > > pipeline before blending, ie. after a pixel is tapped from a plane's > > > > framebuffer and before it's blended with other planes. With this new > > > > uAPI we > > > > aim to reduce the battery life impact of color management and HDR on > > > > mobile > > > > devices, to improve performance and to decrease latency by skipping > > > > composition on the 3D engine. This proposal is the result of > > > > discussions at > > > > the Red Hat HDR hackfest [1] which took place a few days ago. Engineers > > > > familiar with the AMD, Intel and NVIDIA hardware have participated in > > > > the > > > > discussion. > > > > > > > > This proposal takes a prescriptive approach instead of a descriptive > > > > approach. > > > > Drivers describe the available hardware blocks in terms of low-level > > > > mathematical operations, then user-space configures each block. We > > > > decided > > > > against a descriptive approach where user-space would provide a > > > > high-level > > > > description of the colorspace and other parameters: we want to give more > > > > control and flexibility to user-space, e.g. to be able to replicate > > > > exactly the > > > > color pipeline with shaders and switch between shaders and KMS pipelines > > > > seamlessly, and to avoid forcing user-space into a particular color > > > > management > > > > policy. > > > > > > I'm not 100% sold on the prescriptive here, let's see if someone can > > > get me over the line with some questions later. > > > > > > My feeling is color pipeline hw is not a done deal, and that hw > > > vendors will be revising/evolving/churning the hw blocks for a while > > > longer, as there is no real standards in the area to aim for, all the > > > vendors are mostly just doing whatever gets Windows over the line and > > > keeps hw engineers happy. So I have some concerns here around forwards > > > compatibility and hence the API design. > > > > > > I guess my main concern is if you expose a bunch of hw blocks and > > > someone comes up with a novel new thing, will all existing userspace > > > work, without falling back to shaders? > > > Do we have minimum guarantees on what hardware blocks have to be > > > exposed to build a useable pipeline? > > > If a hardware block goes away in a new silicon revision, do I have to > > > rewrite my compositor? or will it be expected that the kernel will > > > emulate the old pipelines on top of whatever new fancy thing exists. > > > > I think there are two answers to those questions. > > These aren't selling me much better :-) > > > > The first one is that right now KMS already doesn't guarantee that > > every property is supported on all hardware. The guarantee we have is > > that properties that are supported on a piece of hardware on a > > specific kernel will be supported on the same hardware on later > > kernels. The color pipeline is no different here. For a specific piece > > of hardware a newer kernel might only change the pipelines in a > > backwards compatible way and add new pipelines. > > > > So to answer your question: if some hardware with a novel pipeline > > will show up it might not be supported and that's fine. We already > > have cases where some hardware does not support the gamma lut property > > but only the CSC property and that breaks night light because we never > > bothered to write a shader fallback. KMS provides ways to offload work > > but a generic user space always has to provide a fallback and this > > doesn't change. Hardware specific user space on the other hand will > > keep working with the forward compatibility guarantees we want to > > provide. > > In my mind we've screwed up already, isn't a case to be made for > continue down the same path. > > The kernel is meant to be a hardware abstraction layer, not just a > hardware exposure layer. The kernel shouldn'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
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, );
> > 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, );
> > +tp->thumb.lower_top_thumb_line = edges.y;
> > +
> > +mm.y = h * 0.08;
> > +edges = evdev_device_mm_to_units(device, );
> > +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
On Fri, Jun 10, 2022 at 10:49:31AM +0300, Pekka Paalanen wrote: > On Thu, 9 Jun 2022 19:39:39 + > Zack Rusin wrote: > > > On Wed, 2022-06-08 at 10:53 +0300, Pekka Paalanen wrote: > > > On Tue, 7 Jun 2022 17:50:24 + > > > Zack Rusin wrote: > > > > > > > On Tue, 2022-06-07 at 11:07 +0300, Pekka Paalanen wrote: > > > > > On Fri, 03 Jun 2022 14:14:59 + > > > > > Simon Ser wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > Please, read this thread: > > > > > > https://lists.freedesktop.org/archives/dri-devel/2020-March/thread.html#259615 > > > > > > > > > > > > It has a lot of information about the pitfalls of cursor hotspot and > > > > > > other things done by VM software. > > > > > > > > > > > > In particular: since the driver will ignore the KMS cursor plane > > > > > > position set by user-space, I don't think it's okay to just expose > > > > > > without opt-in from user-space (e.g. with a DRM_CLIENT_CAP). > > > > > > > > > > > > cc wayland-devel and Pekka for user-space feedback. > > > > > > > > > > > > On Thursday, June 2nd, 2022 at 17:42, Zack Rusin > > > > > > wrote: > > > > > > > > > > > > > - all userspace code needs to hardcore a list of drivers which > > > > > > > require > > > > > > > hotspots because there's no way to query from drm "does this > > > > > > > driver > > > > > > > require hotspot" > > > > > > > > > > > > Can you elaborate? I'm not sure I understand what you mean here. > > > > > > > > > > > > > > > > Hi Zack and everyone, > > > > > > > > > > I would like to try to reboot this discussion and explain where I come > > > > > from. Maybe I have misunderstood something. > > > > > > > > First of all thanks for restarting the discussions. I think Gerd > > > > did a good > > > > job responding to individual points, so let me take a step back and > > > > explain the big > > > > picture here so we can reboot. > > > > > > > > > Which root problems do you want to solve exactly? > > > > > > > > The problem that this patch set is solving is the relatively trivial > > > > problem of not > > > > having a way of setting the hotspot in the atomic kms interface. When we > > > > (virtualized drivers) are using the native cursor we need to know not > > > > only the image > > > > > > Could you clarify what is "native cursor" here? > > > I guess it is the host window system pointer's cursor? > > > > Right, exactly. I'm a little hesitant to call it "host" because it gets > > tricky in > > remote scenarios, where the host is some ESXi server but the local machine > > is the > > one that's actually interacting with the guest. So it's the cursor of the > > machine > > where the guest screen is displayed. > > > > > > > > Now, where the disagreements come from is from the fact that all > > > > virtualized drivers > > > > do not implement the atomic KMS cursor plane contract exactly as > > > > specified. In > > > > atomic kms with universal planes the "cursor" plane can be anything so > > > > asking for > > > > hotspot's for something that's not a cursor is a bit silly (but > > > > arguably so is > > > > calling it a cursor plane and then complaining that people expect > > > > cursor in it). > > > > > > > > So the argument is that we can't put hotspot data into atomic kms > > > > without first > > > > rewriting all of the virtualized drivers cursor code to fix the > > > > underlying contract > > > > violation that they all commit. That would likely be a lot easier sell > > > > if not that > > > > gnome/kde don't put none cursor stuff in the cursor plane, so all this > > > > work is to > > > > fix breakages that seem to affect 0 of our users (and I completely > > > > understand that > > > > we'd still like all the drivers to be correct and unified in terms of > > > > their > > > > behaviour, I'm just saying it's a hard sell without something that we > > > > can point to > > > > and say "this fixes/improves things for our customers") > > > > > > What's the cost of making paravirtualized drivers honour the UAPI > > > contract? > > > Can't you do that on the side of implementing these new hotspot > > > properties, with the little addition to allowing guest userspace to be > > > explicit about whether it supports commandeering or not? > > > > I'm reluctant here because "fixing" here seems to be a bit ephemeral as we > > move from > > one solution to the next. I'm happy to write a patch that's adding a > > DRM_CLIENT_CAP_VIRTUAL_CURSOR_AWARE flag and hiding the cursor plane in > > virtualized > > drivers for clients that advertise DRM_CLIENT_CAP_ATOMIC but not > > DRM_CLIENT_CAP_VIRTUAL_CURSOR_AWARE, but that doesn't solve Weston on > > virtualized > > drivers. > > Mind, I have not talked about hiding cursor planes. I have talked > *only* about stopping commandeering cursor planes if guest userspace > does not indicate it is prepared for commandeering. > > I don't understand how it does not "solve on Weston
[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: 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
On Mon, Aug 03, 2020 at 02:57:11PM +1000, Peter Hutterer wrote:
> On Sat, Aug 01, 2020 at 01:42:16PM +0200, Roman Gilg wrote:
> > >
> > > 1) It exports a set of APIs under org.freedesktop.portal.* that all
> > > sandboxed applications can access.
> > >
> > > In contrast to explicitly allowed APIs (i.e. build time configured list
> > > of API to be exposed directly to inside an application sandbox by
> > > default), a portal APIs allows for applications to dynamically request
> > > access to privileged functionality, for example access to arbitrary
> > > file system locations, cameras, geo location, or screen casting.
> >
> > That's quite a long sentence. Let me dissect it a bit. What kind of
> > API are we talking about? The xdg-portal-desktop one? Who defines the
> > "build time configured list of API"? Are we talking about the "build"
> > of the Flatpak? Is it the Manifest's "finish-args" as described this
> > way in the Flatpak documentation? [1]
>
> sort-of, there's a confusion of terms. "API" stands primarily for a DBus API
> but you'll probably think of X11 and Wayland as sockets. for the purpose
> here you can consider them as APIs as well.
>
> When you build a flatpak application, you specify what that application can
> access outside the sandbox, that's your [1] link. by default, a sandboxed
> application does not have X11 or Wayland access.
>
> you can allow access to those or any API at build time, e.g.
> --talk-name=org.freedesktop.EI would allow the application to talk to a EIS
> server directly without the portal in between. These permissions are
> compiled in and listed by the flatpak itself - they're not dynamic like the
> portal.
>
> Problem with any build-time permissions is the portal has no control over
> it. This particularly shows the issue with sockets which are a complete
> side-channel. A DBus API will be called every time
> it's needed - that allows for a gatekeeper in between. A socket, once
> established, is largely outside the control of such a gatekeeper. XTEST for
> example floats along on the rest of X, you cannot allow an application to
> use X for display but disallow XTEST in a portal, support for this would
> have to be implemented in X itself. The same would be true for a Wayland
> virtual input protocol.
>
> EI is (will be) a combination of API + socket, similar to screencasting -
> negotiation is handled by the portal but once the connection is established
> the data is outside the portal's control. We could make the communication
> fully dbus-y so we can filter at any point but I don't think that would
> provide a lot of benefit.
>
> The socket approach here is acceptable because it's very *specific* for what
> it does. It only does emulated input, so giving permission to that implies
> you want that to happen. Giving permission for X (or Wayland) does not by
> default mean you want emulated input to happen through those protocols.
>
To expand on this, a side channel can be technically relatively multi
purpose, e.g. PipeWire, which is used both for screen casting access,
camera access, and eventually microphone input, sound output etc.
To make this possible, the service provider (PipeWire) needs to
integrate with the sandbox eco system some how, and PipeWire does this
by allowing two phased initialization.
This could in theory be applied to Ei sessions too.
To summarize how access management is handled when using PipeWire, there
are currently two scenarios: screen cast and camera.
For screen casting, the portal sets up screen cast PipeWire streams.
It then creates a PipeWire remote with *only* access to these streams and
nothing else. As permissions can by the client only be restricted, and
never eased, a application cannot undo the restrictions and will thus
only ever see the screen casts it opened using the opened PipeWire file
descriptor.
For camera access, the portal opens up a PipeWire remote, it sets some
metadata ("app-id", and allowed "media roles" (i.e. "Camera")), then
locks down permission to not grant access to anything at all.
It then relies on the PipeWire session manager to know that a remote is
opened by the portal, and then open up access to devices by looking at
the metadata the portal set as well as what's in the permission store.
>
> > > 2) It provides, using backends, methods for implementing user
> > > interactive permission management. For arbitrary file system access,
> > > this may involve e.g. opening a file using a file selection dialog, or
> > > for screen casting this may mean actively choosing what part of your
> > > screen 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
Re: RFC: libei - emulated input in Wayland compositors
On Fri, Jul 31, 2020 at 08:49:41PM +0200, Roman Gilg wrote: > On Fri, Jul 31, 2020 at 7: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. > > > > The proposal I have is a library for Emulated Input, in short libei. > > https://gitlab.freedesktop.org/whot/libei/ > > We talked about it already yesterday but thanks again for this great > project. I decided to directly write some experimental integration > code based on your Weston branch for the server library in KWinFT [1] > in order to try this out as a solution for my Steam Controller issue > [2] that - I assume - motivated the creation of this library to some > extent. > > And yes, it works. :) I can move the cursor with the Steam controller > as in "Steam client -> XTEST -> patched Xwayland -> libei -> libeis -> > KWinFT" just fine. > > Am I right in assuming that the button-press event is not yet done in > libei or in the patched Xwayland version you linked? When it's > available let me know and I'll add the necessary logic for that too. > > > 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. > > > > Now, the next question is: how do they *start* talking to each other? > > libei provides multiple backends for the initial connection negotiation. My > > goal is to have this work with flatpak portals so an application running > > within the sandbox can be restricted accordingly. Alternatives to this could > > be public DBus interfaces, simple fd passing or (as is implemented right > > now) a named unix socket. > > Wiring this somehow through portals would be important for sure. > Xwayland as a client could either be accepted by default or if > Olivier's Xwayland xdg-portal patches [3] land (with the additional > portal for libei) only be accepted after the user confirmed it just > like every other sandboxed client. > > That being said the envisioned permission model is still somewhat > difficult for me to grasp. To reiterate: the access of sandboxed > clients can be accepted or rejected by the user. But to my > understanding that's a function of the xdg-portal itself. You said the > compositor can filter requests too. Can it only allow libei > connections through xdg-portals and Xwayland? What about other > clients, how can they be distinguished from xdg-portals and Xwayland > securely? Or is this only possible for flatpaked clients? Or is such a > client blocked from trying to do that anyway (in other words is it > allowed or not to connect to arbitrary sockets like the libei one)? > > As it is probably clear now the overall concept of xdg-portals in > detail is still not very well understood by me. From conversations I > had lately with other windowing system developers I believe I'm not > the only one. > > Since xdg-portals become more and more important for securing our > graphical sessions it would be great if someone with more knowledge > about it could create some kind of article or documentation about it > that looks at it from the perspective of windowing systems . How do > apps in/out of Flatpaks that display their pixels through X11, > Xwayland or Wayland directly work in respect to the sandboxed > environment provided by xdg-portals? What does this
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
On Wed, Apr 08, 2020 at 07:07:19PM +1200, Scott Anderson wrote: > On 8/04/20 4:04 pm, Erik Jensen wrote: > > Hello, > > > > I'm currently looking into how best to continue supporting Linux for > > Chrome Remote Desktop given the current direction of development for > > graphical sessions on Linux, and would like some community feedback as > > to the best path forward. > > > > Chrome Remote Desktop currently works on Linux by spinning up its own > > Xvfb server and running a graphical session in that. However, as more > > and more parts of the stack assume that a user will have at most one > > graphical session, this is leading to more breakage more often. E.g., > > several distros have switched DBUS to using a single session bus per > > user, which only supports one graphical session, and recent versions > > of GDM will fail to log a user in locally at all if a Chrome Remote > > Desktop session is running due to > > https://gitlab.gnome.org/GNOME/gdm/-/issues/580. Given that Chrome > > Remote Desktop starts at boot, the latter means that even just setting > > it up and rebooting is enough to break local logins for the user, > > which is obviously less than ideal. > > This point about Gnome breaking multiple sessions has been a pain point for > us (sway/wlroots), and why we typically push back against D-Bus solutions to > Wayland problems, at least on the session bus. Wayland itself works > perfectly fine with multiple sessions, and is something we want to preserve. > > It may be possible to create individual session buses for each login > session, but I don't know how this works in practice and I don't think > anybody currently does it. The dependency on a functional D-Bus session bus is in practice a necessity in a modern desktop environment today on Linux; it would be counter productive to try to avoid solving any possible issues related to it to run multiple separate sessions, since so much is using it. For example anything using GtkApplication or GApplication will use the session bus, anything related to accessibility uses D-Bus (although on its own bus), any sandboxed appliction using the portal APIs (including properly sandboxed flatpak and snap applications) will use the session bus, desktop notifications uses the session bus. With that being said, it is possible to run multiple D-Bus sessions, where session busses are separate - it's just that noone actually does it as even if you have separate D-Bus sessions, separate $XDG_RUNTIME_DIRs, the sessions still share fundamental resources such as $HOME, and it is very likely that many applications you attempt to run will run into issues where they, running on separate "sessions" on the same user, will try to manage the same set of files in the users home directory. Thus, the only way to get reliable truly parallel sessions is to use separate users, or separate $HOME directories, where the two sessions do not share any managed resources at all. Whether there is a point in using the same user with separate $HOME directories is desired I doubt. > > > We have the following constraints for our use case: > > * Chrome Remote Desktop must be usable after boot without the user > > needing to log in locally, first. > > * It must be possible to "curtain" the session, meaning that, when a > > user is connected, their session is not displayed on the local > > monitor. (Imagine a user working from home and connecting to their > > workstation in a shared office space.) > > * When the user disconnects, the session must be locked in some > > manner so a person at the local machine can't take over the session > > without authentication. > > * It's okay to require X11 today, but there should be a reasonable > > path forward as more distributions switch to Wayland. > > * It would be nice, though not required, if the user could access the > > same session remotely as they see locally. (Though, as noted above, > > having two separate sessions seems to be explicitly not supported by > > many new developments, so this may be effectively required.) > > * It would be nice, though not required, if the session could be > > resized to fit the client display when the user is connected remotely. > > * It would be nice, though not required, if apps in the session could > > have access to graphics acceleration when accessed remotely. > > > > Possible idea brainstorming: > > I'm hoping for feedback for the feasibility of these, given I don't > > have a lot of experience with Wayland or the modern graphical session > > architecture. All of these have gaps which make them likely not usable > > *right now*, so the question is probably which approach would be the > > most likely to be accepted by the relevant projects, and potentially > > which would be the quickest to design and get working. > > > > There's likely other possibilities that I haven't thought of. > > > > ~Use a nesting compositor~ > > This involves having an outer compositor that we control that
Re: Plumbing explicit synchronization through the Linux ecosystem
On Mon, Mar 16, 2020 at 10:37:04PM -0500, Jason Ekstrand wrote: > On Mon, Mar 16, 2020 at 6:39 PM Roman Gilg wrote: > > > > On Wed, Mar 11, 2020 at 8:21 PM Jason Ekstrand wrote: > > > > > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand > > > wrote: > > > > > > > > All, > > > > > > > > Sorry for casting such a broad net with this one. I'm sure most people > > > > who reply will get at least one mailing list rejection. However, this > > > > is an issue that affects a LOT of components and that's why it's > > > > thorny to begin with. Please pardon the length of this e-mail as > > > > well; I promise there's a concrete point/proposal at the end. > > > > > > > > > > > > Explicit synchronization is the future of graphics and media. At > > > > least, that seems to be the consensus among all the graphics people > > > > I've talked to. I had a chat with one of the lead Android graphics > > > > engineers recently who told me that doing explicit sync from the start > > > > was one of the best engineering decisions Android ever made. It's > > > > also the direction being taken by more modern APIs such as Vulkan. > > > > > > > > > > > > ## What are implicit and explicit synchronization? > > > > > > > > For those that aren't familiar with this space, GPUs, media encoders, > > > > etc. are massively parallel and synchronization of some form is > > > > required to ensure that everything happens in the right order and > > > > avoid data races. Implicit synchronization is when bits of work (3D, > > > > compute, video encode, etc.) are implicitly based on the absolute > > > > CPU-time order in which API calls occur. Explicit synchronization is > > > > when the client (whatever that means in any given context) provides > > > > the dependency graph explicitly via some sort of synchronization > > > > primitives. If you're still confused, consider the following > > > > examples: > > > > > > > > With OpenGL and EGL, almost everything is implicit sync. Say you have > > > > two OpenGL contexts sharing an image where one writes to it and the > > > > other textures from it. The way the OpenGL spec works, the client has > > > > to make the API calls to render to the image before (in CPU time) it > > > > makes the API calls which texture from the image. As long as it does > > > > this (and maybe inserts a glFlush?), the driver will ensure that the > > > > rendering completes before the texturing happens and you get correct > > > > contents. > > > > > > > > Implicit synchronization can also happen across processes. Wayland, > > > > for instance, is currently built on implicit sync where the client > > > > does their rendering and then does a hand-off (via wl_surface::commit) > > > > to tell the compositor it's done at which point the compositor can now > > > > texture from the surface. The hand-off ensures that the client's > > > > OpenGL API calls happen before the server's OpenGL API calls. > > > > > > > > A good example of explicit synchronization is the Vulkan API. There, > > > > a client (or multiple clients) can simultaneously build command > > > > buffers in different threads where one of those command buffers > > > > renders to an image and the other textures from it and then submit > > > > both of them at the same time with instructions to the driver for > > > > which order to execute them in. The execution order is described via > > > > the VkSemaphore primitive. With the new VK_KHR_timeline_semaphore > > > > extension, you can even submit the work which does the texturing > > > > BEFORE the work which does the rendering and the driver will sort it > > > > out. > > > > > > > > The #1 problem with implicit synchronization (which explicit solves) > > > > is that it leads to a lot of over-synchronization both in client space > > > > and in driver/device space. The client has to synchronize a lot more > > > > because it has to ensure that the API calls happen in a particular > > > > order. The driver/device have to synchronize a lot more because they > > > > never know what is going to end up being a synchronization point as an > > > > API call 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 > >
[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
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, "gtk_shell1", 3, new id [unknown]@15) > [1621975.972] wl_registry@2.global(14, "wp_viewporter", 1) > [1621975.982] wl_registry@2.global(15, "zwp_pointer_gestures_v1", 1) > [1621975.991] -> wl_regis...@2.bind(15, "zwp_pointer_gestures_v1", 1, new id > [unknown]@16) > [1621976.005] wl_registry@2.global(16, "zwp_tablet_manager_v2", 1) > [1621976.014] -> wl_regis...@2.bind(16, "zwp_tablet_manager_v2", 1, new id > [unknown]@17) > [1621976.028] wl_registry@2.global(17, "wl_seat", 5) > [1621976.038] -> wl_regis...@2.bind(17, "wl_seat", 5, new id [unknown]@18) > [1621978.926] ->
[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 +1183,41
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 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.
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()
[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 be seen as > atomic, even if they happen via multiple events
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 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.22.0 > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org
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
On Fri, Jun 21, 2019 at 02:26:02PM -0400, Drew DeVault wrote: ... > > > On Wed, Jun 19, 2019 at 10:52:32AM -0400, Drew DeVault wrote: > > > 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 don't think xdg-foreign is especially different from > xdg-toplevel-management so far as the applicability of this definition > is concerned. It comes across as seeing XDG as suitable for anything > GNOME et al needs it for, and unsuitable for things wlroots et al needs > it for (though perhaps unconsciously). I think this is derived from the > fundamental philosophical differences between our design approaches, but > not necessarily from the definition of "XDG". > Both from a use case perspective, technical perspective and philosophical perspective, xdg-foreign and wlr-foreign-toplevel-management are fundamentally different. xdg-foreign allows two tightly coupled clients to act as a single application. For example lets say a GTK application has a Qt plugin and want to let the Qt plugin provide its own settings dialog, xdg-foreign is the glue that makes this possible. Or for example KDE applications wanting to use GTK file dialogs or vice versa. The GTK file dialog cannot easily use the same Wayland connection, so while technically they are two different clients, it's still the same application. The in-use application of this (that I'm aware of) is out-of-process file dialogs via portals; not that different from how native file dialogs would work. The important part here is that it's meant for an arbitrary application to have the tools available to implement it's user interface. It doesn't break general client isolation; it doesn't try to become a managing part of the desktop environment. wlr-foreign-toplevel-manager, on the other hand, is a protocol that 1) breaks client isolation - it exposes toplevel surfaces of all other clients, and 2) enables a client to act as a window manager - it lets the client maximize/move/close/.. any other toplevel surface. > Put another way, what are some protocols GNOME would implement which are > (1) useful for other compositors and (2) more suited to the ext > namespace than the xdg namespace? I find this very irrelevant, as this is not what is generally useful to whom, but more about portability and setting expectations. Either way, one potential protocol that has come up is the input method protocol, and maybe others too. > > > 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. > > Again referring to the xdg-foreign protocol, an argument could be made > that the sandboxing tooling it was designed for is a feature of the > compositor. After all, the sandboxing mechanism holds a privileged > position on the desktop model, and xdg-foreign is a mechanism it uses > for plumbing its way around self-imposed constraints, rather than an > inherent property of application windows. > > I'm not arguing that xdg-foreign isn't suitable for the XDG namespace, > but rather showing that a similar argument against > xdg-toplevel-management's inclusion can be applied to xdg-foreign. > > I guess, in short, I feel that xdg-toplevel-management is a fit for the > XDG namespace because: > > - It's more or less a direct extension of the xdg-shell protocol I really don't see it having anything in common with it other than it has the concept of toplevels. xdg-shell is a protocol allowing applications to configure its own windows, wlr-foreign-toplevel-manager is a protocol for creating window management like desktop components. > - It deals entirely with the management of application windows > > The argument against comes across as: > > - It's not something fully integrated desktops would use > > Which to me feels like gatekeeping the xdg namespace. I want to > establish namespaces based on consistent rationale that we can all > incorporate our work into, and that's probably going to mean being > somewhat 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
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. > > > > Is it really necessary with
Re: wayland-protocols scope and governance
On Sun, May 05, 2019 at 08:41:27PM -0400, Drew DeVault wrote: > Here's an updated governance document for everyone to consider. Changes > from the first version: > > - Use wayland-devel instead of a dedicated mailing list > - Use Gitlab for reviewing new protocols > - Extend discussion period for governance amendments from 30 days to 60 > - Permit either 1 or 2 points of contact for a wayland-protocols member > - Clarify who's affected by the cool-down period after a failed > membership removal vote > > I chose not to change the wording of the xdg namespace definition, > despite Daniel's objection. I couldn't come up with a wording that I > think would make everyone happy - feedback welcome. Under Daniel's > proposed wording of "catch-all window management", a case is easily made > for wlr-foreign-toplevel-management: > > https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml > > I expect this would be controversial. Or perhaps it wouldn't be, and > would fit into this namespace, but would just be NACK'd by some folks. > Depends on how strongly integrated desktop folks want to gatekeep the > XDG namespace. Thoughts? > > 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"). 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. > 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. > 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
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
On Tue, Feb 19, 2019 at 04:50:27PM +, Daniel Stone wrote: > Hi all, > I'd like to open up a discussion on enlarging wayland-protocols to a > wider audience, with a better definition of what it contains. > > Currently, wayland-protocols is a relatively small set of protocols > which were either grandfathered in from Weston, or a semi-opinionated > set of protocols that someone thinks is 'good'. > > The original intent was to provide a set of 'blessed' desktop > protocols which 'everyone' would probably implement in order to > provide a coherent Wayland environment. To some extent - xdg-shell, > dmabuf, xdg-output, viewporter - this succeeded. For some others, it > failed badly - the input protocols no-one likes or has implemented, > necessitating Dorota's rewrite. > > The elephant in the room is extensions like layer-shell and some of > the related extensions to build a desktop environment from a set of > disparate clients using generic APIs. Personally I think the > experience of X11 shows it's only designing for pain, and this is the > general position of wayland-protocols at the moment. But on the other > hand, those protocols aren't going away, they are in use, and having > them developed in a separate siloed community is doing us all a > disservice, since neither hand fully knows what the other is doing. > Even if we don't agree on the fundamentals of the protocol, we could > at least discuss it and try to point out some pitfalls and make some > suggestions for improvement. > > A related issue is that it's hard for both application and compositor > authors to figure out what to do. There is no good 'big picture' on > how these protocols fit together, nor can people figure out which of > the competing proposals they should be using if they want to write an > application running on a given compositor, nor can compositor authors > figure out what apps want them to support. Depending on who happens to > be paying attention to the particular forum the question is asked, > they might get very different answers, depending on the point of view > of who answers. > > My first, hopefully uncontroversial, suggestion: introduce a list of > compositors / compositor frameworks, as well as clients / client > frameworks, and which protocols they use and support. This would help > both application and compositor authors figure out where they should > invest time and effort. I suggest that we keep this lightweight: have > a registry of compositors / compositor frameworks / toolkits / > clients, each with a couple of named people who can speak > authoritatively for that project. > > We could then allow each project to declare its support (or otherwise) > for any extension: will not ever implement, implementation not > planned, no opinion or N/A, implementation planned, implemented but > use not recommended (or limited/stubbed), implemented and recommended. > This list would be machine-parseable (XML, JSON, YAML, whatever is > easiest to fit), with a GitLab CI pipeline used to generate a > https://wayland.freedesktop.org/protocols/ website on every push, > which gave both a per-extension and a per-project support table. And > some more readable docs. I think this would be a really good entry > point and clear up a lot of confusion. > > As a strawman list of projects to begin with (I'm sure there are others): > - compositors and compositor frameworks: Chromium (Exosphere), > Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots > - toolkits: EFL, GTK, Qt > - media: GStreamer, Kodi, VLC, XBMC > - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan) I too agree that this is a good idea. I'm not too sure about the usefulness listing all applications that may use some protocol or another. Might make more sense to keep such a list in a less formal place like a wiki page on gitlab. For a compositor protocol support matrix, I see the value as much higher. > > My second suggestion is to formalise the 'xdg' namespace. xdg > extensions have been accepted or rejected by rough consensus between > Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough > to me, assuming that 'xdg' retains the focus of an integrated (as > opposed to build-it-yourself) desktop. The IVI namespace would > similarly be delegated to automotive people, and maybe we could > delegate the layer_ namespace to those developers as well. > > My third suggestion is to formalise the 'wp' namespace, as core > extensions that everyone can agree on. It doesn't mean everyone needs > to implement them, but at least not have active opposition. For > example, Mutter hadn'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
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
Re: [PATCH wayland-protocols v2] pointer-gestures: add a release request
On Mon, Jan 28, 2019 at 08:33: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 > --- > > Changes in v2: rename to release, thanks Jonas for pointing this mistake out. > > .../pointer-gestures-unstable-v1.xml| 13 ++--- > 1 file changed, 10 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..dd9a52e 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,16 @@ > > > We usually add a + + + + +... to make it clearer what is part of a new version. With that fixed, this is Reviewed-by: Jonas Ådahl Jonas > + > + > + > + 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 +109,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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] pointer-gestures: add a destroy request
IIRC you need to call the request something else (e.g. release, used in similar situations), as wayland-scanner already generated the destructor zwp_pointer_gestures_v1_destroy() which doesn't make any request but still destructs client side. When we move to the protocol to stable, we can name it destroy() however. Jonas On Sun, Jan 27, 2019 at 03:42:08PM +, Simon Ser wrote: > This allows clients to destroy a gesture object before they disconnect. > > Signed-off-by: Simon Ser > --- > .../pointer-gestures-unstable-v1.xml| 13 ++--- > 1 file changed, 10 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..023601f 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,16 @@ > > > > + > + > + > + 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 +109,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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v4] protocol: Define further the behavior of input on the presence of grabs
On Thu, Jan 17, 2019 at 05:27:44PM +0200, Pekka Paalanen wrote: > Hi all, > > I noticed that this patch did not land yet. I added to CC everyone who > commented on the v3 I believe. > > Is this still relevant? I'd say it's good clarifications, and making it possible to "leave" touch points is still more correct than "up":ing or "cancel":ing them. Just one minor comment about wording below. > > > Thanks, > pq > > On Fri, 27 Jan 2017 18:46:58 +0100 > Carlos Garnacho wrote: > > > The leave events in the respective device interfaces has been further > > documented so those can convey the necessary info when input is being > > redirected out of their currently focused surface. > > > > Only wl_touch is missing something semantically similar, a wl_touch.leave > > event has been added so the touch interface can cope with such input > > redirection situations on individual touchpoints. > > > > Signed-off-by: Carlos Garnacho > > Reviewed-by: Peter Hutterer > > --- > > > > Changes since v3: Applied wording improvements from Yong Bakos, added > >the clarification suggested by Daniel, and made wl_touch.leave part of > >wl_touch.frame as suggested by Jonas (and that was the intended > > behavior). > > > >Also went ahead and bumped wl_seat version again to 7, since this is not > >1.13 material. > > > > protocol/wayland.xml | 68 > > ++-- > > 1 file changed, 66 insertions(+), 2 deletions(-) > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 29b63be..7be23ec 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -1651,7 +1651,7 @@ > > > > > > > > - > > + > > > >A seat is a group of keyboards, pointer and touch devices. This > >object is published as a global during start up, or when such a > > @@ -1839,6 +1839,23 @@ > > > > The leave notification is sent before the enter notification > > for the new focus. > > + > > + While a pointer will not usually leave a surface while a button > > + is pressed, there are circumstances where this event may occur, > > + such as: > > + > > + - When a popup is shown by this or another client. > > + - When a drag-and-drop operation is initiated from this or > > + any other surface. > > + - Other compositor-specific grabs, like pointer gestures. > > + > > + In these situations, a leave event will be emitted with no > > + paired button release event on this surface, and clients must > > + undo their internal state related to the ongoing button presses. > > + > > + Clients must either receive a release or a leave event in a > > + timely manner, and strictly before all other input events from > > + that seat. Clients can't "must" receive anything, a compositor either will or it wont. Also is the "all other input evets from the seat" intentional? Or should it be "all other pointer events from that seat"? Jonas > > > > > > > summary="surface left by the pointer"/> > > @@ -1880,6 +1897,10 @@ > > kernel's event code list. All other button codes above 0x are > > currently undefined but may be used in future versions of this > > protocol. > > + > > + Clients should note that pressed/released events may not be paired; > > + in some cases, a leave event will be sent in place of a released event. > > + See wl_pointer.leave for more details. > > > > > > > > @@ -2127,6 +2148,17 @@ > > > > The leave notification is sent before the enter notification > > for the new focus. > > + > > + There may be circumstances that force the keyboard focus to be taken > > + away from a surface while there are pressed keys, for example: > > + > > + - When a popup is shown by this or another client. > > + - When a drag-and-drop operation is initiated from this or > > + any other surface. > > + > > + In these situations, a leave event will be emitted with no paired > > + key release events on this surface, and clients must undo their > > + internal state related to the ongoing key presses. > > > > > > > summary="surface that lost keyboard focus"/> > > @@ -2145,6 +2177,10 @@ > > A key was pressed or released. > > The time argument is a timestamp with millisecond > > granularity, with an undefined base. > > + > > + Clients should note that pressed/released events may not be paired; > > + in some cases, a leave event will be sent in place of a released event. > > + See wl_keyboard.leave for more details. > > > > > > > > @@ -2194,7 +2230,7 @@ > > > > > > > > - > > + > > > >The wl_touch interface represents a touchscreen > >associated with a seat. > > @@ -2226,6 +2262,10 @@ > > The touch point has disappeared. No further events will be sent for > > this touch point and the touch point's ID is released and may be > >
Re: [PATCH wayland-protocols] unstable: add xcursor-configuration
On Mon, Dec 10, 2018 at 02:10:30PM +, Simon Ser wrote: > On Monday, December 10, 2018 2:51 PM, Jonas Ådahl wrote: > > There is an alternative more generic solution to this problem, and all > > other related to what XSettings did in the past. If we'd end up > > introducing a protocol like this, we might end up with many tiny > > protocols for things previously covered by XSettings. Cursor things, > > font things, and what not. Adding a new protocol for each these things > > would be silly. > > > > The generic alternative is designed with sandboxing in mind (but > > of course doesn't require it in any way), and is part of > > xdg-desktop-portal, the same place where the compositor agnostic > > screen casting API lives (org.freedesktop.portal.ScreenCast, implemented > > at least by GNOME and KDE). > > > > It's a D-Bus API called org.freedesktop.portal.Settings[0]. The only > > thing a compositor would need to do is to provide a > > org.freedesktop.impl.portal.Settings implementation using whatever > > settings backend might be in place. > > Hi, > > Unfortunately I don't think D-Bus is a good solution here. Here are a few > reasons why: > > * Not all clients use D-Bus. Adding support for your API would mean adding a > lot > of code and new dependencies to many clients. This reason comes up everytime D-Bus is mentioned, and I think it's somewhat counter productive; I don't think this is a problem clients should try to avoid so hard. D-Bus is more or less the universal IPC on Linux, is used quite extensively to allow sandboxed client to communicate with the outside world, and is almost guaranteed to be available everywhere. > * The idea would be to add support to libwayland-cursor so that many users can > benefit from the protocol. I don't think firing up a D-Bus connection in > libwayland-cursor as a viable solution. Well, we could still have applications feed settings into it. It's not tha complex to do that, and the addition to libwayland-cursor that is arguably more complicated could cover the server side cursor buffer loading that was talked about before. > * Multi-seat support would be kind of alien. Can at least be investigated how multi seat should be achieved before being dismissed as being alien like. I can open issues for that if you'd there is interest. Jonas > > What do you think? > > Thanks, > > Simon > > > > > Jonas > > > > > > [0] > > https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Settings.xml ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
