网页网站建设域名网站建设方案书模板

接前一篇文章：DRM全解析 —— ADD_FB2（2）

本文参考以下博文：

DRM驱动（四）之ADD_FB

特此致谢！

上一回围绕libdrm与DRM在Linux内核中的接口：

DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB2, drm_mode_addfb2_ioctl, 0),

进行了相关宏的展开。本文开始对于drm_mode_addfb2_ioctl函数进行详解。drm_mode_addfb2_ioctl函数在drivers/gpu/drm/drm_framebuffer.c中，代码如下：

int drm_mode_addfb2_ioctl(struct drm_device *dev,void *data, struct drm_file *file_priv)
{
#ifdef __BIG_ENDIANif (!dev->mode_config.quirk_addfb_prefer_host_byte_order) {/** Drivers must set the* quirk_addfb_prefer_host_byte_order quirk to make* the drm_mode_addfb() compat code work correctly on* bigendian machines.** If they don't they interpret pixel_format values* incorrectly for bug compatibility, which in turn* implies the ADDFB2 ioctl does not work correctly* then.  So block it to make userspace fallback to* ADDFB.*/drm_dbg_kms(dev, "addfb2 broken on bigendian");return -EOPNOTSUPP;}
#endifreturn drm_mode_addfb2(dev, data, file_priv);
}

drm_mode_addfb2_ioctl函数只是一层简单封装，实际的工作交给了drm_mode_addfb2函数。它就在上边，代码如下：

/*** drm_mode_addfb2 - add an FB to the graphics configuration* @dev: drm device for the ioctl* @data: data pointer for the ioctl* @file_priv: drm file for the ioctl call** Add a new FB to the specified CRTC, given a user request with format. This is* the 2nd version of the addfb ioctl, which supports multi-planar framebuffers* and uses fourcc codes as pixel format specifiers.** Called by the user via ioctl.** Returns:* Zero on success, negative errno on failure.*/
int drm_mode_addfb2(struct drm_device *dev,void *data, struct drm_file *file_priv)
{struct drm_mode_fb_cmd2 *r = data;struct drm_framebuffer *fb;if (!drm_core_check_feature(dev, DRIVER_MODESET))return -EOPNOTSUPP;fb = drm_internal_framebuffer_create(dev, r, file_priv);if (IS_ERR(fb))return PTR_ERR(fb);drm_dbg_kms(dev, "[FB:%d]\n", fb->base.id);r->fb_id = fb->base.id;/* Transfer ownership to the filp for reaping on close */mutex_lock(&file_priv->fbs_lock);list_add(&fb->filp_head, &file_priv->fbs);mutex_unlock(&file_priv->fbs_lock);return 0;
}

实际上前文DRM全解析 —— ADD_FB（2）中曾给出drm_mode_addfb函数的代码：

/*** drm_mode_addfb - add an FB to the graphics configuration* @dev: drm device for the ioctl* @or: pointer to request structure* @file_priv: drm file** Add a new FB to the specified CRTC, given a user request. This is the* original addfb ioctl which only supported RGB formats.** Called by the user via ioctl, or by an in-kernel client.** Returns:* Zero on success, negative errno on failure.*/
int drm_mode_addfb(struct drm_device *dev, struct drm_mode_fb_cmd *or,struct drm_file *file_priv)
{struct drm_mode_fb_cmd2 r = {};int ret;if (!drm_core_check_feature(dev, DRIVER_MODESET))return -EOPNOTSUPP;r.pixel_format = drm_driver_legacy_fb_format(dev, or->bpp, or->depth);if (r.pixel_format == DRM_FORMAT_INVALID) {drm_dbg_kms(dev, "bad {bpp:%d, depth:%d}\n", or->bpp, or->depth);return -EINVAL;}/* convert to new format and call new ioctl */r.fb_id = or->fb_id;r.width = or->width;r.height = or->height;r.pitches[0] = or->pitch;r.handles[0] = or->handle;ret = drm_mode_addfb2(dev, &r, file_priv);if (ret)return ret;or->fb_id = r.fb_id;return 0;
}

从这里就能看出，drm_mode_addfb()实际上也是调用了drm_mode_addfb2()，这俩本质上是一回事。只是drm_mode_addfb函数中多了一些预准备和预处理。

drm_mode_fb_cmd2结构在本系列第一篇文章中已经介绍过了，为了便于理解，再次给出其代码，在include/drm/drm_mode.h中，如下：

