[PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[Emmanuel Gil Peyrot]

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
-- 
2.7.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[Emil Velikov]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[Daniel Vetter]

On Tue, Jan 26, 2016 at 09:04:18PM +0000, Emil Velikov wrote:
> 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.

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[Daniel Stone]

Hey,

On 27 January 2016 at 09:38, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Jan 26, 2016 at 09:04:18PM +0000, Emil Velikov wrote:
>> 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.
>
> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[Emil Velikov]

On 27 January 2016 at 11:42, Daniel Stone <daniel@fooishbar.org> wrote:
> Hey,
>
> On 27 January 2016 at 09:38, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Tue, Jan 26, 2016 at 09:04:18PM +0000, Emil Velikov wrote:
>>> 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.
>>
>> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[Daniel Stone]

Hi,

On 27 January 2016 at 13:28, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> On 27 January 2016 at 11:42, Daniel Stone <daniel@fooishbar.org> wrote:
>> On 27 January 2016 at 09:38, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> On Tue, Jan 26, 2016 at 09:04:18PM +0000, 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 <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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[Emil Velikov]

On 27 January 2016 at 13:31, Daniel Stone <daniel@fooishbar.org> wrote:
> Hi,
>
> On 27 January 2016 at 13:28, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> On 27 January 2016 at 11:42, Daniel Stone <daniel@fooishbar.org> wrote:
>>> On 27 January 2016 at 09:38, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>> On Tue, Jan 26, 2016 at 09:04:18PM +0000, 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 <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
>
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[Daniel Stone]

Hey,

On 27 January 2016 at 14:23, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> On 27 January 2016 at 13:31, Daniel Stone <daniel@fooishbar.org> wrote:
>> On 27 January 2016 at 13:28, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>> On 27 January 2016 at 11:42, Daniel Stone <daniel@fooishbar.org> wrote:
>>>> On 27 January 2016 at 09:38, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>> On Tue, Jan 26, 2016 at 09:04:18PM +0000, 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 <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
>>
> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[Emmanuel Gil Peyrot]

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
-- 
2.7.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx