2012년 4월 20일 오후 11:22, Rob Clark rob.clark@linaro.org님의 말:
On Fri, Apr 20, 2012 at 8:49 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote:
On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie airlied@gmail.com wrote:
On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
On Thu, Apr 5, 2012 at 7:35 PM, ville.syrjala@linux.intel.com wrote: > From: Ville Syrjälä ville.syrjala@linux.intel.com > > There will be a need for this function in drm_crtc.c later. This > avoids making drm_crtc.c depend on drm_crtc_helper.c.
Hi Ville,
I've applied these 4 patches, but I might have lost some others for you, let me know if there is some other stuff I should be reviewing for -next.
IIRC only one patch fell through the cracks: Subject: [PATCH] drm: Unify and fix idr error handling Message-Id: 1331834311-30757-1-git-send-email-ville.syrjala@linux.intel.com
Thanks I'll take a look at that,
BTW you never gave any statement wrt. removing NV12M and YUV420M from drm_fourcc.h. I can send a patch if you agree, and if not, well then someone has to actually change the code to treat them exactly the same as NV12 and YUV420.
I'm probably not qualified, if you and jbarnes and say one other non-Intel person agree, then send the patch with R-b and I'll apply it.
I agree that they seem like the same thing (as their non-M counterparts) to me.. maybe the one exception is if there was hw that somehow *only* supported discontiguous multi-planar.
The way things are currently, anyone can feed the driver either contiguous or discontiguous planes using either format.
As a hint to userspace the M version might work, except it still doesn't tell you anything on how you need to allocate or align the planes. Since memory allocation is driver specific anyway, I see no point in overloading the pixel formats with that information. Some other mechanism to communicate such information would be needed if there is a desire to make it generic.
I can't really tell if this is the case in current exynos, it seems to only advertise XRGB8888 (but possibly I'm looking in the wrong place).
For drivers that have weird requirements, I'd suggest they use the non 7-bit ascii space (ie. one or more of bytes in fourcc is non-ascii, so as to not conflict with potential future standard fourcc's) driver specific format values.
We could define a DRM_FORMAT_DRIVER_SPECIFIC bit just like we have
yeah, that is a good idea
DRM_FORMAT_BIG_ENDIAN. We still have three bits to choose from. OTOH I'm not too worried about standard fourccs since we already differ from the standard names anyway.
well, was more just thinking from the point of view of clashes if we add more standard names later but some driver somewhere was already using that new fourcc name
Possibly I'm over-thinking this.. but seemed like a reasonable thing to separate standard and non-standard formats before a bunch of driver specific formats start cropping up.
BR, -R
we just wanted to use multi-planar format in same way as v4l2 side and I am not still sure that it's good way to add some codes to identify them. anyway for now, I'm ok.
Thanks, Inki Dae.
-- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel