Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
Hey, On 27 January 2016 at 14:23, Emil Velikov wrote: > On 27 January 2016 at 13:31, Daniel Stone wrote: >> On 27 January 2016 at 13:28, Emil Velikov >> wrote: >>> On 27 January 2016 at 11:42, Daniel Stone wrote: On 27 January 2016 at 09:38, Daniel Vetter wrote: > On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: >> 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. > > 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. Yeah, it's certainly doable, once some kernel-internal details are shuffled out of uapi/drm/drm_mode.h. >>> 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). >> >> More the *_FLAGS enums: >> 12:26 PM daniels, what kind of kernel internals in >> include/uapi/drm/drm_mode.h? >> 12:26 PM danvet: DRM_MODE_FB_DIRTY_FLAGS, >> DRM_MODE_CURSOR_FLAGS, DRM_MODE_PAGE_FLIP_FLAGS, DRM_MODE_ATOMIC_FLAGS >> 12:27 PM 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 hm well, don't mind those too much really >> 12:27 PM better than keeping them separate at least >> 12:28 PM why not just move them into the kernel and leave >> userspace to work it out for itself? >> 12:29 PM 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 >> > 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 ;-) 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
Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
On 27 January 2016 at 13:31, Daniel Stone wrote: > Hi, > > On 27 January 2016 at 13:28, Emil Velikov wrote: >> On 27 January 2016 at 11:42, Daniel Stone wrote: >>> On 27 January 2016 at 09:38, Daniel Vetter wrote: On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: > 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. 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. >>> >>> Yeah, it's certainly doable, once some kernel-internal details are >>> shuffled out of uapi/drm/drm_mode.h. >> 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). > > More the *_FLAGS enums: > 12:26 PM daniels, what kind of kernel internals in > include/uapi/drm/drm_mode.h? > 12:26 PM danvet: DRM_MODE_FB_DIRTY_FLAGS, > DRM_MODE_CURSOR_FLAGS, DRM_MODE_PAGE_FLIP_FLAGS, DRM_MODE_ATOMIC_FLAGS > 12:27 PM 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 hm well, don't mind those too much really > 12:27 PM better than keeping them separate at least > 12:28 PM why not just move them into the kernel and leave > userspace to work it out for itself? > 12:29 PM 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 > 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
Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
Hi, On 27 January 2016 at 13:28, Emil Velikov wrote: > On 27 January 2016 at 11:42, Daniel Stone wrote: >> On 27 January 2016 at 09:38, Daniel Vetter wrote: >>> On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: 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. >>> >>> 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. >> >> Yeah, it's certainly doable, once some kernel-internal details are >> shuffled out of uapi/drm/drm_mode.h. > 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). More the *_FLAGS enums: 12:26 PM daniels, what kind of kernel internals in include/uapi/drm/drm_mode.h? 12:26 PM danvet: DRM_MODE_FB_DIRTY_FLAGS, DRM_MODE_CURSOR_FLAGS, DRM_MODE_PAGE_FLIP_FLAGS, DRM_MODE_ATOMIC_FLAGS 12:27 PM 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 hm well, don't mind those too much really 12:27 PM better than keeping them separate at least 12:28 PM why not just move them into the kernel and leave userspace to work it out for itself? 12:29 PM 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
Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
On 27 January 2016 at 11:42, Daniel Stone wrote: > Hey, > > On 27 January 2016 at 09:38, Daniel Vetter wrote: >> On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: >>> On 11 January 2016 at 19:32, Emmanuel Gil Peyrot >>> 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. >> >> 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. > > Yeah, it's certainly doable, once some kernel-internal details are > shuffled out of uapi/drm/drm_mode.h. 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
Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
Hey, On 27 January 2016 at 09:38, Daniel Vetter wrote: > On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: >> On 11 January 2016 at 19:32, Emmanuel Gil Peyrot >> 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. > > 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. 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
[PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
On Tue, Jan 26, 2016 at 09:04:18PM +, Emil Velikov wrote: > On 11 January 2016 at 19:32, Emmanuel Gil Peyrot > 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. 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
On 11 January 2016 at 19:32, Emmanuel Gil Peyrot 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
[PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version
This adds R8, RG88 and GR88, as well as the non-subsampled NV24/NV42 formats.
Signed-off-by: Emmanuel Gil Peyrot
---
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_RG88fourcc_code('R', 'G', '8', '8') /*
[15:0] R:G 8:8 little endian */
+#define DRM_FORMAT_GR88fourcc_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_NV21fourcc_code('N', 'V', '2', '1') /* 2x2
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') /* 2x1
subsampled Cr:Cb plane */
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
+#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
* 3 plane YCbCr
--
2.7.0
