This adds R8, RG88 and GR88, as well as the non-subsampled NV24/NV42 formats.
Signed-off-by: Emmanuel Gil Peyrot emmanuel.peyrot@collabora.com --- include/drm/drm_fourcc.h | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h index e741b09..59fc54d 100644 --- a/include/drm/drm_fourcc.h +++ b/include/drm/drm_fourcc.h @@ -34,6 +34,13 @@ /* color index */ #define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
+/* 8 bpp Red */ +#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */ + +/* 16 bpp RG */ +#define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /* [15:0] R:G 8:8 little endian */ +#define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /* [15:0] G:R 8:8 little endian */ + /* 8 bpp RGB */ #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 3:3:2 */ #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 2:3:3 */ @@ -106,6 +113,8 @@ #define DRM_FORMAT_NV21 fourcc_code('N', 'V', '2', '1') /* 2x2 subsampled Cb:Cr plane */ #define DRM_FORMAT_NV16 fourcc_code('N', 'V', '1', '6') /* 2x1 subsampled Cr:Cb plane */ #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */ +#define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */ +#define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
/* * 3 plane YCbCr
On 11 January 2016 at 19:32, Emmanuel Gil Peyrot emmanuel.peyrot@collabora.com wrote:
This adds R8, RG88 and GR88, as well as the non-subsampled NV24/NV42 formats.
Err... please don't copy/paste 'random' hunks here. These headers should be imported from the kernel with the commit message mentioning the sha of their origin.
I've been procrastinating^Wwaiting on some upstream changes to land and with those in place I'll update the Makefile to import things properly.
-Emil
On Tue, Jan 26, 2016 at 09:04:18PM +0000, Emil Velikov wrote:
Yeah, we should have some scripts in libdrm that runs make headers_install, copies over the latest generated uapi headers for drm and then creates a commit with the sha1 it was generated from. Maybe even a rule that the sha1 has to be from Dave's drm-next. -Daniel
Hey,
On 27 January 2016 at 09:38, Daniel Vetter daniel@ffwll.ch wrote:
Yeah, it's certainly doable, once some kernel-internal details are shuffled out of uapi/drm/drm_mode.h. Would be pretty nice to have too.
Cheers, Daniel
On 27 January 2016 at 11:42, Daniel Stone daniel@fooishbar.org wrote:
What do you have in mind - DRM_MODE_PICTURE_ASPECT_* ? I'm thinking more that we should bring back DRM_MODE_OBJECT_* as it breaks libdrm and maybe other userspace.
Feel free to let me know here or in the patch I just sent (didn't realise and I Cc'd your collabora email).
Thanks Emil
Hi,
On 27 January 2016 at 13:28, Emil Velikov emil.l.velikov@gmail.com wrote:
More the *_FLAGS enums: 12:26 PM <danvet> daniels, what kind of kernel internals in include/uapi/drm/drm_mode.h? 12:26 PM <daniels> danvet: DRM_MODE_FB_DIRTY_FLAGS, DRM_MODE_CURSOR_FLAGS, DRM_MODE_PAGE_FLIP_FLAGS, DRM_MODE_ATOMIC_FLAGS 12:27 PM <daniels> danvet: not strictly kernel-internal per se, but does encourage userspace to do stupid validation on a potentially outdated (or too-new; either way the result is incorrect) set of flags 12:27 PM <danvet> hm well, don't mind those too much really 12:27 PM <danvet> better than keeping them separate at least 12:28 PM <daniels> why not just move them into the kernel and leave userspace to work it out for itself? 12:29 PM <daniels> i can't see the space for userspace using them at all; if you're needing to test for specific flags, then do that, but the only case for exposing the _FLAGS mask is to validate that you're not passing 'unsupported' flags (not 'flags i don't know about', since just use individual flags yourself for that, but 'flags the kernel doesn't know about'), which is a) pointless, and b) likely to be incorrect
Cheers, Daniel
On 27 January 2016 at 13:31, Daniel Stone daniel@fooishbar.org wrote:
Silly me should have checked the logs first.
While I agree with your points I'm slightly worried that some of these are already part of the API. So as long as a volunteer goes through the history and checks that we don't break existing apps (libdrm, mesa, ddxen, xserver, wayland and other compositors, dvdhrm's kmscon and others?) I would love to see them do ;-)
Thanks Emil
Hey,
On 27 January 2016 at 14:23, Emil Velikov emil.l.velikov@gmail.com wrote:
Well, not in libdrm Mesa, the X server or Intel driver, Weston, Mutter, or Chromium ... haven't checked kmscon, Enlightenment or other DDXes, but I'd be shocked if they did use it; if you're generating the pageflip flags in the first place yourself, why would you then need to filter them against a bitmask .,.. ?
Cheers, Daniel
dri-devel@lists.freedesktop.org
-
Daniel Stone -
Daniel Vetter -
Emil Velikov -
Emmanuel Gil Peyrot