linux-toradex.git/include/uapi/drm/drm.h, branch v4.3-rc6

drm/mode: Add user blob-creation ioctl

2015-05-22T14:18:28+00:00

Add an ioctl which allows users to create blob properties from supplied
data. Currently this only supports modes, creating a drm_display_mode from
the userspace drm_mode_modeinfo.

v2: Removed size/type checks.
    Rebased on new patches to allow error propagation from create_blob,
    as well as avoiding double-allocation.

Signed-off-by: Daniel Stone 
Reviewed-by: Maarten Lankhorst 
Tested-by: Sean Paul 
Signed-off-by: Daniel Vetter

drm: add support for tiled/compressed/etc modifier in addfb2

2015-02-13T22:28:12+00:00

In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats.  Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
gem-create ioctl to pass around these extra flags.

The proposal is to add a per-plane format modifier.  This allows to, if
necessary, use different tiling patters for sub-sampled planes, etc.
The format modifiers are added at the end of the ioctl struct, so for
legacy userspace it will be zero padded.

v1: original
v1.5: increase modifier to 64b

v2: Incorporate review comments from the big thread, plus a few more.

- Add a getcap so that userspace doesn't have to jump through hoops.
- Allow modifiers only when a flag is set. That way drivers know when
  they're dealing with old userspace and need to fish out e.g. tiling
  from other information.
- After rolling out checks for ->modifier to all drivers I've decided
  that this is way too fragile and needs an explicit opt-in flag. So
  do that instead.
- Add a define (just for documentation really) for the "NONE"
  modifier. Imo we don't need to add mask #defines since drivers
  really should only do exact matches against values defined with
  fourcc_mod_code.
- Drop the Samsung tiling modifier on Rob's request since he's not yet
  sure whether that one is accurate.

v3:
- Also add a new ->modifier[] array to struct drm_framebuffer and fill
  it in drm_helper_mode_fill_fb_struct. Requested by Tvrkto Uruslin.
- Remove TODO in comment and add code comment that modifiers should be
  properly documented, requested by Rob.

Cc: Rob Clark 
Cc: Tvrtko Ursulin 
Cc: Laurent Pinchart 
Cc: Daniel Stone 
Cc: Ville Syrjälä 
Cc: Michel Dänzer 
Signed-off-by: Rob Clark  (v1.5)
Reviewed-by: Rob Clark 
Reviewed-by: Daniel Stone 
Acked-by: Dave Airlie 
Signed-off-by: Daniel Vetter

drm: Atomic modeset ioctl

2015-01-05T12:55:29+00:00

The atomic modeset ioctl can be used to push any number of new values
for object properties. The driver can then check the full device
configuration as single unit, and try to apply the changes atomically.

The ioctl simply takes a list of object IDs and property IDs and their
values.

Originally based on a patch from Ville Syrjälä, although it has mutated
(mutilated?) enough since then that you probably shouldn't blame it on
him ;-)

The atomic support is hidden behind the DRM_CLIENT_CAP_ATOMIC cap (to
protect legacy userspace) and drm.atomic module param (for now).

v2: Check for file_priv->atomic to make sure we only allow userspace
in-the-know to use atomic.

Signed-off-by: Rob Clark 
Reviewed-by: Sean Paul 
Reviewed-by: Daniel Vetter 
Signed-off-by: Daniel Vetter

drm: add atomic properties

2015-01-05T12:54:38+00:00

Once a driver is using atomic helpers for modeset, the next step is to
switch over to atomic properties.  To do this, make sure that any
modeset objects have their ->atomic_{get,set}_property() vfuncs suitably
populated if they have custom properties (you did already remember to
plug in atomic-helper func for the legacy ->set_property() vfuncs,
right?), and then set DRIVER_ATOMIC bit in driver_features flag.

A new cap is introduced, DRM_CLIENT_CAP_ATOMIC, for the purposes of
shielding legacy userspace from atomic properties.  Mostly for the
benefit of legacy DDX drivers that do silly things like getting/setting
each property at startup (since some of the new atomic properties will
be able to trigger modeset).

