diff options
author | Jonathan Gray <jsg@cvs.openbsd.org> | 2016-11-19 05:36:56 +0000 |
---|---|---|
committer | Jonathan Gray <jsg@cvs.openbsd.org> | 2016-11-19 05:36:56 +0000 |
commit | 4ac2045a69e0e16d0a0450d556db49af2d968c54 (patch) | |
tree | 03b66b0414d019c316d7c480a144d73b40ede464 /lib/libdrm/include | |
parent | 8c28f43db5396da49b52c608049d0c21ee713a0b (diff) |
Import libdrm 2.4.73
Diffstat (limited to 'lib/libdrm/include')
-rw-r--r-- | lib/libdrm/include/drm/README | 157 | ||||
-rw-r--r-- | lib/libdrm/include/drm/drm_mode.h | 49 |
2 files changed, 203 insertions, 3 deletions
diff --git a/lib/libdrm/include/drm/README b/lib/libdrm/include/drm/README new file mode 100644 index 000000000..c3292f312 --- /dev/null +++ b/lib/libdrm/include/drm/README @@ -0,0 +1,157 @@ +What are these headers ? +------------------------ +This is the canonical source of drm headers that user space should use for +communicating with the kernel DRM subsystem. + +They flow from the kernel, thus any changes must be merged there first. +Do _not_ attempt to "fix" these by deviating from the kernel ones ! + + +Non-linux platforms - changes/patches +------------------------------------- +If your platform has local changes, please send them upstream for inclusion. +Even if your patches don't get accepted in their current form, devs will +give you feedback on how to address things properly. + +git send-email --subject-prefix="PATCH libdrm" your patches to dri-devel +mailing list. + +Before doing so, please consider the following: + - Have the [libdrm vs kernel] headers on your platform deviated ? +Consider unifying them first. + + - Have you introduced additional ABI that's not available in Linux ? +Propose it for [Linux kernel] upstream inclusion. +If that doesn't work out (hopefully it never does), move it to another header +and/or keep the change(s) local ? + + - Are your changes DRI1/UMS specific ? +There is virtually no interest/power in keeping those legacy interfaces. They +are around due to the kernel "thou shalt not break existing user space" rule. + +Consider porting the driver to DRI2/KMS - all (almost?) sensible hardware is +capable of supporting those. + + +Which headers go where ? +------------------------ +A snipped from the, now removed, Makefile.am used to state: + + XXX airlied says, nothing besides *_drm.h and drm*.h should be necessary. + however, r300 and via need their reg headers installed in order to build. + better solutions are welcome. + +Obviously the r300 and via headers are no longer around ;-) + +Reason behind is that the drm headers can be used as a basic communications +channel with the respective kernel modules. If more advanced functionality is +required one can pull the specific libdrm_$driver which is free to pull +additional files from the kernel. + +For example: nouveau has nouveau/nvif/*.h while vc4 has vc4/*.h + +If your driver is still in prototyping/staging state, consider moving the +$driver_drm.h into $driver and _not_ installing it. An header providing opaque +definitions and access [via $driver_drmif.h or similar] would be better fit. + + +When and which headers to update +-------------------------------- +Ideally all files will be synced (updated) with the latest released kernel on +each libdrm release. Sadly that's not yet possible since quite a few headers +differ significantly - see Outdated or Broken Headers section below. + +That said, it's up-to the individual developers to sync with newer version +(from drm-next) as they see fit. + + +When and how to update these files +---------------------------------- +In order to update the files do the following: + - Switch to a Linux kernel tree/branch which is not rebased. +For example: airlied/drm-next + - Install the headers via `make headers_install' to a separate location. + - Copy the drm header[s] + git add + git commit. + - Note: Your commit message must include: + a) Brief summary on the delta. If there's any change that looks like an +API/ABI break one _must_ explicitly state why it's safe to do so. + b) "Generated using make headers_install." + c) "Generated from $tree/branch commit $sha" + + +Outdated or Broken Headers +-------------------------- +This section contains a list of headers and the respective "issues" they might +have relative to their kernel equivalent. + +Nearly all headers: + - Missing extern C notation. +Status: Trivial. + +Most UMS headers: + - Not using fixed size interers - compat ioctls are broken. +Status: ? +Promote to fixed size ints, which match the current (32bit) ones. + + +amdgpu_drm.h + - Using the stdint.h uint*_t over the respective __u* ones +Status: Trivial. + +drm_mode.h + - Missing DPI encode/connector pair. +Status: Trivial. + +i915_drm.h + - Missing PARAMS - HAS_POOLED_EU, MIN_EU_IN_POOL CONTEXT_PARAM_NO_ERROR_CAPTURE +Status: Trivial. + +mga_drm.h + - Typo fix, use struct over typedef. +Status: Trivial. + +nouveau_drm.h + - Missing macros NOUVEAU_GETPARAM*, NOUVEAU_DRM_HEADER_PATCHLEVEL, structs, +enums, using stdint.h over the __u* types. +Status: ? + +qxl_drm.h + - Using the stdint.h uint*_t over the respective __u* ones +Status: Trivial. + +r128_drm.h + - Broken compat ioctls. + +radeon_drm.h + - Missing RADEON_TILING_R600_NO_SCANOUT, CIK_TILE_MODE_*, broken UMS ioctls, +using stdint types. + - Both kernel and libdrm: missing padding - +drm_radeon_gem_{create,{g,s}et_tiling,set_domain} others ? +Status: ? + +savage_drm.h + - Renamed ioctls - DRM_IOCTL_SAVAGE_{,BCI}_EVENT_EMIT, compat ioctls are broken. +Status: ? + +sis_drm.h + - Borken ioctls + libdrm uses int vs kernel long +Status: ? + +via_drm.h + - Borken ioctls - libdrm int vs kernel long +Status: ? + + +omap_drm.h (living in $TOP/omap) + - License mismatch, missing DRM_IOCTL_OMAP_GEM_NEW and related struct +Status: ? + +msm_drm.h (located in $TOP/freedreno/msm/) + - License mismatch, missing MSM_PIPE_*, MSM_SUBMIT_*. Renamed +drm_msm_gem_submit::flags, missing drm_msm_gem_submit::fence_fd. +Status: ? + +exynos_drm.h (living in $TOP/exynos) + - License mismatch, now using fixed size ints (but not everywhere). Lots of +new stuff. +Status: ? diff --git a/lib/libdrm/include/drm/drm_mode.h b/lib/libdrm/include/drm/drm_mode.h index 7a7856e02..df0e3504c 100644 --- a/lib/libdrm/include/drm/drm_mode.h +++ b/lib/libdrm/include/drm/drm_mode.h @@ -29,6 +29,10 @@ #include "drm.h" +#if defined(__cplusplus) +extern "C" { +#endif + #define DRM_DISPLAY_INFO_LEN 32 #define DRM_CONNECTOR_NAME_LEN 32 #define DRM_DISPLAY_MODE_LEN 32 @@ -202,6 +206,7 @@ struct drm_mode_get_plane_res { #define DRM_MODE_ENCODER_VIRTUAL 5 #define DRM_MODE_ENCODER_DSI 6 #define DRM_MODE_ENCODER_DPMST 7 +#define DRM_MODE_ENCODER_DPI 8 struct drm_mode_get_encoder { __u32 encoder_id; @@ -241,6 +246,7 @@ struct drm_mode_get_encoder { #define DRM_MODE_CONNECTOR_eDP 14 #define DRM_MODE_CONNECTOR_VIRTUAL 15 #define DRM_MODE_CONNECTOR_DSI 16 +#define DRM_MODE_CONNECTOR_DPI 17 struct drm_mode_get_connector { @@ -514,7 +520,13 @@ struct drm_color_lut { #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define DRM_MODE_PAGE_FLIP_ASYNC 0x02 -#define DRM_MODE_PAGE_FLIP_FLAGS (DRM_MODE_PAGE_FLIP_EVENT|DRM_MODE_PAGE_FLIP_ASYNC) +#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4 +#define DRM_MODE_PAGE_FLIP_TARGET_RELATIVE 0x8 +#define DRM_MODE_PAGE_FLIP_TARGET (DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE | \ + DRM_MODE_PAGE_FLIP_TARGET_RELATIVE) +#define DRM_MODE_PAGE_FLIP_FLAGS (DRM_MODE_PAGE_FLIP_EVENT | \ + DRM_MODE_PAGE_FLIP_ASYNC | \ + DRM_MODE_PAGE_FLIP_TARGET) /* * Request a page flip on the specified crtc. @@ -537,8 +549,7 @@ struct drm_color_lut { * 'as soon as possible', meaning that it not delay waiting for vblank. * This may cause tearing on the screen. * - * The reserved field must be zero until we figure out something - * clever to use it for. + * The reserved field must be zero. */ struct drm_mode_crtc_page_flip { @@ -549,6 +560,34 @@ struct drm_mode_crtc_page_flip { __u64 user_data; }; +/* + * Request a page flip on the specified crtc. + * + * Same as struct drm_mode_crtc_page_flip, but supports new flags and + * re-purposes the reserved field: + * + * The sequence field must be zero unless either of the + * DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags is specified. When + * the ABSOLUTE flag is specified, the sequence field denotes the absolute + * vblank sequence when the flip should take effect. When the RELATIVE + * flag is specified, the sequence field denotes the relative (to the + * current one when the ioctl is called) vblank sequence when the flip + * should take effect. NOTE: DRM_IOCTL_WAIT_VBLANK must still be used to + * make sure the vblank sequence before the target one has passed before + * calling this ioctl. The purpose of the + * DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags is merely to clarify + * the target for when code dealing with a page flip runs during a + * vertical blank period. + */ + +struct drm_mode_crtc_page_flip_target { + __u32 crtc_id; + __u32 fb_id; + __u32 flags; + __u32 sequence; + __u64 user_data; +}; + /* create a dumb scanout buffer */ struct drm_mode_create_dumb { __u32 height; @@ -621,4 +660,8 @@ struct drm_mode_destroy_blob { __u32 blob_id; }; +#if defined(__cplusplus) +} +#endif + #endif |