Hello, On 04/06/2012 11:22 AM, Kyungmin Park wrote: > + V4L2 develper > Sylwester, please give your opinions? How to handle it at v4l2 side. > > Thank you, > Kyungmin Park > > On Apr 6, 2012 12:44 AM, "Ville Syrjälä" <syrjala@xxxxxx > <mailto:syrjala@xxxxxx>> wrote: > > On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote: > > Hi Ville, > > > > > -----Original Message----- > > > From: Ville Syrjälä [mailto:ville.syrjala@xxxxxxxxxxxxxxx > <mailto:ville.syrjala@xxxxxxxxxxxxxxx>] > > > Sent: Friday, April 06, 2012 3:14 AM > > > To: airlied@xxxxxxxxxx <mailto:airlied@xxxxxxxxxx> > > > Cc: inki.dae@xxxxxxxxxxx <mailto:inki.dae@xxxxxxxxxxx>; > kyungmin.park@xxxxxxxxxxx <mailto:kyungmin.park@xxxxxxxxxxx>; dri- > > > devel@xxxxxxxxxxxxxxxxxxxxx <mailto:devel@xxxxxxxxxxxxxxxxxxxxx>; > Seung-Woo Kim > > > Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to > > > add multi plane formats > > > > > > On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrjälä wrote: > > > > On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote: > > > > > Multi buffer plane pixel formats are added as like kernel header. > > > > > > > > > > Signed-off-by: Seung-Woo Kim <sw0312.kim@xxxxxxxxxxx > <mailto:sw0312.kim@xxxxxxxxxxx>> > > > > > --- > > > > > include/drm/drm_fourcc.h | 7 +++++++ > > > > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > > > > > > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h > > > > > index 85facb0..7cfd95a 100644 > > > > > --- a/include/drm/drm_fourcc.h > > > > > +++ b/include/drm/drm_fourcc.h > > > > > @@ -107,6 +107,10 @@ > > > > > #define DRM_FORMAT_NV16 fourcc_code('N', 'V', '1', > '6') /* > > > 2x1 subsampled Cr:Cb plane */ > > > > > #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', > '1') /* > > > 2x1 subsampled Cb:Cr plane */ > > > > > > > > > > +/* 2 non contiguous plane YCbCr */ > > > > > +#define DRM_FORMAT_NV12M fourcc_code('N', 'M', '1', '2') /* 2x2 > > > subsampled Cr:Cb plane */ > > > > > > > > NAK. DRM_FORMAT_NV12 handles this just fine. > > > > > > And I just realized that I was already too late with my NAK since this a > > > libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in > > > via some backdoor without review. Sigh. > > > > > > > We had already requested review for it. for this you can refer to link > > below: > > > > http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html > > I see. I couldn't find it in my work mailbox for some reason, and I > don't remember having seen the patch before. I suppose I just missed it > due to Christmas vacations, and was too blind to see it in my mailbox. > Also google decicded to filter my search results too much, so I didn't > spot it via the web archives either. I'm sorry for the false accusation. > > > > So they're now in Linus's tree. But looks like format_check() was never > > > updated to accept them, so there's no way anyone could actually be using > > > them. So Dave, can we still remove them from the kernel header? > > > > > > > Yes, right. these formats aren't used for any SoCs except Exynos series yet > > but just we are first. I think they should be added because anyone may use > > them someday at least possible. > > Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point > in adding it (similarly for YUV420M vs. YUV420). In V4L2 the fourcc also determines the number of memory planes in the frame buffer. The multi-planar API has been added to support devices with odd alignment requirements (image components, like Y/CbCr in separate physical memory buffers) for which it was difficult to map whole frame into contiguous user memory region. Here is some excample: http://linuxtv.org/downloads/v4l-dvb-apis/V4L2-PIX-FMT-NV12M.html I'm not terribly familiar with the buffer structure in DRM, maybe there are better ways to handle something like this in DRI. > -- > Ville Syrjälä > syrjala@xxxxxx <mailto:syrjala@xxxxxx> > http://www.sci.fi/~syrjala/ Regards, -- Sylwester Nawrocki Samsung Poland R&D Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel