[PATCH wayland-protocols] xdg-shell: fix a typo
Signed-off-by: Sebastian Krzyszkowiak --- stable/xdg-shell/xdg-shell.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml index e259a1f..2e420c6 100644 --- a/stable/xdg-shell/xdg-shell.xml +++ b/stable/xdg-shell/xdg-shell.xml @@ -101,7 +101,7 @@ The ping event asks the client if it's still alive. Pass the serial specified in the event back to the compositor by sending - a "pong" request back with the specified serial. See xdg_wm_base.ping. + a "pong" request back with the specified serial. See xdg_wm_base.pong. Compositors can use this to determine if the client is still alive. It's unspecified what will happen if the client doesn't -- 2.19.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: deprecate wl_surface.damage
On 11/5/18 7:43 AM, Simon Ser wrote: > On Monday, November 5, 2018 11:07 AM, Pekka Paalanen > wrote: >> How about writing what Derek said: that the old damage request may be >> unoptimal rather than deprecated. >> >> I don't like "deprecated" because to me it implies that this request >> will be removed (i.e. can be left unimplemented) some time in the future. > > Fair enough, I'll rephrase with words like "should" and "preferred". > > It would be nice to really deprecate this request at some point. Have we ever considered having a way to deprecate requests (beyond deprecating entire xml files like the old xdg versions)? We could generate compile time warnings and perhaps print a log message. Actually removing protocol might be kind of scary, but we can give people some way to know that they might get better performance with some changes. Or is this so infrequent an occurrence that it doesn't need to be bothered with? Thanks, Derek >> Xwayland is still using exclusively wl_surface.damage, for instance. > > Sent a patch to fix this [1]. > > [1]: https://lists.x.org/archives/xorg-devel/2018-November/057678.html > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] protocol: prefer wl_surface.damage_buffer
On 11/5/18 7:57 AM, Simon Ser wrote: > This commit makes wl_surface.damage_buffer preferred over wl_surface.damage. > wl_surface.damage can be implemented in a non-optimal way by the compositor > (e.g. by always damaging the whole buffer). > > Having two requests makes it complicated for the compositor to handle damage, > making it necessary to transform one into the other's coordinates. > > Moreover, integration with wp_viewporter is tricky. > > Signed-off-by: Simon Ser Obnoxious nitpick: for some reason that file uses different formatting than others in the repo, and 8 spaces are compressed into a single tab. Otherwise, this is: Reviewed-by: Derek Foreman > --- > protocol/wayland.xml | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 141038b..df2b6d2 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1397,9 +1397,9 @@ > and clears pending damage. The server will clear the current > damage as it repaints the surface. > > - Alternatively, damage can be posted with wl_surface.damage_buffer > - which uses buffer coordinates instead of surface coordinates, > - and is probably the preferred and intuitive way of doing this. > +Note! New clients should not use this request. Instead damage can be > +posted with wl_surface.damage_buffer which uses buffer coordinates > +instead of surface coordinates. > > > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v4] Add zwp_linux_explicit_synchronization_v1
On Monday, November 5, 2018 10:50 AM, Alexandros Frantzis wrote: > On Sat, Nov 03, 2018 at 02:44:53PM +, Simon Ser wrote: > > Hi Simon, > > > > > > + Explicit synchronization is guaranteed to be supported only > > > > > for buffers > > > > > + created with any version of the zwp_linux_dmabuf buffer > > > > > factory. > > > > > > > > I think we can drop the "z" prefix here. > > > > > > Hmm, not sure about this. We would be using a protocol prefix/name > > > combination that doesn't exist (yet). Of course the intention is clear, > > > but I think it would be better to update this to, e.g., > > > (z)wp_linux_dmabuf, when linux_dmabuf actually becomes stable. > > > > Then add the v1 suffix zwp_linux_dmabuf_v1? > > The "any version" of zwp_linux_dmabuf was meant to cover both _v* and > version="*", but I guess that's not clear enough. Perhaps "with any > version of zwp_linux_dmabuf_v*"? In any case, I am also fine with just > adding _v1 for now and updating as needed in the future. It's not uncommon to refer to the not-yet-existing stable versions of the protocols in their unstable versions. If you think all DMA-BUFs can use this protocol, use wp_linux_dmabuf. If it only applies to the unstable-v1 protocol, use zwp_linux_dmabuf_v1. > > > > > + > > > > > + > > > > > +Sent when the compositor has finalised its usage of the > > > > > associated > > > > > +buffer for the relevant commit, providing a dma_fence which > > > > > will be > > > > > +signaled when all operations by the compositor on that > > > > > buffer for that > > > > > +commit have finished. > > > > > + > > > > > +Clients must not perform any destructive operations (e.g. > > > > > clearing or > > > > > +rendering) on the buffer until that fence has signaled. > > > > > > > > We should probably add to this request and to immediate_release > > > > something among > > > > the lines of: > > > > > > > > > Upon receiving this event, the client should destroy this object. > > > > > > In v5 I am changing zwp_buffer_release to use destroy-on-event, so this > > > doesn't apply any more. Of course, the client should still destroy the > > > proxy, but I don't think this is something we need to explicitly state. > > > > Hmm. One should be careful when choosing destroy-on-event, it makes it > > impossible to add requests to the interface later on. > > We discussed a bit about this in an earlier email, and the conclusion > was that buffer_release is expected to remain a pure event interface. > It's not expected to gain any requests, or to be used as an argument to > other requests. Of course, if people have any such use cases in mind I > would be happy to hear about them and discuss further. Okay. In this case we need to make it clear which events make the compositor destroy the object. See for instance the wl_surface.frame description: The object returned by this request will be destroyed by the compositor after the callback is fired and as such the client must not attempt to use it after that point. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] protocol: prefer wl_surface.damage_buffer
On Mon, 05 Nov 2018 13:57:00 + Simon Ser wrote: > This commit makes wl_surface.damage_buffer preferred over wl_surface.damage. > wl_surface.damage can be implemented in a non-optimal way by the compositor > (e.g. by always damaging the whole buffer). > > Having two requests makes it complicated for the compositor to handle damage, > making it necessary to transform one into the other's coordinates. > > Moreover, integration with wp_viewporter is tricky. > > Signed-off-by: Simon Ser > --- > protocol/wayland.xml | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 141038b..df2b6d2 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1397,9 +1397,9 @@ > and clears pending damage. The server will clear the current > damage as it repaints the surface. > > - Alternatively, damage can be posted with wl_surface.damage_buffer > - which uses buffer coordinates instead of surface coordinates, > - and is probably the preferred and intuitive way of doing this. > +Note! New clients should not use this request. Instead damage can be > +posted with wl_surface.damage_buffer which uses buffer coordinates > +instead of surface coordinates. > > > Acked-by: Pekka Paalanen Thanks, pq pgpL9jI_LQvSI.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2] protocol: prefer wl_surface.damage_buffer
This commit makes wl_surface.damage_buffer preferred over wl_surface.damage. wl_surface.damage can be implemented in a non-optimal way by the compositor (e.g. by always damaging the whole buffer). Having two requests makes it complicated for the compositor to handle damage, making it necessary to transform one into the other's coordinates. Moreover, integration with wp_viewporter is tricky. Signed-off-by: Simon Ser --- protocol/wayland.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 141038b..df2b6d2 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1397,9 +1397,9 @@ and clears pending damage. The server will clear the current damage as it repaints the surface. - Alternatively, damage can be posted with wl_surface.damage_buffer - which uses buffer coordinates instead of surface coordinates, - and is probably the preferred and intuitive way of doing this. +Note! New clients should not use this request. Instead damage can be +posted with wl_surface.damage_buffer which uses buffer coordinates +instead of surface coordinates. -- 2.19.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: deprecate wl_surface.damage
On Monday, November 5, 2018 11:07 AM, Pekka Paalanen wrote: > How about writing what Derek said: that the old damage request may be > unoptimal rather than deprecated. > > I don't like "deprecated" because to me it implies that this request > will be removed (i.e. can be left unimplemented) some time in the future. Fair enough, I'll rephrase with words like "should" and "preferred". It would be nice to really deprecate this request at some point. > Xwayland is still using exclusively wl_surface.damage, for instance. Sent a patch to fix this [1]. [1]: https://lists.x.org/archives/xorg-devel/2018-November/057678.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: deprecate wl_surface.damage
On Mon, 05 Nov 2018 08:58:46 + Simon Ser wrote: > On Monday, November 5, 2018 9:44 AM, Pekka Paalanen > wrote: > > Hi, > > > > what good does this do, when no compositor can ever stop implementing it? > > > > I'm ok with adding a note that clients might have easier time using > > damage_buffer, but I don't see anything that would allow compositors to > > do otherwise. Err, well, that note is what you are replacing here. > > > > Whatever the compositor, it will always have to translate from one > > space to the other space, regardless of which request a client is > > using. You need the buffer space damage to be able to update textures > > (wl_shm path), and you need the surface space damage to repaint the > > screen (for framebuffer damage). > > As you said, the compositor needs to do two things with damage: (1) update > textures (buffer coords) and (2) damage outputs (surface coords). > > If we only get buffer damage from clients, then (1) is easy and (2) requires a > single region transformation. > > If we get surface damage and/or buffer damage from clients, then both (1) and > (2) require region transformations. > > As said in the commit message, surface damage interactions with wp_viewporter > are hard to understand. > > In the end, I still think having one code path for damage submission is a net > win. I don't see why clients would need to use surface damage instead of > buffer > damage. How about writing what Derek said: that the old damage request may be unoptimal rather than deprecated. I don't like "deprecated" because to me it implies that this request will be removed (i.e. can be left unimplemented) some time in the future. Xwayland is still using exclusively wl_surface.damage, for instance. Thanks, pq pgpeCA6SO7oKa.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v4] Add zwp_linux_explicit_synchronization_v1
On Sat, Nov 03, 2018 at 02:44:53PM +, Simon Ser wrote: Hi Simon, > > > > + Explicit synchronization is guaranteed to be supported only for > > > > buffers > > > > + created with any version of the zwp_linux_dmabuf buffer factory. > > > > > > I think we can drop the "z" prefix here. > > > > Hmm, not sure about this. We would be using a protocol prefix/name > > combination that doesn't exist (yet). Of course the intention is clear, > > but I think it would be better to update this to, e.g., > > (z)wp_linux_dmabuf, when linux_dmabuf actually becomes stable. > > Then add the v1 suffix zwp_linux_dmabuf_v1? The "any version" of zwp_linux_dmabuf was meant to cover both _v* and version="*", but I guess that's not clear enough. Perhaps "with any version of zwp_linux_dmabuf_v*"? In any case, I am also fine with just adding _v1 for now and updating as needed in the future. > > > > + > > > > + > > > > +Sent when the compositor has finalised its usage of the > > > > associated > > > > +buffer for the relevant commit, providing a dma_fence which > > > > will be > > > > +signaled when all operations by the compositor on that buffer > > > > for that > > > > +commit have finished. > > > > + > > > > +Clients must not perform any destructive operations (e.g. > > > > clearing or > > > > +rendering) on the buffer until that fence has signaled. > > > > > > We should probably add to this request and to immediate_release something > > > among > > > the lines of: > > > > > > > Upon receiving this event, the client should destroy this object. > > > > In v5 I am changing zwp_buffer_release to use destroy-on-event, so this > > doesn't apply any more. Of course, the client should still destroy the > > proxy, but I don't think this is something we need to explicitly state. > > Hmm. One should be careful when choosing destroy-on-event, it makes it > impossible to add requests to the interface later on. We discussed a bit about this in an earlier email, and the conclusion was that buffer_release is expected to remain a pure event interface. It's not expected to gain any requests, or to be used as an argument to other requests. Of course, if people have any such use cases in mind I would be happy to hear about them and discuss further. Thanks, Alexandros ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: I would like to learn how this project build Wayland
Hi Valentino Am 04.11.18 um 12:59 schrieb Valentino Bocchino: > Hi, > I’m Valentino, I come from Italy and I’m 14 years old. I am really interested > in learning programming languages and I thought that asking the Wayland team > how they built Wayland could be a great idea. I don’t carry any kind of > experience, so I probably can’t help to this project, but if I could learn, > then maybe one day I could become helpful. Of course, it is unlikely that I > can be physically present, but the technology that we have today enables me > to learn and help people in other places which revery distant from home. Wayland is a networking protocol, so you cannot build it (with a compiler). What you can build is Weston, the reference implementation. Have you read [1] and if so, how far did you get? If you really have no experience, you should start by reading a good book on Linux' system architecture and command-line tools; ideally while you're trying to get Weston to build. If you want to work on Linux graphics you also have to understand C. But that can wait for later. Best regards Thomas [1] https://wayland.freedesktop.org/building.html > > Have a nice day, > Valentino Bocchino > P.S.: Excuse me for my English, but because it’s my third language I’m trying > to do my best. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: deprecate wl_surface.damage
On Monday, November 5, 2018 9:44 AM, Pekka Paalanen wrote: > Hi, > > what good does this do, when no compositor can ever stop implementing it? > > I'm ok with adding a note that clients might have easier time using > damage_buffer, but I don't see anything that would allow compositors to > do otherwise. Err, well, that note is what you are replacing here. > > Whatever the compositor, it will always have to translate from one > space to the other space, regardless of which request a client is > using. You need the buffer space damage to be able to update textures > (wl_shm path), and you need the surface space damage to repaint the > screen (for framebuffer damage). As you said, the compositor needs to do two things with damage: (1) update textures (buffer coords) and (2) damage outputs (surface coords). If we only get buffer damage from clients, then (1) is easy and (2) requires a single region transformation. If we get surface damage and/or buffer damage from clients, then both (1) and (2) require region transformations. As said in the commit message, surface damage interactions with wp_viewporter are hard to understand. In the end, I still think having one code path for damage submission is a net win. I don't see why clients would need to use surface damage instead of buffer damage. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint
On Fri, 02 Nov 2018 18:38:10 +
Simon Ser wrote:
> On Friday, November 2, 2018 9:53 AM, Pekka Paalanen
> wrote:
> > > I think we want another event here, to group sets of modifiers
> > > together by preference.
> > >
> > > For example, say the surface could be directly scanned out, but only
> > > if it uses the linear or X-tiled modifiers. Our surface-preferred
> > > modifiers would be LINEAR + X_TILED. However, the client may not be
> > > able to produce that combination. If the GPU still supports Y_TILED,
> >
> > Combination? I thought modifiers are never combined with other
> > modifiers?
>
> I think Daniel refers to the format + modifier combination. Yes, modifiers
> cannot be mixed with each other.
>
> > > then we want to indicate that the client _can_ use Y_TILED if it needs
> > > to, but _should_ use LINEAR or X_TILED.
> > >
> > > DRI3 implements this by sending sets of modifiers in 'tranches', which
> > > are arrays of arrays, which in this case would be:
> > > tranches = {
> > > [0 /* optimal */] = {
> > > { .format = XRGB, .modifier = LINEAR }
> > > { .format = XRGB, .modifier = X_TILED }
> > > },
> > > [1 /* less optimal */] = {
> > > { .format = XRGB, .modifier = Y_TILED }
> > > }
> > > }
> > >
> > > I imagine the best way to do it with Wayland events would be to add a
> > > 'marker' event to indicate the border between these tranches. So we
> > > would send:
> > > modifier(XRGB, LINEAR)
> > > modifier(XRGB, X_TILED)
> > > barrier()
> > > modifier(XRGB, Y_TILED)
> > > barrier()
> > > done()
> >
> > Yeah. Another option is to send a wl_array of modifiers per format and
> > tranch.
>
> True. Any reason why this hasn't been done in the global?
For formats? Well, it is simpler without a wl_array, and there might be
a lot of formats.
Could there be a lot of modifiers per format? Would a wl_array make
anything easier? Just a thought.
>
> > I suppose it will be enough to send tranches for just the currently
> > used format? Otherwise it could be "a lot" of data.
>
> What do you mean by "the currently used format"?
This interface is used to send clients hints after they are already
presenting, which means they already have a format chosen and probably
want to stick with it, just changing the modifiers to be more optimal.
> I expect clients to bind to this interface and create a surface hints object
> before the surface is mapped. In this case there's no "currently used format".
Right, that's another use case.
> It will be a fair amount of data, yes. However it's just a list of integers.
> When we send strings over the protocol (e.g. toplevel title in xdg-shell) it's
> about the same amount of data I guess.
If the EGLConfig or GLXFBConfig or GLX visual lists are of any
indication... yes, they account for depth, stencil, aux, etc. but then
we will have modifiers.
We already advertise the list of everything supported of format+modifer
in the linux_dmabuf extension. Could we somehow minimize the number of
recommended format+modifiers in hints? Or maybe that's not a concern
for the protocol spec?
> > >
> > > For a simple 'GPU composition or scanout' case, this would only be two
> > > tranches, which are 'most optimal' and 'fallback'. For multiple GPUs
> > > though, we could end up with three tranches: scanout-capable,
> > > same-GPU-composition, or cross-GPU-composition. Similarly, if we take
> > > media recording into account, we could end up with more than two
> > > tranches.
> > >
> > > What do you think?
> >
> > At first I didn't understand this at all. I wonder if Simon is as
> > puzzled as I was. :-)
> >
> > Is the idea of tranches such that within a tranch, a client will be able
> > to pick a modifier that is optimal for its rendering? This would convey
> > the knowledge that all modifiers withing a tranch are equally good
> > for the compositor, so the client can pick what it can use the best.
> >
> > This is contrary to a flat preference list, where a client would pick
> > the first modifier it can use, even if it is less optimal than a later
> > modifer for its rendering while for compositor it would not make a
> > difference.
>
> Yeah, that's what I've understood too.
>
> > I'm also not sure I understand your tranch categories. Are you thinking
> > that, for instance, if a client uses same-GPU-composition modifers
> > which exclude cross-GPU-composition that a compositor would start
> > copy-converting buffers if the composition no longer happens on the
> > same GPU, until the client adjusts to the new preference? That makes
> > sense, if I guessed right what you meant.
>
> Right. I don't think we can do any better.
>
> > I'm wondering how the requirement "a compositor must always be able to
> > consume the buffer regardless of where it will be shown" is accounted
> > for here. Do we need a reminder about that in the spec?
>
> A reminder might be a good idea. The whole surface hints are just
Re: [PATCH] protocol: deprecate wl_surface.damage
On Sun, 04 Nov 2018 08:38:16 + Simon Ser wrote: > This commit deprecates wl_surface.damage in favor of wl_surface.damage_buffer. > > Having two requests makes it complicated for the compositor to handle damage, > making it necessary to transform one into the other's coordinates. > > Moreover, integration with wp_viewporter is tricky. > > Signed-off-by: Simon Ser > --- > > Based on the discussion in [1]. > > [1]: > https://gitlab.freedesktop.org/wayland/weston/merge_requests/41#note_74071 > > protocol/wayland.xml | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 141038b..c75ea3a 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1397,9 +1397,9 @@ > and clears pending damage. The server will clear the current > damage as it repaints the surface. > > - Alternatively, damage can be posted with wl_surface.damage_buffer > - which uses buffer coordinates instead of surface coordinates, > - and is probably the preferred and intuitive way of doing this. > + Note! This request is deprecated and should not be used in new > + clients. Instead damage can be posted with wl_surface.damage_buffer > + which uses buffer coordinates instead of surface coordinates. > > > Hi, what good does this do, when no compositor can ever stop implementing it? I'm ok with adding a note that clients might have easier time using damage_buffer, but I don't see anything that would allow compositors to do otherwise. Err, well, that note is what you are replacing here. Whatever the compositor, it will always have to translate from one space to the other space, regardless of which request a client is using. You need the buffer space damage to be able to update textures (wl_shm path), and you need the surface space damage to repaint the screen (for framebuffer damage). Thanks, pq pgphHnyrSP5gu.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
