<p>Hi Jesse,</p>
<p>2011/11/15 Jesse Barnes &lt;<a href="mailto:jbarnes@virtuousgeek.org">jbarnes@virtuousgeek.org</a>&gt;<br>
&gt;<br>
&gt; To properly support the various plane formats supported by different<br>
&gt; hardware, the kernel must know the pixel format of a framebuffer object.<br>
&gt; So add a new ioctl taking a format argument corresponding to a fourcc<br>
&gt; name from the new drm_fourcc.h header file. Implement the fb creation<br>
&gt; hooks in terms of the new mode_fb_cmd2 using helpers where the old<br>
&gt; bpp/depth values are needed.<br>
&gt;<br>
&gt; v2: create DRM specific fourcc header file for sharing with libdrm etc<br>
&gt; v3: fix rebase failure and use DRM fourcc codes in intel_display.c and<br>
&gt; update commit message<br>
&gt; v4: make fb_cmd2 handle field into an array for multi-object formats<br>
&gt; pull in Ville&#39;s fix for the memcpy in drm_plane_init<br>
&gt; apply Ville&#39;s cleanup to zero out fb_cmd2 arg in drm_mode_addfb<br>
&gt; v5: add &#39;flags&#39; field for interlaced support (from Ville)<br>
&gt;<br>
&gt; Signed-off-by: Ville Syrjälä &lt;<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>&gt;<br>
&gt; Acked-by: Alan Cox &lt;<a href="mailto:alan@lxorguk.ukuu.org.uk">alan@lxorguk.ukuu.org.uk</a>&gt;<br>
&gt; Reviewed-by: Rob Clark &lt;<a href="mailto:rob.clark@linaro.org">rob.clark@linaro.org</a>&gt;<br>
&gt; Signed-off-by: Jesse Barnes &lt;<a href="mailto:jbarnes@virtuousgeek.org">jbarnes@virtuousgeek.org</a>&gt;<br>
&gt; ---<br>
&gt; drivers/gpu/drm/drm_crtc.c | 111 +++++++++++++++++++++++++++--<br>
&gt; drivers/gpu/drm/drm_crtc_helper.c | 51 ++++++++++++-<br>
&gt; drivers/gpu/drm/drm_drv.c | 1 +<br>
&gt; drivers/gpu/drm/i915/intel_display.c | 39 ++++++-----<br>
&gt; drivers/gpu/drm/i915/intel_drv.h | 2 +-<br>
&gt; drivers/gpu/drm/i915/intel_fb.c | 11 ++--<br>
&gt; drivers/gpu/drm/nouveau/nouveau_display.c | 6 +-<br>
&gt; drivers/gpu/drm/nouveau/nouveau_fb.h | 2 +-<br>
&gt; drivers/gpu/drm/nouveau/nouveau_fbcon.c | 13 ++--<br>
&gt; drivers/gpu/drm/radeon/radeon_display.c | 8 +-<br>
&gt; drivers/gpu/drm/radeon/radeon_fb.c | 18 +++--<br>
&gt; drivers/gpu/drm/radeon/radeon_mode.h | 2 +-<br>
&gt; drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 22 ++++--<br>
&gt; drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 1 +<br>
&gt; drivers/staging/gma500/framebuffer.c | 2 +-<br>
&gt; include/drm/drm.h | 1 +<br>
&gt; include/drm/drm_crtc.h | 9 ++-<br>
&gt; include/drm/drm_crtc_helper.h | 4 +-<br>
&gt; include/drm/drm_fourcc.h | 63 ++++++++++++++++<br>
&gt; include/drm/drm_mode.h | 27 +++++++<br>
&gt; 20 files changed, 327 insertions(+), 66 deletions(-)<br>
&gt; create mode 100644 include/drm/drm_fourcc.h<br>
&gt;</p>
<p>&lt;snip&gt;</p>
<p>&gt; diff --git a/drivers/staging/gma500/framebuffer.c b/drivers/staging/gma500/framebuffer.c<br>
&gt; index 3f39a37..1e77229 100644<br>
&gt; --- a/drivers/staging/gma500/framebuffer.c<br>
&gt; +++ b/drivers/staging/gma500/framebuffer.c<br>
&gt; @@ -546,7 +546,7 @@ out_err1:<br>
&gt; */<br>
&gt; static struct drm_framebuffer *psb_user_framebuffer_create<br>
&gt; (struct drm_device *dev, struct drm_file *filp,<br>
&gt; - struct drm_mode_fb_cmd *cmd)<br>
&gt; + struct drm_mode_fb_cmd2 *cmd)<br>
&gt; {<br>
&gt; struct gtt_range *r;<br>
&gt; struct drm_gem_object *obj;</p>
<p>I have no idea that this staging driver is really used or not, but anyway if drm_mode_fb_cmd2 is<br>
used here, then also it looks like that *cmd-&gt;handle* and *psb_framebuffer_create(dev, cmd, r)*<br>
are changed.</p>
<p>psb_framebuffer_create() and psb_framebuffer_init() still use drm_mode_fb_cmd, so maybe<br>
changed like vmwgfx_kms.c.</p>
<p>&lt;snip&gt;</p>
<p>&gt; +++ b/include/drm/drm_mode.h<br>
&gt; @@ -266,6 +266,33 @@ struct drm_mode_fb_cmd {<br>
&gt; __u32 handle;<br>
&gt; };<br>
&gt;<br>
&gt; +#define DRM_MODE_FB_INTERLACED (1&lt;&lt;0 /* for interlaced framebuffers */<br>
&gt; +<br>
&gt; +struct drm_mode_fb_cmd2 {<br>
&gt; + __u32 fb_id;<br>
&gt; + __u32 width, height;<br>
&gt; + __u32 pixel_format; /* fourcc code from drm_fourcc.h */<br>
&gt; + __u32 flags; /* see above flags */<br>
&gt; +<br>
&gt; + /*<br>
&gt; + * In case of planar formats, this ioctl allows up to 4<br>
&gt; + * buffer objects with offets and pitches per plane.<br>
&gt; + * The pitch and offset order is dictated by the fourcc,<br>
&gt; + * e.g. NV12 (<a href="http://fourcc.org/yuv.php#NV12">http://fourcc.org/yuv.php#NV12</a>) is described as:<br>
&gt; + *<br>
&gt; + * YUV 4:2:0 image with a plane of 8 bit Y samples<br>
&gt; + * followed by an interleaved U/V plane containing<br>
&gt; + * 8 bit 2x2 subsampled colour difference samples.<br>
&gt; + *<br>
&gt; + * So it would consist of Y as offset[0] and UV as<br>
&gt; + * offeset[1]. Note that offset[0] will generally<br>
&gt; + * be 0.<br>
&gt; + */<br>
&gt; + __u32 handles[4];<br>
&gt; + __u32 pitches[4]; /* pitch for each plane */<br>
&gt; + __u32 offsets[4]; /* offset of each plane */<br>
&gt; +};</p>
<p>&lt;snip&gt;</p>
<p>Regards,<br>
- Seung-Woo Kim</p>