On 15/09/17 22:56, Carl Eugen Hoyos wrote: > 2017-09-15 23:53 GMT+02:00 Mark Thompson <s...@jkqxz.net>: >> On 15/09/17 22:50, Carl Eugen Hoyos wrote: >>> 2017-09-15 23:44 GMT+02:00 Mark Thompson <s...@jkqxz.net>: >>>> On 15/09/17 22:43, Carl Eugen Hoyos wrote: >>>>> 2017-09-15 22:51 GMT+02:00 Mark Thompson <s...@jkqxz.net>: >>>>>> The planes have no reason to be contiguous, assuming they >>>>>> are results in very broken output. >>>>> >>>>> Is being contiguous a requirement of DRM? >>>> >>>> For multiple-plane formats, no. Hence the change. >>> >>> Is it a requirement in FFmpeg? >>> >>> Sorry if I misunderstand, Carl Eugen >> >> Right, sorry, I wasn't reading the right thing into the question. >> >> Only the address of the first plane is retrievable, so we don't know >> the addresses of the other planes. Assuming they are contiguous >> is a possible guess, but not one we can actually make in practice. > > How are the formats supposed to be used?
The process which created the planes (and will render to them) knows where they are. You create a multiple-plane framebuffer with drmModeAddFB2() or drmModeAddFB2WithModifiers(). The only retrieval function is drmModeGetFB(), which matches the single-plane-only drmModeAddFB(). See <https://cgit.freedesktop.org/mesa/drm/tree/xf86drmMode.h#n359>. If drmModeGetFB2(), or ideally drmModeGetFB2WithModifiers(), were added then we could support multiple-plane formats in kmsgrab. (Better versions like this would also remove some of the guessing of formats and modifiers, which would be nice.) (These are all simple ioctl() wrappers which land in the kernel at <drivers/gpu/drm/drm_framebuffer.c>. E.g. drmModeGetFB() ends up at <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_framebuffer.c#n430>, where you can also see other things like the DRM-master-or-CAP_SYS_ADMIN requirement.) - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
