kernel/linux.git/include/uapi/drm/drm_mode.h, branch v4.8.16

drm: add extern C guard for the UAPI headers

2016-05-13T12:57:17+00:00

Signed-off-by: Emil Velikov

Merge tag 'drm-vc4-next-2016-05-02' of https://github.com/anholt/linux into drm-next

2016-05-04T07:30:53+00:00

This pull request brings in DPI panel support, gamma ramp support, and render nodes for vc4. * tag 'drm-vc4-next-2016-05-02' of https://github.com/anholt/linux: drm/vc4: Add missing render node support drm/vc4: Add support for gamma ramps. drm/vc4: Fix NULL deref in HDMI init error path drm/vc4: Add DPI driver drm: Add an encoder and connector type enum for DPI.

drm: Add an encoder and connector type enum for DPI.

2016-04-01T01:39:39+00:00

Right now exynos is exposing DPI as a TMDS encoder and VGA connector, which seems rather misleading. This isn't just an internal detail, since xrandr actually exposes "VGA" as the output name. Define some new enums so that vc4's DPI can have a more informative name. I considered other names for the connector as well. For VC4, the Adafruit DPI kippah takes the 28 GPIO pins and routes them to a standard-ish 40-pin FPC connector, but "40-pin FPC" doesn't uniquely identify an ordering of pins (apparently some other orderings exist), doesn't explain things as well for the user (who, if anything, knows their product is a DPI kippah/panel combo), and actually doesn't have to exist (one could connect the 28 GPIOs directly to something else). Simply "DPI" seems like a good compromise name to distinguish from the HDMI, DSI, and TV connectors . Signed-off-by: Eric Anholt Reviewed-by: Daniel Vetter

drm: Move DRM_MODE_OBJECT_* to uapi headers

2016-03-30T19:08:33+00:00

These type defines are officially part of the uapi, but ended up in the wrong headers somehow when we split them all. Cc: Emil Velikov Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1459347584-30566-3-git-send-email-daniel.vetter@ffwll.ch

drm: introduce pipe color correction properties

2016-03-08T12:57:32+00:00

Patch based on a previous series by Shashank Sharma. This introduces optional properties to enable color correction at the pipe level. It relies on 3 transformations applied to every pixels displayed. First a lookup into a degamma table, then a multiplication of the rgb components by a 3x3 matrix and finally another lookup into a gamma table. The following properties can be added to a pipe : - DEGAMMA_LUT : blob containing degamma LUT - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT - CTM : transformation matrix applied after the degamma LUT - GAMMA_LUT : blob containing gamma LUT - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by the driver to tell userspace applications what sizes should be the lookup tables in DEGAMMA_LUT and GAMMA_LUT. A helper is also provided so legacy gamma correction is redirected through these new properties. v2: Register LUT size properties as range v3: Fix round in drm_color_lut_get_value() helper More docs on how degamma/gamma properties are used v4: Update contributors v5: Rename CTM_MATRIX property to CTM (Doh!) Add legacy gamma_set atomic helper Describe CTM/LUT acronyms in the kernel doc v6: Fix missing blob unref in drm_atomic_helper_crtc_reset Signed-off-by: Shashank Sharma Signed-off-by: Kumar, Kiran S Signed-off-by: Kausal Malladi Signed-off-by: Lionel Landwerlin Reviewed-by: Matt Roper Acked-by: Rob Bradford [danvet: CrOS maintainers are also happy with the userspacde side: https://codereview.chromium.org/1182063002/ ] Reviewed-by: Daniel Stone Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1456506302-640-4-git-send-email-lionel.g.landwerlin@intel.com

drm: drm_mode.h fix includes

2015-12-10T11:33:23+00:00

Instead of using linux/types.h, drm headers should use drm.h, in order to handle the portability issues in only one place. Signed-off-by: Gabriel Laskar Reviewed-by: Emil Velikov CC: Emil Velikov CC: Mikko Rapeli

drm_mode.h: use u32 and u64 from linux/types.h

2015-12-10T11:33:23+00:00

Fixes userspace compilation error: drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’ Signed-off-by: Mikko Rapeli

drm: cleanup modesetting ioctls, one param per line

2015-09-08T11:45:47+00:00

Since this already confused me once when adding addfb2.1, let's clean up the header to split params one per line. Signed-off-by: Rob Clark Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter

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