Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
On Fri, 15 Nov 2019 10:17:54 -0500 "Drew DeVault" wrote: > I understand that we can implement DRM protocols in a way which just > says no, but I'd rather just say no to implementing DRM protocols at > all. We implement linux-dmabuf for obvious reasons, but I would prefer > to have DRM features in a separate protocol that we can refuse to > implement, as a message that DRM is not tolerated on our software. We > design our software with the users interests in mind, not our customers. That is a very good stance. I agree with that. > We won't block this if implemented as a separate protocol in the ext > namespace. We will officially NACK it, but ext protocols can still be > standardized even if NACKed. I do not know of a reason yet to make it an ext extension. I believe it will be a Weston extension for now, like a couple others that no other compositor implements (HDCP, debug log streams). If other compositors want to implement these extensions, then it might make sense to make it ext. Until then. Thanks, pq pgpKmg3aEDjfl.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
On Fri Nov 15, 2019 at 11:29 AM, Pekka Paalanen wrote: > All existing flags in zwp_linux_dmabuf are not hints either. If a > compositor does not correctly implement each flag every time a client > specifies one or more, the result is more or less incorrect. Hence all > compositors must always reject all flags they do not recognize or > implement. Yeah, but none of them are for DRM until now. That they are not hints means that we must take care with what kinds of flags we add. There's an implication here that clients ought to be afforded the privilege of specifying that their buffers cannot be read, as some kind of tautology, but I reject this, because the only obvious use-case is a malicious one. We don't afford the client plenty of other privileges on Wayland, because they'd be easily abused. There have been plenty of arguments against a randr-esque protocol, for example, because clients could weaponize it against users to screw up their desktop session. The same arguments apply to this - it will be weaponized to prevent users from doing what they want to with their computers. > > I think that there would be value in being able to suggest that a > > particluar buffer be scanned out for performance reasons. > > I think not, for the reasons Scott explained in his reply. Is that acknowledging that there are no use-cases for this other than DRM? > A totally valid implementation is to always reject any dmabufs that > attempt to have direct-display flag set. > > You can do that on any flag, too. You can also advertise > zwp_linux_dmabuf and never accept any dmabuf at all. That is also a > valid implementation, though not a very useful one. > > zwp_linux_dmabuf has the built-in assumption that the compositor can > always reject creating a wl_buffer from a dmabuf for any reason or even > just for the heck of it, because no-one can know in advance if a > particular driver will actually accept a particular dmabuf or not. I understand that we can implement DRM protocols in a way which just says no, but I'd rather just say no to implementing DRM protocols at all. We implement linux-dmabuf for obvious reasons, but I would prefer to have DRM features in a separate protocol that we can refuse to implement, as a message that DRM is not tolerated on our software. We design our software with the users interests in mind, not our customers. > > Rather, this just seems to be a DRM-enabling change, and the official > > policy of wlroots will always be to NACK those for the wp and xdg > > namespaces. > > Very good. We will work with that. We won't block this if implemented as a separate protocol in the ext namespace. We will officially NACK it, but ext protocols can still be standardized even if NACKed. I think this is the most reasonable way forward with this change. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
Hi, On Thu, 14 Nov 2019 at 22:44, Scott Anderson wrote: > On 15/11/19 4:04 am, Drew DeVault wrote: > > I think that there would be value in being able to suggest that a > > particluar buffer be scanned out for performance reasons. But, as a > > suggestion, and not a demand, and definitely not for secrecy reasons. > > wlroots-based compositors would reserve the right to read your buffers > > whenever we want. If I want to read your buffer for a frame to take a > > screenshot, it's not going to be the end of the world for performance > > and I don't want to end up segfaulting because of it. > > > > [...] > > > > If this protocol change were for the purpose of _suggesting_ scan-out, > > I'd be on board with it. But this is not that - if it were, we would > > dispense with any ideas around enforcing it with memory protections. > > Then we could get an improvement for performance without a regression > > for usability. > > > > Rather, this just seems to be a DRM-enabling change, and the official > > policy of wlroots will always be to NACK those for the wp and xdg > > namespaces. > > I don't think a hint for "please scan me out" has any value. A Wayland > compositor that is capable of scanning out will try to scan out > everybody as often as they can anyway, making the hint meaningless. A > Wayland compositor that is not capable of scanning out is also going to > ignore the hint, also making it meaningless. > > The only situation I could possibly think of where this could make a > difference is if you have two surfaces, and the compositor's policy > would normally be to scan out the focused surface, but chooses to scan > out e.g. a video player surface with this flag instead. That only works > if the video player is not occluded. Right. ST (the SoC vendor) originally requested this a long time ago - perhaps a few years even. They run Weston on set-top boxes, and would like to have the underlying video surface hit overlays at the cost of GPU composition of the subtitle & UI surfaces. According to them, just doing the EGLImage import of video buffers was a large enough performance hit - if I remember correctly, mostly fine but occasional hitches - that they had to be able to bypass it. I don't really see any overlap with hints here, given that hints are server -> client, and also don't prevent the buffer from being imported into the GPU in the first place. But yes, as said in the MR, the current usecase we have is a system which (for good reason) distrusts the GPU with protected content. I'm fine with just putting this in as a Weston-private extension layered on top of dmabuf. > But that's also cheapened by the fact that this flag sounds like "free > performance", and everybody would just set it. Well, 'free performance but you're very likely to also display nothing in the general case', which is a less appealing trade-off. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
On Thu, 14 Nov 2019 10:04:53 -0500 "Drew DeVault" wrote: > On Fri Nov 15, 2019 at 12:39 AM, Scott Anderson wrote: > > > A hint is merely a hint. The compositor can abide or not by that. > > > This flag will explicitly close the client connection if the buffer > > > can't be scanned out when this flag is passed. > > > > This flag doesn't sound like a hint to me, but a hard requirement. From > > the discussion I saw on the MR [1], if we don't abide, we risk being > > killed. > > I agree: that's not a hint, it's a demand. All existing flags in zwp_linux_dmabuf are not hints either. If a compositor does not correctly implement each flag every time a client specifies one or more, the result is more or less incorrect. Hence all compositors must always reject all flags they do not recognize or implement. > I think that there would be value in being able to suggest that a > particluar buffer be scanned out for performance reasons. I think not, for the reasons Scott explained in his reply. > But, as a > suggestion, and not a demand, and definitely not for secrecy reasons. > wlroots-based compositors would reserve the right to read your buffers > whenever we want. If I want to read your buffer for a frame to take a > screenshot, it's not going to be the end of the world for performance > and I don't want to end up segfaulting because of it. A totally valid implementation is to always reject any dmabufs that attempt to have direct-display flag set. You can do that on any flag, too. You can also advertise zwp_linux_dmabuf and never accept any dmabuf at all. That is also a valid implementation, though not a very useful one. zwp_linux_dmabuf has the built-in assumption that the compositor can always reject creating a wl_buffer from a dmabuf for any reason or even just for the heck of it, because no-one can know in advance if a particular driver will actually accept a particular dmabuf or not. > Rather, this just seems to be a DRM-enabling change, and the official > policy of wlroots will always be to NACK those for the wp and xdg > namespaces. Very good. We will work with that. Thanks, pq pgpMT8ARCvlun.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
On 15/11/19 4:04 am, Drew DeVault wrote: On Fri Nov 15, 2019 at 12:39 AM, Scott Anderson wrote: A hint is merely a hint. The compositor can abide or not by that. This flag will explicitly close the client connection if the buffer can't be scanned out when this flag is passed. This flag doesn't sound like a hint to me, but a hard requirement. From the discussion I saw on the MR [1], if we don't abide, we risk being killed. I agree: that's not a hint, it's a demand. I think that there would be value in being able to suggest that a particluar buffer be scanned out for performance reasons. But, as a suggestion, and not a demand, and definitely not for secrecy reasons. wlroots-based compositors would reserve the right to read your buffers whenever we want. If I want to read your buffer for a frame to take a screenshot, it's not going to be the end of the world for performance and I don't want to end up segfaulting because of it. > But without the excuse for performance, that also raises another issue for me about content-protection living in a "wp" protocol. The governance thing hasn't officially been applied yet, and I wouldn't even be the official spokesperson for wlroots, but I would personally NACK that. Content-protection is a niche use case not generally useful to Wayland implementations. I think a "ext" "wl_buffer factory for protected dmabufs" would be a better place for this. It means you could advertise a correct list of formats+modifiers too. As an official spokesperson for wlroots: If this protocol change were for the purpose of _suggesting_ scan-out, I'd be on board with it. But this is not that - if it were, we would dispense with any ideas around enforcing it with memory protections. Then we could get an improvement for performance without a regression for usability. Rather, this just seems to be a DRM-enabling change, and the official policy of wlroots will always be to NACK those for the wp and xdg namespaces. I don't think a hint for "please scan me out" has any value. A Wayland compositor that is capable of scanning out will try to scan out everybody as often as they can anyway, making the hint meaningless. A Wayland compositor that is not capable of scanning out is also going to ignore the hint, also making it meaningless. The only situation I could possibly think of where this could make a difference is if you have two surfaces, and the compositor's policy would normally be to scan out the focused surface, but chooses to scan out e.g. a video player surface with this flag instead. That only works if the video player is not occluded. But that's also cheapened by the fact that this flag sounds like "free performance", and everybody would just set it. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
On Thursday, November 14, 2019 4:13 PM, Pekka Paalanen wrote: > yes. The main use for 'direct-display' flag is dmabufs that are > "poisonous". Touching their content in any way might kill the > compositor, or so I hear. Obviously no normal desktop system would ever > have those, since they would be a trivial DoS attack vector. > > The hints extension will be useful for the users of 'direct-display', > but indeed it is missing the bit to say which format+modifier would be > scanout-able, so it's not sufficient as is. > > Possibly the closest use case on normal desktops would be XR without > DRM leasing. You want the XR buffers to always go straight to display > without compositing, but if they cannot, it is better to show e.g. black > than a nauseating animation. Of course, such a use case would need > other extensions as well, so you can rightly say that the other > extensions should take care of this instead. I think this use-case would be better handled via the presentation-time protocol. presentation-time provides timing information and also has a bit for direct scan-out. Clients can read the presentation data and decide what to do: if direct scan-out isn't used, and if latency is too high, render a simpler or a black screen. This would be better because the "placeholder" wouldn't be rendered by the compositor, clients would render it themselves. Also clients can decide to give up based on actual latency (and not just "is direct scan-out used?": compositing might be fast enough on a system but too slow on another). Typically in the VR case, Steam games will render a very simple 3D grid when they can't keep up. > > I'm also worried about compositors that are capable of taking > > screenshots. This flag implies that it's "dangerous" to ever touch the > > buffer for any purpose. But then it sounds like you're encouraging video > > players to use this, which is only going to break basic functionality. I > > suspect than the only sensible thing for a screenshot-capable compositor > > to do is to simply reject all uses of this flag, making it useless > > outside of highly-integrated environments. > > Yes, screenshooting would only show the placeholder graphics, so you > can argue that screenshooting would be broken. > > Quite the contrary, I'd recommend no-one to use this flag unless they > know they really have to and have no other choice. > > A compositor implementation that outright always rejects this flag > would be completely conformant. I'd probably recommend that to desktop > compositors even, just like they already reject all flags they do not > recognise. Hence a minimal implementation of this revision of > zwp_linux_dmabuf would be trivial. > > (Did anyone actually do anything meaningful with the interlaced flag?) > > > dmabuf-hints seems like a much better way to achieve the same effect of > > efficiency, instead of the client trying to dictate what the compositor > > should do. If this flag is added, I would want a stern warning to not > > carelessly use it unless the compositor literally can't access the > > buffer from the GPU. > > It's a different problem. > > I can well understand if this flag gets rejected from zwp_linux_dmabuf. > Maybe we should make this a separate extension instead, it would be > quite simple too. The fact that it's not a hint and that compositors need to render a placeholder makes me think this would be better. > Thanks, > pq > > > Scott > > > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
On Thu, 14 Nov 2019 17:05:41 +1300 Scott Anderson wrote: > On 14/11/19 3:08 am, Marius Vlad wrote: > > Flag used to tell the compositor that it should avoid touching the > > dmabuf buffer and forward it directly to the display controller. > > > > Most likely this flag can be used together with the content-protection > > protocol. It assures the client that the compositor will never handle > > the buffer over to the GPU but instead it will forward it straight to > > the display controller. > > > > While content-protection protocol should be sufficient to restrict the > > content on certain displays, on certain hardware platforms the GPU is > > not a secure-path link in the secure-content-path chain, and as such, > > this flag would be necessary to avoid passing the dmabuf buffer > > over to the GPU altogether. GPUs reading the dmabuf residing in a > > specially designed memory zone would be seen as an illegal memory access. > > > > Other example include video players which might need this flag passed > > down to avoid doing any composition, thus having an improvement of > > bandwidth usage and performance. Set-up boxes with dedicated video > > players could use this facility alongside the Pixman renderer, is > > another potential example of why this flag would be useful. > > > > Bumps zwp_linux_dmabuf_v1 and zwp_linux_buffer_params_v1 to version 4. > > > > Signed-off-by: Marius Vlad > > > > --- > > This patch initially started as fork at > > https://gitlab.freedesktop.org/marius.vlad0/wayland-protocols/merge_requests/3 > > > > This flag was used to be called 'no_gpu_import' but 'direct_display' > > should better reflect its name and purpose. > > > > Lastly, a WIP for the implementation of this flag for weston is at > > https://gitlab.freedesktop.org/wayland/weston/merge_requests/298, which > > should follow up closely. > > --- > > .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 15 --- > > 1 file changed, 12 insertions(+), 3 deletions(-) > > > > diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > index b43e81c..5b4b1e6 100644 > > --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > > @@ -2,7 +2,7 @@ > > > > > > > > -Copyright © 2014, 2015 Collabora, Ltd. > > +Copyright © 2014, 2015, 2019 Collabora, Ltd. > > > > Permission is hereby granted, free of charge, to any person obtaining > > a > > copy of this software and associated documentation files (the > > "Software"), > > @@ -24,7 +24,7 @@ > > DEALINGS IN THE SOFTWARE. > > > > > > - > > + > > > > Following the interfaces from: > > > > https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt > > @@ -149,7 +149,7 @@ > > > > > > > > - > > + > > > > This temporary object is a collection of dmabufs and other > > parameters that together form a single logical buffer. The temporary > > @@ -229,6 +229,7 @@ > > > > > > > > + > > > > > > > > @@ -254,6 +255,14 @@ > > 'bottom_first' is specified. It is undefined whether > > 'bottom_first' > > is ignored if 'interlaced' is not set. > > > > +Flag 'direct_display' tells the compositor not to import it to the > > GPU > > +in order to bypass it entirely, such that the buffer will be > > directly > > +scanned-out by the display controller. If HW is not capable/or > > there > > +aren't any available resources to directly scan-out the buffer, a > > +placeholder should be installed in-place by the compositor. The > > +compositor may perform checks on the dmabuf and refuse to create a > > +wl_buffer if the dmabuf seems unusable for being used directly. > > + > > This protocol does not convey any information about field rate, > > duration, or timing, other than the relative ordering between the > > two fields in one buffer. A compositor may have to estimate the > > Has any thought been into how this would need to interact with > dmabuf-hints[1]? Without that, it seems like it would be a total > crapshoot for clients to try and use this flag, since they have no idea > what formats+modifers the display controller supports, and instead only > has the list that the GPU supports. > dmabuf-hints would also need to explicitly state that a tranche of > formats+modifiers are supported for this flag. Hi, yes. The main use for 'direct-display' flag is dmabufs that are "poisonous". Touching their content in any way might kill the compositor, or so I hear. Obviously no normal desktop system would ever have those, since they would be a trivial DoS attack vector. The hints extension will be useful for the users of 'direct-display', but indeed it is missing the
Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
On Fri Nov 15, 2019 at 12:39 AM, Scott Anderson wrote: > > A hint is merely a hint. The compositor can abide or not by that. > > This flag will explicitly close the client connection if the buffer > > can't be scanned out when this flag is passed. > > This flag doesn't sound like a hint to me, but a hard requirement. From > the discussion I saw on the MR [1], if we don't abide, we risk being killed. I agree: that's not a hint, it's a demand. I think that there would be value in being able to suggest that a particluar buffer be scanned out for performance reasons. But, as a suggestion, and not a demand, and definitely not for secrecy reasons. wlroots-based compositors would reserve the right to read your buffers whenever we want. If I want to read your buffer for a frame to take a screenshot, it's not going to be the end of the world for performance and I don't want to end up segfaulting because of it. > But without the excuse for performance, that also raises another issue > for me about content-protection living in a "wp" protocol. The > governance thing hasn't officially been applied yet, and I wouldn't even > be the official spokesperson for wlroots, but I would personally NACK > that. Content-protection is a niche use case not generally useful to > Wayland implementations. I think a "ext" "wl_buffer factory for > protected dmabufs" would be a better place for this. It means you could > advertise a correct list of formats+modifiers too. As an official spokesperson for wlroots: If this protocol change were for the purpose of _suggesting_ scan-out, I'd be on board with it. But this is not that - if it were, we would dispense with any ideas around enforcing it with memory protections. Then we could get an improvement for performance without a regression for usability. Rather, this just seems to be a DRM-enabling change, and the official policy of wlroots will always be to NACK those for the wp and xdg namespaces. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
Has any thought been into how this would need to interact with dmabuf-hints[1]? Without that, it seems like it would be a total crapshoot for clients to try and use this flag, since they have no idea what formats+modifers the display controller supports, and instead only has the list that the GPU supports. dmabuf-hints would also need to explicitly state that a tranche of formats+modifiers are supported for this flag. Well I'm not aware of that hint extension, but I think this wasn't taken into consideration because it isn't the same thing. There's no assurance from the compositor that the buffer will not read/be imported by the GPU. Yeah, dmabuf-hints wouldn't replace this flag, but does interact with it. It's supposed to give the client the best possible chance of being able to be scanned out if it's possible, and is dynamic with how the surface is currently being used. I consider it a much better way to deal with any of the performance-related aspects of this, but doesn't say anything about the content-protection cases. Regarding formats+modifiers, the set of them that is valid is potentially very different from the ones advertised by wp_linux_dmabuf. The client has no reliable way to know what they are. dmabuf-hints does give a good idea of what the direct-scanout formats are, but doesn't really fit the content-protection case _that_ well. A hint is merely a hint. The compositor can abide or not by that. This flag will explicitly close the client connection if the buffer can't be scanned out when this flag is passed. This flag doesn't sound like a hint to me, but a hard requirement. From the discussion I saw on the MR [1], if we don't abide, we risk being killed. Regarding the screenshot bit not sure what is the concern here. Are you afraid you won't able to take screenshots? The placeholder graphics is in place only if view to which the buffer is attached can no longer be assigned to a HW plane. > It would be nice to know what basic functionality will this break, as I not aware of any. Yes, the functionality is the ability to take correct screenshots. We can't take a screenshot of a plane, so we're forced to compose. But this flag basically forces us to never compose, at risk of being killed. This is intended in the content-protection case, but not for anything else. When an application think it's being clever by using this flag (and they have no reason to NOT set it; it sounds like free performance), it breaks basic screenshots for us, and users are going to be annoyed by placeholders for random surfaces. For wlroots, which is never going to support content-protection, maybe we'd just completely ignore the issue, but the most sensible implementation to me would be to just completely disallow this flag. This flag should be completely re-contextualized about being content-protection only, or otherwise buffers we literally cannot access from the GPU. There should be no implications about performance, and it should be clear that 99.9% of clients don't want to use it. But without the excuse for performance, that also raises another issue for me about content-protection living in a "wp" protocol. The governance thing hasn't officially been applied yet, and I wouldn't even be the official spokesperson for wlroots, but I would personally NACK that. Content-protection is a niche use case not generally useful to Wayland implementations. I think a "ext" "wl_buffer factory for protected dmabufs" would be a better place for this. It means you could advertise a correct list of formats+modifiers too. Scott [1]: https://gitlab.freedesktop.org/marius.vlad0/wayland-protocols/merge_requests/3#note_291389 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
On 11/14/19 12:20 AM, Drew DeVault wrote: > Can you elaborate more on non-DRM use-cases? Most compositors are > already going to use direct scan-out as much as possible, and can make > reasonably well informed choices about when to do so. For example, > fullscreen surfaces will generally always be scanned out if possible. Unfortunately that's only partially correct, the buffer will (eventually) be scanned out directly, but there's nothing preventing the compositor to first import into the GPU. That flag assures the client that (the above) will not never happen. Really old platforms like i.MX51/i.MX53 have limited bandwidth to accommodate both video decoding/compositing/rendering and would greatly benefit from having to ability to bypass the GPU entirely. There's even lower powered boards which don't have a 3D core at all, but still capable of video display through a display controller. These are some potential targets which could benefit from having this available. > More interesting approaches could include intelligently picking the most > frequently updated buffers to be placed on planes, or the most optimal > arrangement for a given combination of pixel formats. > > In addition, the implication that the compositor shouldn't do things > like letting the user take screenshots when views like this are being > shown is a chilling effect on non-DRM use-cases, in which taking a > screenshot is a perfectly reasonable thing to do. I've seen this raised by Scott, have to admit I'm not aware of the issues with the screenshots are, nor do I see how this flag would influence that behaviour. I'll sure take a look to see what's the issue about it. > > I don't really like the idea of DRM-enabling features being added to > linux-dmabuf with this level of justification for non-DRM use-cases. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Marius Vlad 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] unstable/linux-dmabuf: Add 'direct_display' flag
On 11/14/19 6:05 AM, Scott Anderson wrote: >> > > Has any thought been into how this would need to interact with > dmabuf-hints[1]? Without that, it seems like it would be a total > crapshoot for clients to try and use this flag, since they have no idea > what formats+modifers the display controller supports, and instead only > has the list that the GPU supports. > dmabuf-hints would also need to explicitly state that a tranche of > formats+modifiers are supported for this flag. Well I'm not aware of that hint extension, but I think this wasn't taken into consideration because it isn't the same thing. There's no assurance from the compositor that the buffer will not read/be imported by the GPU. A hint is merely a hint. The compositor can abide or not by that. This flag will explicitly close the client connection if the buffer can't be scanned out when this flag is passed. Regarding the screenshot bit not sure what is the concern here. Are you afraid you won't able to take screenshots? The placeholder graphics is in place only if view to which the buffer is attached can no longer be assigned to a HW plane. It would be nice to know what basic functionality will this break, as I not aware of any. -- Marius Vlad 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] unstable/linux-dmabuf: Add 'direct_display' flag
On 14/11/19 3:08 am, Marius Vlad wrote: Flag used to tell the compositor that it should avoid touching the dmabuf buffer and forward it directly to the display controller. Most likely this flag can be used together with the content-protection protocol. It assures the client that the compositor will never handle the buffer over to the GPU but instead it will forward it straight to the display controller. While content-protection protocol should be sufficient to restrict the content on certain displays, on certain hardware platforms the GPU is not a secure-path link in the secure-content-path chain, and as such, this flag would be necessary to avoid passing the dmabuf buffer over to the GPU altogether. GPUs reading the dmabuf residing in a specially designed memory zone would be seen as an illegal memory access. Other example include video players which might need this flag passed down to avoid doing any composition, thus having an improvement of bandwidth usage and performance. Set-up boxes with dedicated video players could use this facility alongside the Pixman renderer, is another potential example of why this flag would be useful. Bumps zwp_linux_dmabuf_v1 and zwp_linux_buffer_params_v1 to version 4. Signed-off-by: Marius Vlad --- This patch initially started as fork at https://gitlab.freedesktop.org/marius.vlad0/wayland-protocols/merge_requests/3 This flag was used to be called 'no_gpu_import' but 'direct_display' should better reflect its name and purpose. Lastly, a WIP for the implementation of this flag for weston is at https://gitlab.freedesktop.org/wayland/weston/merge_requests/298, which should follow up closely. --- .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml index b43e81c..5b4b1e6 100644 --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml @@ -2,7 +2,7 @@ -Copyright © 2014, 2015 Collabora, Ltd. +Copyright © 2014, 2015, 2019 Collabora, Ltd. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), @@ -24,7 +24,7 @@ DEALINGS IN THE SOFTWARE. - + Following the interfaces from: https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt @@ -149,7 +149,7 @@ - + This temporary object is a collection of dmabufs and other parameters that together form a single logical buffer. The temporary @@ -229,6 +229,7 @@ + @@ -254,6 +255,14 @@ 'bottom_first' is specified. It is undefined whether 'bottom_first' is ignored if 'interlaced' is not set. +Flag 'direct_display' tells the compositor not to import it to the GPU +in order to bypass it entirely, such that the buffer will be directly +scanned-out by the display controller. If HW is not capable/or there +aren't any available resources to directly scan-out the buffer, a +placeholder should be installed in-place by the compositor. The +compositor may perform checks on the dmabuf and refuse to create a +wl_buffer if the dmabuf seems unusable for being used directly. + This protocol does not convey any information about field rate, duration, or timing, other than the relative ordering between the two fields in one buffer. A compositor may have to estimate the Has any thought been into how this would need to interact with dmabuf-hints[1]? Without that, it seems like it would be a total crapshoot for clients to try and use this flag, since they have no idea what formats+modifers the display controller supports, and instead only has the list that the GPU supports. dmabuf-hints would also need to explicitly state that a tranche of formats+modifiers are supported for this flag. I'm also worried about compositors that are capable of taking screenshots. This flag implies that it's "dangerous" to ever touch the buffer for any purpose. But then it sounds like you're encouraging video players to use this, which is only going to break basic functionality. I suspect than the only sensible thing for a screenshot-capable compositor to do is to simply reject all uses of this flag, making it useless outside of highly-integrated environments. dmabuf-hints seems like a much better way to achieve the same effect of efficiency, instead of the client trying to dictate what the compositor should do. If this flag is added, I would want a stern warning to not carelessly use it unless the compositor literally can't access the buffer from the GPU. Scott [1]: https://patchwork.freedesktop.org/patch/263061/
Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
Can you elaborate more on non-DRM use-cases? Most compositors are already going to use direct scan-out as much as possible, and can make reasonably well informed choices about when to do so. For example, fullscreen surfaces will generally always be scanned out if possible. More interesting approaches could include intelligently picking the most frequently updated buffers to be placed on planes, or the most optimal arrangement for a given combination of pixel formats. In addition, the implication that the compositor shouldn't do things like letting the user take screenshots when views like this are being shown is a chilling effect on non-DRM use-cases, in which taking a screenshot is a perfectly reasonable thing to do. I don't really like the idea of DRM-enabling features being added to linux-dmabuf with this level of justification for non-DRM use-cases. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] unstable/linux-dmabuf: Add 'direct_display' flag
Flag used to tell the compositor that it should avoid touching the dmabuf buffer and forward it directly to the display controller. Most likely this flag can be used together with the content-protection protocol. It assures the client that the compositor will never handle the buffer over to the GPU but instead it will forward it straight to the display controller. While content-protection protocol should be sufficient to restrict the content on certain displays, on certain hardware platforms the GPU is not a secure-path link in the secure-content-path chain, and as such, this flag would be necessary to avoid passing the dmabuf buffer over to the GPU altogether. GPUs reading the dmabuf residing in a specially designed memory zone would be seen as an illegal memory access. Other example include video players which might need this flag passed down to avoid doing any composition, thus having an improvement of bandwidth usage and performance. Set-up boxes with dedicated video players could use this facility alongside the Pixman renderer, is another potential example of why this flag would be useful. Bumps zwp_linux_dmabuf_v1 and zwp_linux_buffer_params_v1 to version 4. Signed-off-by: Marius Vlad --- This patch initially started as fork at https://gitlab.freedesktop.org/marius.vlad0/wayland-protocols/merge_requests/3 This flag was used to be called 'no_gpu_import' but 'direct_display' should better reflect its name and purpose. Lastly, a WIP for the implementation of this flag for weston is at https://gitlab.freedesktop.org/wayland/weston/merge_requests/298, which should follow up closely. --- .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml index b43e81c..5b4b1e6 100644 --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml @@ -2,7 +2,7 @@ -Copyright © 2014, 2015 Collabora, Ltd. +Copyright © 2014, 2015, 2019 Collabora, Ltd. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), @@ -24,7 +24,7 @@ DEALINGS IN THE SOFTWARE. - + Following the interfaces from: https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt @@ -149,7 +149,7 @@ - + This temporary object is a collection of dmabufs and other parameters that together form a single logical buffer. The temporary @@ -229,6 +229,7 @@ + @@ -254,6 +255,14 @@ 'bottom_first' is specified. It is undefined whether 'bottom_first' is ignored if 'interlaced' is not set. +Flag 'direct_display' tells the compositor not to import it to the GPU +in order to bypass it entirely, such that the buffer will be directly +scanned-out by the display controller. If HW is not capable/or there +aren't any available resources to directly scan-out the buffer, a +placeholder should be installed in-place by the compositor. The +compositor may perform checks on the dmabuf and refuse to create a +wl_buffer if the dmabuf seems unusable for being used directly. + This protocol does not convey any information about field rate, duration, or timing, other than the relative ordering between the two fields in one buffer. A compositor may have to estimate the -- 2.24.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
