On Wed, 25 Mar 2020 11:24:15 +0100 Neil Armstrong wrote: > Hi, > > On 25/03/2020 10:04, Simon Ser wrote: > > On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong wrote: > > > >> Amlogic uses a proprietary lossless image compression protocol and format > >> for their hardware video codec accelerators, either video decoders or > >> video input encoders. > >> > >> This introduces the Scatter Memory layout, means the header contains IOMMU > >> references to the compressed frames content to optimize memory access > >> and layout. > >> > >> In this mode, only the header memory address is needed, thus the content > >> memory organization is tied to the current producer execution and cannot > >> be saved/dumped neither transferrable between Amlogic SoCs supporting this > >> modifier. > > > > I don't think this is suitable for modifiers. User-space relies on > > being able to copy a buffer from one machine to another over the > > network. It would be pretty annoying for user-space to have a blacklist > > of modifiers that don't work this way. > > > > Example of such user-space: > > https://gitlab.freedesktop.org/mstoeckl/waypipe/ > > > > I really understand your point, but this is one of the use-cases we need solve. > This is why I split the fourcc patch and added an explicit comment. > > Please point me a way to display such buffer, the HW exists, works like that and > it's a fact and can't change. > > It will be the same for secure zero-copy buffers we can't map from userspace, but > only the HW decoder can read/write and HW display can read. The comparison to secure buffers is a good one. Are buffers with the DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER modifier meaningfully mmappable to CPU always / sometimes / never / varies-and-cannot-know? Maybe this type should be handled similar to secure buffers, with the exception that they are not actually secured but only mostly inaccessible. Then again, I haven't looked at any of the secure buffer proposals. Thanks, pq