On 02/02/2015 09:58 AM, Daniel Vetter wrote:
On Mon, Feb 02, 2015 at 10:41:24AM +0100, Daniel Vetter wrote:
On Fri, Jan 30, 2015 at 05:36:54PM +0000, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
To be used from the new addfb2 extension.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
---
include/uapi/drm/i915_drm.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6eed16b..a7327fd 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -28,6 +28,7 @@
#define _UAPI_I915_DRM_H_
#include <drm/drm.h>
+#include <uapi/drm/drm_fourcc.h>
/* Please note that modifications to all structs defined here are
* subject to backwards-compatibility constraints.
@@ -1101,4 +1102,16 @@ struct drm_i915_gem_context_param {
__u64 value;
};
+/** @{
+ * Intel framebuffer modifiers
+ *
+ * Tiling modes supported by the display hardware
+ * to be passed in via the DRM addfb2 ioctl.
+ */
+/** None */
+#define I915_FORMAT_MOD_NONE fourcc_mod_code(INTEL, 0x00000000000000L)
+/** X tiling */
+#define I915_FORMAT_MOD_X_TILED fourcc_mod_code(INTEL, 0x00000000000001L)
One thing I wonder here is whether we should have a modifier for each
physical layout (tiling modes do change slightly between hw) or whether we
should just continue to assume that this is Intel-specific and add a
disclaimer that the precise layout depends upon the actual intel box
you're running on?
Leaning towards your approach, worst case we get to write some code to
de-alias layout modifiers with established cross-vendor layouts (if they
ever happen). Just want to make sure that we've thought about this. Adding
Rob&dri-devel for this.
Something else to ponder: We also need layout modifiers for non-fb formats
in userspace so that clients and compositors can communicate about render
formats. Given that I think it'll make sense to enumerate all the other
tiling formats we have, too (i.e. Y-tiled and W-tiled).
If we need fb modifiers for non-fb formats, although that sounds a bit
funky to me, we can always add them in separate patches, no?
Regards,
Tvrtko
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