struct drm_mode_fb_cmd2 {__u32 fb_id;__u32 width;__u32 height;__u32 pixel_format; /* fourcc code from drm_fourcc.h */__u32 flags; /* see above flags *//** In case of planar formats, this ioctl allows up to 4* buffer objects with offsets and pitches per plane.* The pitch and offset order is dictated by the fourcc,* e.g. NV12 (https://fourcc.org/yuv.php#NV12) is described as:**   YUV 4:2:0 image with a plane of 8 bit Y samples*   followed by an interleaved U/V plane containing*   8 bit 2x2 subsampled colour difference samples.** So it would consist of Y as offsets[0] and UV as* offsets[1].  Note that offsets[0] will generally* be 0 (but this is not required).** To accommodate tiled, compressed, etc formats, a* modifier can be specified.  The default value of zero* indicates "native" format as specified by the fourcc.* Vendor specific modifier token.  Note that even though* it looks like we have a modifier per-plane, we in fact* do not. The modifier for each plane must be identical.* Thus all combinations of different data layouts for* multi plane formats must be enumerated as separate* modifiers.*/__u32 handles[4];__u32 pitches[4]; /* pitch for each plane */__u32 offsets[4]; /* offset of each plane */__u64 modifier[4]; /* ie, tiling, compress */
};

struct drm_framebuffer 当然是在include/drm/drm_framebuffer.h中定义，代码如下：

/*** struct drm_framebuffer - frame buffer object** Note that the fb is refcounted for the benefit of driver internals,* for example some hw, disabling a CRTC/plane is asynchronous, and* scanout does not actually complete until the next vblank.  So some* cleanup (like releasing the reference(s) on the backing GEM bo(s))* should be deferred.  In cases like this, the driver would like to* hold a ref to the fb even though it has already been removed from* userspace perspective. See drm_framebuffer_get() and* drm_framebuffer_put().** The refcount is stored inside the mode object @base.*/
struct drm_framebuffer {/*** @dev: DRM device this framebuffer belongs to*/struct drm_device *dev;/*** @head: Place on the &drm_mode_config.fb_list, access protected by* &drm_mode_config.fb_lock.*/struct list_head head;/*** @base: base modeset object structure, contains the reference count.*/struct drm_mode_object base;/*** @comm: Name of the process allocating the fb, used for fb dumping.*/char comm[TASK_COMM_LEN];/*** @format: framebuffer format information*/const struct drm_format_info *format;/*** @funcs: framebuffer vfunc table*/const struct drm_framebuffer_funcs *funcs;/*** @pitches: Line stride per buffer. For userspace created object this* is copied from drm_mode_fb_cmd2.*/unsigned int pitches[DRM_FORMAT_MAX_PLANES];/*** @offsets: Offset from buffer start to the actual pixel data in bytes,* per buffer. For userspace created object this is copied from* drm_mode_fb_cmd2.** Note that this is a linear offset and does not take into account* tiling or buffer layout per @modifier. It is meant to be used when* the actual pixel data for this framebuffer plane starts at an offset,* e.g. when multiple planes are allocated within the same backing* storage buffer object. For tiled layouts this generally means its* @offsets must at least be tile-size aligned, but hardware often has* stricter requirements.** This should not be used to specifiy x/y pixel offsets into the buffer* data (even for linear buffers). Specifying an x/y pixel offset is* instead done through the source rectangle in &struct drm_plane_state.*/unsigned int offsets[DRM_FORMAT_MAX_PLANES];/*** @modifier: Data layout modifier. This is used to describe* tiling, or also special layouts (like compression) of auxiliary* buffers. For userspace created object this is copied from* drm_mode_fb_cmd2.*/uint64_t modifier;/*** @width: Logical width of the visible area of the framebuffer, in* pixels.*/unsigned int width;/*** @height: Logical height of the visible area of the framebuffer, in* pixels.*/unsigned int height;/*** @flags: Framebuffer flags like DRM_MODE_FB_INTERLACED or* DRM_MODE_FB_MODIFIERS.*/int flags;/*** @hot_x: X coordinate of the cursor hotspot. Used by the legacy cursor* IOCTL when the driver supports cursor through a DRM_PLANE_TYPE_CURSOR* universal plane.*/int hot_x;/*** @hot_y: Y coordinate of the cursor hotspot. Used by the legacy cursor* IOCTL when the driver supports cursor through a DRM_PLANE_TYPE_CURSOR* universal plane.*/int hot_y;/*** @filp_head: Placed on &drm_file.fbs, protected by &drm_file.fbs_lock.*/struct list_head filp_head;/*** @obj: GEM objects backing the framebuffer, one per plane (optional).** This is used by the GEM framebuffer helpers, see e.g.* drm_gem_fb_create().*/struct drm_gem_object *obj[DRM_FORMAT_MAX_PLANES];
};

了解了相关的结构体定义之后，可以开始对于drm_mode_addfb2函数的正式解析了。请看下回。