drm/include/drm
Thierry Reding ab5aaf6c8e drm/tegra: Sanitize format modifiers
The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:

  - The format specifiers, except for one, are not Tegra specific, but
    the names don't reflect that.
  - The number space is split into two, reserving 32 bits for some
    "parameter" which most of the modifiers are not going to have.
  - Symbolic names for the modifiers are not using the standard
    DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
  - The vendor prefix NV is somewhat ambiguous.

Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.

Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.

This is based on commit 5843f4e02fbe86a59981e35adc6cabebee46fdc0 from
Linux v4.16-rc1 and also updates modetest to use the new defines.

Acked-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-02-19 14:58:57 +01:00
..
README headers: Drop outdated node about a delta in drm_mode.h. 2017-11-10 12:10:19 -08:00
amdgpu_drm.h headers: sync up amdgpu_drm.h with drm-next 2018-01-09 17:15:06 +01:00
drm.h drm: sync drm headers from drm-next. 2017-10-25 16:38:13 +10:00
drm_fourcc.h drm/tegra: Sanitize format modifiers 2018-02-19 14:58:57 +01:00
drm_mode.h drm: sync drm headers from drm-next. 2017-10-25 16:38:13 +10:00
drm_sarea.h headers: sync drm_sarea.h with airlied/drm-next 2017-06-03 23:39:22 +01:00
i915_drm.h Import uapi/i915_drm.h from v4.10-rc5-950-g152d5750dda9 2017-01-27 20:00:38 +00:00
mach64_drm.h Put mach64_drm.h back in to avoid breaking mesa build 2009-11-20 20:17:26 -05:00
mga_drm.h headers: Sync up mga_drm.h from drm-next. 2017-11-10 12:10:15 -08:00
nouveau_drm.h headers: Sync up kernel changes to use kernel types instead of stdint.h. 2017-11-10 12:10:17 -08:00
qxl_drm.h headers: Sync up kernel changes to use kernel types instead of stdint.h. 2017-11-10 12:10:17 -08:00
r128_drm.h headers: Sync up some header guard changes from drm-next. 2017-11-10 12:10:12 -08:00
radeon_drm.h headers: Sync up kernel changes to use kernel types instead of stdint.h. 2017-11-10 12:10:17 -08:00
savage_drm.h headers: Sync up some comment spelling and whitespace fixes from drm-next. 2017-11-10 12:10:13 -08:00
sis_drm.h headers: Sync up some header guard changes from drm-next. 2017-11-10 12:10:12 -08:00
tegra_drm.h headers: Sync up some header guard changes from drm-next. 2017-11-10 12:10:12 -08:00
vc4_drm.h headers: Sync vc4 header from drm-next. 2017-11-10 12:10:09 -08:00
via_drm.h headers: Sync up some header guard changes from drm-next. 2017-11-10 12:10:12 -08:00
virtgpu_drm.h virtgpu: Update kernel header 2016-07-23 09:45:53 +02:00
vmwgfx_drm.h headers: Sync up some header guard changes from drm-next. 2017-11-10 12:10:12 -08:00

README

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
----------------------------------
Note: One should not do _any_ changes to the files apart from the steps below.

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.

Most UMS headers:
 - Not using fixed size integers - compat ioctls are broken.
Status: ?
Promote to fixed size ints, which match the current (32bit) ones.

i915_drm.h
 - Missing PARAMS - HAS_POOLED_EU, MIN_EU_IN_POOL CONTEXT_PARAM_NO_ERROR_CAPTURE
Status: Trivial.

nouveau_drm.h
 - Missing macros NOUVEAU_GETPARAM*, NOUVEAU_DRM_HEADER_PATCHLEVEL, structs,
enums
Status: ?

r128_drm.h
 - Broken compat ioctls.

radeon_drm.h
 - Missing RADEON_TILING_R600_NO_SCANOUT, CIK_TILE_MODE_*, broken UMS ioctls
 - 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: ?