Re: [PATCH] linux-dmabuf: un-deprecate format events
I agree using DRM_FORMAT_MOD_INVALID for implicit modifier is simplest. Let's move the discussion to the other patch which does that. On Fri, Apr 12, 2019 at 2:17 AM Pekka Paalanen wrote: > On Thu, 11 Apr 2019 15:33:06 -0700 > Chia-I Wu wrote: > > > On Thu, Apr 11, 2019 at 7:12 AM Simon Ser wrote: > > > > > On Thursday, April 11, 2019 11:48 AM, Pekka Paalanen < > ppaala...@gmail.com> > > > wrote: > > > > > At first read of your commit message, I got the feeling you want > > > > formats to be advertised by both events: format event to declare a > > > > format at all, plus modifier events to list any modifiers. That is > also > > > > what your proposed spec text reads, so I'd recommend clarifying that > > > > implementations need to send only one of the two events per format. > Or > > > > both if the same format can be used with and without a modifier? > > > > > Your interpretation is correct: format events are for formats, and > modifier > > events are for modifiers. > > > > This is more intuitive comparing to Weston's. > > Hi, > > I disagree. Your design raises the question: what does it mean if there > is a 'modifier' event with a format that was not in a 'format' event? > > If you want to forbid that, you need to write it down. > It is written down. > > It also makes the 'format' event completely redundant if there is a > 'modifier' event for the same format. This is quite likely the reason > why 'format' event was deprecated. > > If you insist on keeping the 'format' event, then it should be > formulated like this: > > - send 'format' event for a format that is usable without an explicit > modifier > > - send 'modifier' event for a format that is usable with the given > explicit modifier > > - sending 'modifier' event does not directly imply that also 'format' > event must be sent, because the two have different meanings. > > However, for the reason mentioned below, that will make the format > advertisement asymmetric with creating buffers. > > > > > If we have two events, one without and one with a modifier, should we > > > > also then have two (well, four actually, for the immed variant) > > > > requests to create a buffer: one without and one with a modifier? I > > > > think it would be nice to have these consistent unless there is a > > > > reason not to. > > > > > > > > I can find justification both ways, and whether we need to fix Weston > > > > or Mutter is not that important to me. I might want to avoid the four > > > > create requests case though. > > > > > > I agree that either way, some compositors will need to be fixed, and > that > > > we > > > shouldn't decide based on current implementations. > > > > At the advertising phase, supported formats and modifiers are > unambiguously > > advertised. > > > > At the creation phase, you are right that it is hard to express the > intent > > to create a buffer with implicit modifier. I think it is best to add a > new > > bit to flags, to express the intent unambiguously. > > A flag for "ignore argument m" does avoid the proliferation of > requests, but it seems redundant. DRM_FORMAT_MOD_INVALID has a unique > definition that cannot conflict with anything else, so we can as well > use that. If one passes the flag to use implicit modifiers, then we > should also require the modifier argument to be DRM_FORMAT_MOD_INVALID > anyway for the same reason you want the flag: clarity. > Yes. Explicit, implicit, and invalid can all be separated for clarity, if we model after the kernel. > > > > I'm not sure the versioning fully works out, if we have: > > > > - version 1 and 2 have only 'format' event > > > > - version 3 has 'modifier' event, with 'format' event not to be used > > > > - version 4 wants to use both 'modifier' and 'format' events > > > > > > Yeah, that would be a little bit annoying. > > > > > > > > Implementation would need to adhere to these, so Mutter would still > > > > need fixing for clients that bind version 3. I don't think we should > > > > retro-actively change the semantics of an existing version. > > > > > > If the protocol isn't ambiguous, it would be dangerous to change > semantics > > > indeed. > > > > > When it comes to implementations, my view is > > > > v1/v2: `format' event > > v3: add `modifier' event and `format' event becomes optional (i.e., > > clients ignores it) > > v4: `format' should not be optional > > > > An implementation can support all versions by always sending `format' > > events, and only send modifier events when version >= 3. A client can > pick > > any version that suits it. > > One more detail: v3 'modifier' events for formats using the implicit > modifier must be sent with DRM_FORMAT_MOD_INVALID. Otherwise a > compositor has no way to advertise a format with the implicit modifier > as clients will ignore the 'format' event. > > > > > I notice that currently the modifier is in > > > > zwp_linux_buffer_params_v1.add request which makes the modifier > > > > per-plane, but I seem to recall tha
Re: [PATCH] linux-dmabuf: un-deprecate format events
On Thu, 11 Apr 2019 15:33:06 -0700 Chia-I Wu wrote: > On Thu, Apr 11, 2019 at 7:12 AM Simon Ser wrote: > > > On Thursday, April 11, 2019 11:48 AM, Pekka Paalanen > > wrote: > > > At first read of your commit message, I got the feeling you want > > > formats to be advertised by both events: format event to declare a > > > format at all, plus modifier events to list any modifiers. That is also > > > what your proposed spec text reads, so I'd recommend clarifying that > > > implementations need to send only one of the two events per format. Or > > > both if the same format can be used with and without a modifier? > > > Your interpretation is correct: format events are for formats, and modifier > events are for modifiers. > > This is more intuitive comparing to Weston's. Hi, I disagree. Your design raises the question: what does it mean if there is a 'modifier' event with a format that was not in a 'format' event? If you want to forbid that, you need to write it down. It also makes the 'format' event completely redundant if there is a 'modifier' event for the same format. This is quite likely the reason why 'format' event was deprecated. If you insist on keeping the 'format' event, then it should be formulated like this: - send 'format' event for a format that is usable without an explicit modifier - send 'modifier' event for a format that is usable with the given explicit modifier - sending 'modifier' event does not directly imply that also 'format' event must be sent, because the two have different meanings. However, for the reason mentioned below, that will make the format advertisement asymmetric with creating buffers. > > > If we have two events, one without and one with a modifier, should we > > > also then have two (well, four actually, for the immed variant) > > > requests to create a buffer: one without and one with a modifier? I > > > think it would be nice to have these consistent unless there is a > > > reason not to. > > > > > > I can find justification both ways, and whether we need to fix Weston > > > or Mutter is not that important to me. I might want to avoid the four > > > create requests case though. > > > > I agree that either way, some compositors will need to be fixed, and that > > we > > shouldn't decide based on current implementations. > > At the advertising phase, supported formats and modifiers are unambiguously > advertised. > > At the creation phase, you are right that it is hard to express the intent > to create a buffer with implicit modifier. I think it is best to add a new > bit to flags, to express the intent unambiguously. A flag for "ignore argument m" does avoid the proliferation of requests, but it seems redundant. DRM_FORMAT_MOD_INVALID has a unique definition that cannot conflict with anything else, so we can as well use that. If one passes the flag to use implicit modifiers, then we should also require the modifier argument to be DRM_FORMAT_MOD_INVALID anyway for the same reason you want the flag: clarity. > > > I'm not sure the versioning fully works out, if we have: > > > - version 1 and 2 have only 'format' event > > > - version 3 has 'modifier' event, with 'format' event not to be used > > > - version 4 wants to use both 'modifier' and 'format' events > > > > Yeah, that would be a little bit annoying. > > > > > Implementation would need to adhere to these, so Mutter would still > > > need fixing for clients that bind version 3. I don't think we should > > > retro-actively change the semantics of an existing version. > > > > If the protocol isn't ambiguous, it would be dangerous to change semantics > > indeed. > > > When it comes to implementations, my view is > > v1/v2: `format' event > v3: add `modifier' event and `format' event becomes optional (i.e., > clients ignores it) > v4: `format' should not be optional > > An implementation can support all versions by always sending `format' > events, and only send modifier events when version >= 3. A client can pick > any version that suits it. One more detail: v3 'modifier' events for formats using the implicit modifier must be sent with DRM_FORMAT_MOD_INVALID. Otherwise a compositor has no way to advertise a format with the implicit modifier as clients will ignore the 'format' event. > > > I notice that currently the modifier is in > > > zwp_linux_buffer_params_v1.add request which makes the modifier > > > per-plane, but I seem to recall that in practise modifiers are nowadays > > > used only per-buffer, not per-plane, so the modifier argument should > > > move to the create and create_immed requests. > > > > You're right, modifiers are now per-buffer and not per-plane. > > > This diverges from what EGL and kernel do. If we are sure it will be fine > down the road, I am fine with it. Don't both kernel and EGL implementations require all modifiers of planes to be equal? Was it not considered a mistake to have per-plane modifiers in both APIs? The current prot
Re: [PATCH] linux-dmabuf: un-deprecate format events
On Thu, Apr 11, 2019 at 7:12 AM Simon Ser wrote: > On Thursday, April 11, 2019 11:48 AM, Pekka Paalanen > wrote: > > Hi, > > > > at first hand, I would keep Weston's behaviour, because that is what > > the current protocol specification says exactly. The specification text > > is very clear on the intent: the old format event is not to be used, if > > both the client and server support the version with the modifier event. > > When the protocol will be stabilized (which is always an ABI break), > > the format event without a modifier will be removed. > v3 does not consider implicit modifiers as it seems (and Weston uses the DRM_FORMAT_MOD_INVALID hack). I don't think this is a good justification. > > > The difference to EGL API does not seem to be making anything more > > difficult either. > > > > Technically there is little difference between using two events with > > and without a modifier, and one event with a special no-modifier value. > > A technical reason to favour two different events would be bandwidth > > saving, since then one doesn't need to send the dummy modifier. Can we > > make that argument? If yes, that would be a good justification to make > > the change you propose. > > Do we have a lot of these? My machines don't have any (i915 driver). > No, bandwidth should not be a concern. > > But anyway, I thought that DRM_FORMAT_MOD_INVALID was being phased out? > Kernel never returns it and never accepts it. It has a separate flag (DRM_MODE_FB_MODIFIERS) to indicate if the modifier is explicit or implicit, and DRM_FORMAT_MOD_INVALID is not a valid explicit modifier. > > > At first read of your commit message, I got the feeling you want > > formats to be advertised by both events: format event to declare a > > format at all, plus modifier events to list any modifiers. That is also > > what your proposed spec text reads, so I'd recommend clarifying that > > implementations need to send only one of the two events per format. Or > > both if the same format can be used with and without a modifier? > Your interpretation is correct: format events are for formats, and modifier events are for modifiers. This is more intuitive comparing to Weston's. > > > If we have two events, one without and one with a modifier, should we > > also then have two (well, four actually, for the immed variant) > > requests to create a buffer: one without and one with a modifier? I > > think it would be nice to have these consistent unless there is a > > reason not to. > > > > I can find justification both ways, and whether we need to fix Weston > > or Mutter is not that important to me. I might want to avoid the four > > create requests case though. > > I agree that either way, some compositors will need to be fixed, and that > we > shouldn't decide based on current implementations. At the advertising phase, supported formats and modifiers are unambiguously advertised. At the creation phase, you are right that it is hard to express the intent to create a buffer with implicit modifier. I think it is best to add a new bit to flags, to express the intent unambiguously. > > I'm not sure the versioning fully works out, if we have: > > - version 1 and 2 have only 'format' event > > - version 3 has 'modifier' event, with 'format' event not to be used > > - version 4 wants to use both 'modifier' and 'format' events > > Yeah, that would be a little bit annoying. > > Implementation would need to adhere to these, so Mutter would still > > need fixing for clients that bind version 3. I don't think we should > > retro-actively change the semantics of an existing version. > > If the protocol isn't ambiguous, it would be dangerous to change semantics > indeed. > When it comes to implementations, my view is v1/v2: `format' event v3: add `modifier' event and `format' event becomes optional (i.e., clients ignores it) v4: `format' should not be optional An implementation can support all versions by always sending `format' events, and only send modifier events when version >= 3. A client can pick any version that suits it. > > I notice that currently the modifier is in > > zwp_linux_buffer_params_v1.add request which makes the modifier > > per-plane, but I seem to recall that in practise modifiers are nowadays > > used only per-buffer, not per-plane, so the modifier argument should > > move to the create and create_immed requests. > > You're right, modifiers are now per-buffer and not per-plane. > This diverges from what EGL and kernel do. If we are sure it will be fine down the road, I am fine with it. But it also makes implementations more complex to support both older and new versions. This was brought up above. So I think it is also a concern? > > > We also need to consider https://patchwork.freedesktop.org/patch/263061/ > . > > > > I would propose the following roadmap: > > > > 1. Do not un-deprecate format events; instead clarify the modifier on > >create and fix Mutter's behaviour. > > > > 2. Get http
Re: [PATCH] linux-dmabuf: un-deprecate format events
On Thursday, April 11, 2019 11:48 AM, Pekka Paalanen wrote: > Hi, > > at first hand, I would keep Weston's behaviour, because that is what > the current protocol specification says exactly. The specification text > is very clear on the intent: the old format event is not to be used, if > both the client and server support the version with the modifier event. > When the protocol will be stabilized (which is always an ABI break), > the format event without a modifier will be removed. > > The difference to EGL API does not seem to be making anything more > difficult either. > > Technically there is little difference between using two events with > and without a modifier, and one event with a special no-modifier value. > A technical reason to favour two different events would be bandwidth > saving, since then one doesn't need to send the dummy modifier. Can we > make that argument? If yes, that would be a good justification to make > the change you propose. Do we have a lot of these? My machines don't have any (i915 driver). But anyway, I thought that DRM_FORMAT_MOD_INVALID was being phased out? > At first read of your commit message, I got the feeling you want > formats to be advertised by both events: format event to declare a > format at all, plus modifier events to list any modifiers. That is also > what your proposed spec text reads, so I'd recommend clarifying that > implementations need to send only one of the two events per format. Or > both if the same format can be used with and without a modifier? > > If we have two events, one without and one with a modifier, should we > also then have two (well, four actually, for the immed variant) > requests to create a buffer: one without and one with a modifier? I > think it would be nice to have these consistent unless there is a > reason not to. > > I can find justification both ways, and whether we need to fix Weston > or Mutter is not that important to me. I might want to avoid the four > create requests case though. I agree that either way, some compositors will need to be fixed, and that we shouldn't decide based on current implementations. > I'm not sure the versioning fully works out, if we have: > - version 1 and 2 have only 'format' event > - version 3 has 'modifier' event, with 'format' event not to be used > - version 4 wants to use both 'modifier' and 'format' events Yeah, that would be a little bit annoying. > Implementation would need to adhere to these, so Mutter would still > need fixing for clients that bind version 3. I don't think we should > retro-actively change the semantics of an existing version. If the protocol isn't ambiguous, it would be dangerous to change semantics indeed. > I notice that currently the modifier is in > zwp_linux_buffer_params_v1.add request which makes the modifier > per-plane, but I seem to recall that in practise modifiers are nowadays > used only per-buffer, not per-plane, so the modifier argument should > move to the create and create_immed requests. You're right, modifiers are now per-buffer and not per-plane. > We also need to consider https://patchwork.freedesktop.org/patch/263061/ . > > I would propose the following roadmap: > > 1. Do not un-deprecate format events; instead clarify the modifier on >create and fix Mutter's behaviour. > > 2. Get https://patchwork.freedesktop.org/patch/263061/ merged. > > 3. Stop using wl_drm completely when both server and client support the >latest zwp_linux_dmabuf. > > 4. Do ABI-breaking cleanups, and bump the major or if we are sure >enough then declare the extension stable. > > The reason why I would throw the 'format' event away as it is is that > then it will be consistent with the create requests: use > DRM_FORMAT_MOD_INVALID for "no modifier" in both events and requests. I > would assume that the bandwidth savings would not be significant, > considering everything is aiming to have explicit modifiers. > > How would that sound? This makes a lot of sense to me. +1. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] linux-dmabuf: un-deprecate format events
On Wed, 10 Apr 2019 14:00:12 -0700 Chia-I Wu wrote: > On Wed, Apr 10, 2019 at 12:40 PM Simon Ser wrote: > > > On Wednesday, April 10, 2019 9:25 PM, Chia-I Wu wrote: > > > Both implementations support formats that have no explicit modifiers. > > > But when it comes to buffer creation, modifier_hi/lo is required > > > again. It is unclear how to create a buffer for such formats. > > > > > > This patch tries to clarify these issues, leaning toward mutter's > > > behavior. > > > > Is there a reason to standardize Mutter's behavior instead of Weston's > > and wlroots'? (Don't know about others) > > > Frankly, there was no clear, strong argument to prefer one over the other > to me. Things I can think of are > > - it is more intuitive to have format events for formats and modifier > events for modifiers > - having both events makes the protocol more similar to EGL's > equeglQueryDmaBufFormatsEXT > / eglQueryDmaBufModifiersEXT > > I should bring this up that standardizing on Mutter's behavior means Weston > and others require fixes, to send format events at least. But > standardizing on Weston's behavior means Mutter still works to some degree: > it only loses formats that have no explicit modifiers because format events > will be ignored. But that degree of compatibility is not enough if the > goal is to replace wl_drm ultimately. Hi, at first hand, I would keep Weston's behaviour, because that is what the current protocol specification says exactly. The specification text is very clear on the intent: the old format event is not to be used, if both the client and server support the version with the modifier event. When the protocol will be stabilized (which is always an ABI break), the format event without a modifier will be removed. The difference to EGL API does not seem to be making anything more difficult either. Technically there is little difference between using two events with and without a modifier, and one event with a special no-modifier value. A technical reason to favour two different events would be bandwidth saving, since then one doesn't need to send the dummy modifier. Can we make that argument? If yes, that would be a good justification to make the change you propose. At first read of your commit message, I got the feeling you want formats to be advertised by both events: format event to declare a format at all, plus modifier events to list any modifiers. That is also what your proposed spec text reads, so I'd recommend clarifying that implementations need to send only one of the two events per format. Or both if the same format can be used with and without a modifier? If we have two events, one without and one with a modifier, should we also then have two (well, four actually, for the immed variant) requests to create a buffer: one without and one with a modifier? I think it would be nice to have these consistent unless there is a reason not to. I can find justification both ways, and whether we need to fix Weston or Mutter is not that important to me. I might want to avoid the four create requests case though. I'm not sure the versioning fully works out, if we have: - version 1 and 2 have only 'format' event - version 3 has 'modifier' event, with 'format' event not to be used - version 4 wants to use both 'modifier' and 'format' events Implementation would need to adhere to these, so Mutter would still need fixing for clients that bind version 3. I don't think we should retro-actively change the semantics of an existing version. I notice that currently the modifier is in zwp_linux_buffer_params_v1.add request which makes the modifier per-plane, but I seem to recall that in practise modifiers are nowadays used only per-buffer, not per-plane, so the modifier argument should move to the create and create_immed requests. We also need to consider https://patchwork.freedesktop.org/patch/263061/ . I would propose the following roadmap: 1. Do not un-deprecate format events; instead clarify the modifier on create and fix Mutter's behaviour. 2. Get https://patchwork.freedesktop.org/patch/263061/ merged. 3. Stop using wl_drm completely when both server and client support the latest zwp_linux_dmabuf. 4. Do ABI-breaking cleanups, and bump the major or if we are sure enough then declare the extension stable. The reason why I would throw the 'format' event away as it is is that then it will be consistent with the create requests: use DRM_FORMAT_MOD_INVALID for "no modifier" in both events and requests. I would assume that the bandwidth savings would not be significant, considering everything is aiming to have explicit modifiers. How would that sound? Thanks, pq pgpvTAs5uiQCF.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] linux-dmabuf: un-deprecate format events
On Wed, Apr 10, 2019 at 12:40 PM Simon Ser wrote: > On Wednesday, April 10, 2019 9:25 PM, Chia-I Wu wrote: > > Both implementations support formats that have no explicit modifiers. > > But when it comes to buffer creation, modifier_hi/lo is required > > again. It is unclear how to create a buffer for such formats. > > > > This patch tries to clarify these issues, leaning toward mutter's > > behavior. > > Is there a reason to standardize Mutter's behavior instead of Weston's > and wlroots'? (Don't know about others) > Frankly, there was no clear, strong argument to prefer one over the other to me. Things I can think of are - it is more intuitive to have format events for formats and modifier events for modifiers - having both events makes the protocol more similar to EGL's equeglQueryDmaBufFormatsEXT / eglQueryDmaBufModifiersEXT I should bring this up that standardizing on Mutter's behavior means Weston and others require fixes, to send format events at least. But standardizing on Weston's behavior means Mutter still works to some degree: it only loses formats that have no explicit modifiers because format events will be ignored. But that degree of compatibility is not enough if the goal is to replace wl_drm ultimately. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] linux-dmabuf: un-deprecate format events
On Wednesday, April 10, 2019 9:25 PM, Chia-I Wu wrote: > Both implementations support formats that have no explicit modifiers. > But when it comes to buffer creation, modifier_hi/lo is required > again. It is unclear how to create a buffer for such formats. > > This patch tries to clarify these issues, leaning toward mutter's > behavior. Is there a reason to standardize Mutter's behavior instead of Weston's and wlroots'? (Don't know about others) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] linux-dmabuf: un-deprecate format events
In the prior version, "modifier" events could be used to advertise either formats or modifiers. For example, they could be used to advertise formats that have no modifiers, by setting the modifier_hi/lo to DRM_FORMAT_MOD_INVALID. In this version, "format" events are used to advertise formats and "modifier" events are used to advertise modifiers. The prior patch describes the behavior of weston, and this version describes the behavior of mutter. On Wed, Apr 10, 2019 at 12:20 AM Pekka Paalanen wrote: > On Tue, 9 Apr 2019 15:22:13 -0700 > Chia-I Wu wrote: > > > Format events are used to return supported formats while modifier > > evetns are used to return supported modifiers for each supported > > format. > > > > For example, if an implementation is based on EGL, it may send one > > format event for each format returned by eglQueryDmaBufFormatsEXT, > > and one modifier event for each modifier returned by > > eglQueryDmaBufModifiersEXT. > > Hi, > > sorry, but I did not understand this rationale at all. Could you > explain it thoroughly, please? > Say a compositor supports a list of formats. For each format, there is a list of supported modifiers. The list of supported modifiers for a format can be empty because, not every implementation supports explicit modifiers. Currently, mutter sends a format event for each supported formats. It also sends a modifier event for each supported modifiers of a format. When a format does not support any explicit modifiers, no modifier event is sent for the format. On the other hands, weston does not send format events at all. It only sends modifier events. When a format does not support any explicit modifier, weston sends a modifier event with modifier_hi/lo set to DRM_FORMAT_MOD_INVALID. Both implementations support formats that have no explicit modifiers. But when it comes to buffer creation, modifier_hi/lo is required again. It is unclear how to create a buffer for such formats. This patch tries to clarify these issues, leaning toward mutter's behavior. > > Thanks, > pq > > > > > Signed-off-by: Chia-I Wu > > --- > > .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 20 +-- > > 1 file changed, 14 insertions(+), 6 deletions(-) > > > > diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > index 154afe2..736cc2b 100644 > > --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > @@ -24,10 +24,11 @@ > > DEALINGS IN THE SOFTWARE. > > > > > > - > > + > > > >Following the interfaces from: > > > https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt > > + > https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt > >and the Linux DRM sub-system's AddFb2 ioctl. > > > >This interface offers ways to create generic dmabuf-based > > @@ -113,10 +114,8 @@ > > For the definition of the format codes, see the > > zwp_linux_buffer_params_v1::create request. > > > > -Warning: the 'format' event is likely to be deprecated and > replaced > > -with the 'modifier' event introduced in zwp_linux_dmabuf_v1 > > -version 3, described below. Please refrain from using the > information > > -received from this event. > > +For each buffer format that the server supports, this event > must be > > +sent before any 'modifier' event for the same buffer format. > > > > > > > > @@ -130,7 +129,11 @@ > > the client has received all supported format-modifier pairs. > > > > For the definition of the format and modifier codes, see the > > -zwp_linux_buffer_params_v1::create request. > > +zwp_linux_buffer_params_v1::create and > zwp_linux_buffer_params_v1::add > > +requests. > > + > > +Note that DRM_FORMAT_MOD_INVALID (that is, modifier_hi == > 0x00ff > > +and modifier_lo == 0x) is not a valid modifier in this > event. > > > > > > > @@ -200,6 +203,11 @@ > > This request raises the PLANE_IDX error if plane_idx is too > large. > > The error PLANE_SET is raised if attempting to set a plane that > > was already set. > > + > > +Note that DRM_FORMAT_MOD_INVALID (that is, modifier_hi == > 0x00ff > > +and modifier_lo == 0x) is always allowed and has a > special > > +meaning. It indicates that the modifier is derived from the > dmabuf fd > > +rather than explicitly specified. > > > > > > > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] linux-dmabuf: un-deprecate format events
On Tue, 9 Apr 2019 15:22:13 -0700 Chia-I Wu wrote: > Format events are used to return supported formats while modifier > evetns are used to return supported modifiers for each supported > format. > > For example, if an implementation is based on EGL, it may send one > format event for each format returned by eglQueryDmaBufFormatsEXT, > and one modifier event for each modifier returned by > eglQueryDmaBufModifiersEXT. Hi, sorry, but I did not understand this rationale at all. Could you explain it thoroughly, please? Thanks, pq > > Signed-off-by: Chia-I Wu > --- > .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 20 +-- > 1 file changed, 14 insertions(+), 6 deletions(-) > > diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > index 154afe2..736cc2b 100644 > --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > @@ -24,10 +24,11 @@ > DEALINGS IN THE SOFTWARE. > > > - > + > >Following the interfaces from: > > https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt > + > https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt >and the Linux DRM sub-system's AddFb2 ioctl. > >This interface offers ways to create generic dmabuf-based > @@ -113,10 +114,8 @@ > For the definition of the format codes, see the > zwp_linux_buffer_params_v1::create request. > > -Warning: the 'format' event is likely to be deprecated and replaced > -with the 'modifier' event introduced in zwp_linux_dmabuf_v1 > -version 3, described below. Please refrain from using the information > -received from this event. > +For each buffer format that the server supports, this event must be > +sent before any 'modifier' event for the same buffer format. > > > > @@ -130,7 +129,11 @@ > the client has received all supported format-modifier pairs. > > For the definition of the format and modifier codes, see the > -zwp_linux_buffer_params_v1::create request. > +zwp_linux_buffer_params_v1::create and > zwp_linux_buffer_params_v1::add > +requests. > + > +Note that DRM_FORMAT_MOD_INVALID (that is, modifier_hi == 0x00ff > +and modifier_lo == 0x) is not a valid modifier in this event. > > > @@ -200,6 +203,11 @@ > This request raises the PLANE_IDX error if plane_idx is too large. > The error PLANE_SET is raised if attempting to set a plane that > was already set. > + > +Note that DRM_FORMAT_MOD_INVALID (that is, modifier_hi == 0x00ff > +and modifier_lo == 0x) is always allowed and has a special > +meaning. It indicates that the modifier is derived from the dmabuf fd > +rather than explicitly specified. > > > pgpvhcWQivGgp.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] linux-dmabuf: un-deprecate format events
Hi, Thanks for your patch. On Wednesday, April 10, 2019 1:22 AM, Chia-I Wu wrote: > Format events are used to return supported formats while modifier > evetns are used to return supported modifiers for each supported Typo: events > format. > > For example, if an implementation is based on EGL, it may send one > format event for each format returned by eglQueryDmaBufFormatsEXT, > and one modifier event for each modifier returned by > eglQueryDmaBufModifiersEXT. Can you explain the rationale behind this change, why the other has been abandoned, why this one is better? In wlroots we send modifier events with DRM_FORMAT_MOD_INVALID in case no modifier can be used with the format. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] linux-dmabuf: un-deprecate format events
Format events are used to return supported formats while modifier evetns are used to return supported modifiers for each supported format. For example, if an implementation is based on EGL, it may send one format event for each format returned by eglQueryDmaBufFormatsEXT, and one modifier event for each modifier returned by eglQueryDmaBufModifiersEXT. Signed-off-by: Chia-I Wu --- .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 20 +-- 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml index 154afe2..736cc2b 100644 --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml @@ -24,10 +24,11 @@ DEALINGS IN THE SOFTWARE. - + Following the interfaces from: https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt + https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt and the Linux DRM sub-system's AddFb2 ioctl. This interface offers ways to create generic dmabuf-based @@ -113,10 +114,8 @@ For the definition of the format codes, see the zwp_linux_buffer_params_v1::create request. -Warning: the 'format' event is likely to be deprecated and replaced -with the 'modifier' event introduced in zwp_linux_dmabuf_v1 -version 3, described below. Please refrain from using the information -received from this event. +For each buffer format that the server supports, this event must be +sent before any 'modifier' event for the same buffer format. @@ -130,7 +129,11 @@ the client has received all supported format-modifier pairs. For the definition of the format and modifier codes, see the -zwp_linux_buffer_params_v1::create request. +zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add +requests. + +Note that DRM_FORMAT_MOD_INVALID (that is, modifier_hi == 0x00ff +and modifier_lo == 0x) is not a valid modifier in this event. -- 2.21.0.392.gf8f6787159e-goog ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
