| Message ID | 20170915205108.14049-2-sw@jkqxz.net |
|---|---|
| State | Accepted |
| Commit | 9f9625ea80acf4b7272f740f7b2c15cebf96d09b |
| Headers | show |
2017-09-15 22:51 GMT+02:00 Mark Thompson <sw@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? Carl Eugen
On 15/09/17 22:43, Carl Eugen Hoyos wrote: > 2017-09-15 22:51 GMT+02:00 Mark Thompson <sw@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. - Mark
2017-09-15 23:44 GMT+02:00 Mark Thompson <sw@jkqxz.net>: > On 15/09/17 22:43, Carl Eugen Hoyos wrote: >> 2017-09-15 22:51 GMT+02:00 Mark Thompson <sw@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
On 15/09/17 22:50, Carl Eugen Hoyos wrote: > 2017-09-15 23:44 GMT+02:00 Mark Thompson <sw@jkqxz.net>: >> On 15/09/17 22:43, Carl Eugen Hoyos wrote: >>> 2017-09-15 22:51 GMT+02:00 Mark Thompson <sw@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. - Mark
2017-09-15 23:53 GMT+02:00 Mark Thompson <sw@jkqxz.net>: > On 15/09/17 22:50, Carl Eugen Hoyos wrote: >> 2017-09-15 23:44 GMT+02:00 Mark Thompson <sw@jkqxz.net>: >>> On 15/09/17 22:43, Carl Eugen Hoyos wrote: >>>> 2017-09-15 22:51 GMT+02:00 Mark Thompson <sw@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? Just curious, Carl Eugen
On 15/09/17 22:56, Carl Eugen Hoyos wrote: > 2017-09-15 23:53 GMT+02:00 Mark Thompson <sw@jkqxz.net>: >> On 15/09/17 22:50, Carl Eugen Hoyos wrote: >>> 2017-09-15 23:44 GMT+02:00 Mark Thompson <sw@jkqxz.net>: >>>> On 15/09/17 22:43, Carl Eugen Hoyos wrote: >>>>> 2017-09-15 22:51 GMT+02:00 Mark Thompson <sw@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
diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c index bcb6865f60..e54534006e 100644 --- a/libavdevice/kmsgrab.c +++ b/libavdevice/kmsgrab.c @@ -221,10 +221,6 @@ static const struct { { AV_PIX_FMT_YUYV422, DRM_FORMAT_YUYV }, { AV_PIX_FMT_YVYU422, DRM_FORMAT_YVYU }, { AV_PIX_FMT_UYVY422, DRM_FORMAT_UYVY }, - { AV_PIX_FMT_NV12, DRM_FORMAT_NV12 }, - { AV_PIX_FMT_YUV420P, DRM_FORMAT_YUV420 }, - { AV_PIX_FMT_YUV422P, DRM_FORMAT_YUV422 }, - { AV_PIX_FMT_YUV444P, DRM_FORMAT_YUV444 }, }; static av_cold int kmsgrab_read_header(AVFormatContext *avctx)