Signed-off-by: Rob Clark 
[danvet: Squash in fixup patch to check for DRM_MODE_PROP_ATOMIC
instaed of the CAP define when filtering properties. Reported by
Tvrtko Uruslin, acked by Rob.]
Signed-off-by: Daniel Vetter

drm: Driver-specific ioctls range from 0x40 to 0x9f

2014-06-18T11:50:16+00:00

DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.

Signed-off-by: Damien Lespiau 
Reviewed-by: Alex Deucher 
Signed-off-by: Daniel Vetter

Merge branch 'primary-plane' of git://people.freedesktop.org/~robclark/linux into drm-next

2014-04-02T02:09:09+00:00

Here's the latest iteration of the universal planes work, which I believe is
finally ready for merging.  Aside from the minor driver patches to use the
new drm_for_each_legacy_plane() macro for plane loops, these should all have
an r-b from Rob Clark now.

Actual userspace-visibility is currently hidden behind a
drm.universal_planes module parameter so that we can do some experimental
testing of this before flipping it on universally.

* 'primary-plane' of git://people.freedesktop.org/~robclark/linux:
  drm/doc: Update plane documentation and add plane helper library
  drm: Allow userspace to ask for universal plane list (v2)
  drm: Remove unused drm_crtc->fb
  drm: Replace crtc fb with primary plane fb (v3)
  drm/msm: Switch to universal plane API's
  drm: Add drm_crtc_init_with_planes() (v2)
  drm: Add plane type property (v2)
  drm: Add drm_universal_plane_init()
  drm: Add primary plane helpers (v3)
  drm: Make drm_crtc_check_viewport non-static
  drm/shmobile: Restrict plane loops to only operate on legacy planes
  drm/i915: Restrict plane loops to only operate on overlay planes (v2)
  drm/exynos: Restrict plane loops to only operate on overlay planes (v2)
  drm: Add support for multiple plane types (v2)

drm: Specify a bit more the DRM_CAP_CURSOR_{WIDTH, HEIGHT} caps

2014-04-02T00:29:01+00:00

Earlier this week, there was a bit of confusion about those new
capabilities, to the point I think it's better to document the intention
and API contract.

The comment documents the current situation:
 - the radeon driver returns the only valid size for the hw
 - i915 returns the maximun cursor size
 - other drivers fall back to returning 64x64

The common contract is to return a valid cursor size.

Cc: Sagar Kamble 
Cc: Chris Wilson 
Cc: Alex Deucher 
Cc: Imre Deak 
Signed-off-by: Damien Lespiau 
Reviewed-by: Chris Wilson 
Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie

drm: Allow userspace to ask for universal plane list (v2)

2014-04-02T00:18:29+00:00

Userspace clients which wish to receive all DRM planes (primary and
cursor planes in addition to the traditional overlay planes) may set the
DRM_CLIENT_CAP_UNIVERSAL_PLANES capability.

v2: Hide behind drm.universal_planes module option [suggested by
    Daniel Vetter]

Signed-off-by: Matt Roper 
Reviewed-by: Rob Clark

drm: add DRM_CAPs for cursor size

2014-02-18T18:41:01+00:00

Some hardware may not support standard 64x64 cursors.  Add
a drm cap to query the cursor size from the kernel.  Some examples
include radeon CIK parts (128x128 cursors) and armada (32x64 or 64x32).
This allows things like device specific ddxes to remove asics specific
logic and also allows xf86-video-modesetting to work properly with hw
cursors on this hardware. Default to 64 if the driver doesn't specify
a size.

Signed-off-by: Alex Deucher 
Reviewed-by: Rob Clark

drm/bufs: remove handling of _DRM_GEM mappings

2013-12-18T01:08:42+00:00

Gone with the new gem vma offset manager from David.

We can also ditch the uapi header definition from the enum since
userspace never used this. It ended up in there purely for historical
reasons (for reusing the old drm mmap code essentially), not because
userspace ever needed it.

Cc: David Herrmann 
Reviewed-by: David Herrmann 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie