Re: [PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2017-05-07 Thread Rainer Hochecker 
>>
>
> Yep. The weird thing about that extension is that it only implements the
> query vblank count/timestamp part of GLX_OML_sync_control. Sounds like the
> least useful bit of all in isolation, although the extension as a whole
> could be useful, just as on GLX. Also note this comment on that commit
> referenced by Daniel from just 2 hours ago:
>
> "marcheu 2 hours, 35 minutes ago (2017-05-05 18:52:45 UTC) #10
> lgtm
>
> By the way, there is discussion on dropping this extension from mesa. You
> should let Chad know if you need it in the long run. Chrome OS stopped
> requiring it when we switched to freon."
>
> Cc'ing Chad Versace on the off-chance he is the mentioned Chad.
>
> Also, the VDPAU api for video playback implements functions for precise
> timing of video frame presentation. I don't have any practical experience
> with them, but iirc Mesa's VDPAU video presentation api implements those via
> DRI3/Present extension, so hooks into drmWaitVblank et al. If Kodi uses
> VDPAU for playback, it could use those conveniently for timing.
>
> -mario

Kodi needs interoperability between vpdau and GL, it does not use vdpau's
presentation queue. Currently vdpau is bound to GLX and there don't seem
to be any activity to change this, it will most likely die with X11.

Kodi will get Wayland support soon, a GSOC project was just acceptend wich
I will mentor. We already have support for Mir.
That means Kodi is fine if you go ahead with this RFC.

Rainer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: add fourcc codes for 16bit R and GR

2017-01-02 Thread Rainer Hochecker 
I chose GR16 because that matches with Mesa texture formats. Unfortunately
RG16 is already taken by DRM_FORMAT_RGB565
<http://lxr.free-electrons.com/ident?v=3.6;i=DRM_FORMAT_RGB565>
So GR32 / RG32 might be better. All other codes in fourcc.h seem to sum up
all planes.

On Mon, Jan 2, 2017 at 3:05 PM, Ville Syrjälä  wrote:

> On Mon, Jan 02, 2017 at 01:23:23PM +0100, David Herrmann wrote:
> > Hi
> >
> > On Mon, Jan 2, 2017 at 11:41 AM, Rainer Hochecker 
> wrote:
> > > From: Rainer Hochecker 
> > >
> > > Add fourcc codes for 16bit planes. Required by mesa for
> > > eglCreateImageKHR to access P010 surfaces created by vaapi.
> > >
> > > Signed-off-by: Rainer Hochecker 
> > > ---
> > >  include/uapi/drm/drm_fourcc.h | 6 ++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > > index a5890bf..e6ab638 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -41,10 +41,16 @@ extern "C" {
> > >  /* 8 bpp Red */
> > >  #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /*
> [7:0] R */
> > >
> > > +/* 16 bpp Red */
> > > +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /*
> [15: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 */
> > >
> > > +/* 32 bpp GR */
> > > +#define DRM_FORMAT_GR16fourcc_code('G', 'R', '1',
> '6') /* [31:0] G:R 16:16 little endian */
> > > +
> >
> > Shouldn't it be 'G', 'R', '3', '2'?
>
> The name should be _GR1616. Using GR16 for the fourcc seems OK to me
> since we can't fit in the full GR1616 in there. Althogh GR32 could work
> too I suppose.
>
> And what about RG16?
>
> >
> > Also, please put dri-devel on CC.
> >
> > Thanks
> > David
> >
> > >  /* 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 */
> > > --
> > > 2.9.3
> > >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/9ec94c1b/attachment-0001.html>

[PATCH] drm: add fourcc codes for 16bit R and GR

2017-01-02 Thread Rainer Hochecker 
I chose GR16 because that matches with Mesa texture formats. Unfortunately
RG16 is already taken by DRM_FORMAT_RGB565
So GR32 / RG32 might be better. All other codes in fourcc.h seem to sum up
all planes.

(sorry, gmail included some html links on last attempt)

On Mon, Jan 2, 2017 at 3:05 PM, Ville Syrjälä  wrote:

> On Mon, Jan 02, 2017 at 01:23:23PM +0100, David Herrmann wrote:
> > Hi
> >
> > On Mon, Jan 2, 2017 at 11:41 AM, Rainer Hochecker 
> wrote:
> > > From: Rainer Hochecker 
> > >
> > > Add fourcc codes for 16bit planes. Required by mesa for
> > > eglCreateImageKHR to access P010 surfaces created by vaapi.
> > >
> > > Signed-off-by: Rainer Hochecker 
> > > ---
> > >  include/uapi/drm/drm_fourcc.h | 6 ++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > > index a5890bf..e6ab638 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -41,10 +41,16 @@ extern "C" {
> > >  /* 8 bpp Red */
> > >  #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /*
> [7:0] R */
> > >
> > > +/* 16 bpp Red */
> > > +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /*
> [15: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 */
> > >
> > > +/* 32 bpp GR */
> > > +#define DRM_FORMAT_GR16fourcc_code('G', 'R', '1',
> '6') /* [31:0] G:R 16:16 little endian */
> > > +
> >
> > Shouldn't it be 'G', 'R', '3', '2'?
>
> The name should be _GR1616. Using GR16 for the fourcc seems OK to me
> since we can't fit in the full GR1616 in there. Althogh GR32 could work
> too I suppose.
>
> And what about RG16?
>
> >
> > Also, please put dri-devel on CC.
> >
> > Thanks
> > David
> >
> > >  /* 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 */
> > > --
> > > 2.9.3
> > >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170102/185bab15/attachment.html>

[PATCH] drm: add fourcc codes for 16bit R and GR

2017-01-03 Thread Rainer Hochecker 
On Mon, Jan 2, 2017 at 3:31 PM, Rainer Hochecker  wrote:
>
> I chose GR16 because that matches with Mesa texture formats. Unfortunately
> RG16 is already taken by DRM_FORMAT_RGB565
> So GR32 / RG32 might be better. All other codes in fourcc.h seem to sum up
> all planes.
>
> (sorry, gmail included some html links on last attempt)
>
> On Mon, Jan 2, 2017 at 3:05 PM, Ville Syrjälä  linux.intel.com> wrote:
>>
>> On Mon, Jan 02, 2017 at 01:23:23PM +0100, David Herrmann wrote:
>> > Hi
>> >
>> > On Mon, Jan 2, 2017 at 11:41 AM, Rainer Hochecker  
>> > wrote:
>> > > From: Rainer Hochecker 
>> > >
>> > > Add fourcc codes for 16bit planes. Required by mesa for
>> > > eglCreateImageKHR to access P010 surfaces created by vaapi.
>> > >
>> > > Signed-off-by: Rainer Hochecker 
>> > > ---
>> > >  include/uapi/drm/drm_fourcc.h | 6 ++
>> > >  1 file changed, 6 insertions(+)
>> > >
>> > > diff --git a/include/uapi/drm/drm_fourcc.h 
>> > > b/include/uapi/drm/drm_fourcc.h
>> > > index a5890bf..e6ab638 100644
>> > > --- a/include/uapi/drm/drm_fourcc.h
>> > > +++ b/include/uapi/drm/drm_fourcc.h
>> > > @@ -41,10 +41,16 @@ extern "C" {
>> > >  /* 8 bpp Red */
>> > >  #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] 
>> > > R */
>> > >
>> > > +/* 16 bpp Red */
>> > > +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* 
>> > > [15: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 */
>> > >
>> > > +/* 32 bpp GR */
>> > > +#define DRM_FORMAT_GR16fourcc_code('G', 'R', '1', '6') 
>> > > /* [31:0] G:R 16:16 little endian */
>> > > +
>> >
>> > Shouldn't it be 'G', 'R', '3', '2'?
>>
>> The name should be _GR1616. Using GR16 for the fourcc seems OK to me
>> since we can't fit in the full GR1616 in there. Althogh GR32 could work
>> too I suppose.
>>
>> And what about RG16?
>>
>> >
>> > Also, please put dri-devel on CC.
>> >
>> > Thanks
>> > David
>> >
>> > >  /* 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 */
>> > > --
>> > > 2.9.3
>> > >
>> > ___
>> > dri-devel mailing list
>> > dri-devel at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> --
>> Ville Syrjälä
>> Intel OTC
>
>

Updated patch as suggested by Ville Syrjälä


>From 29e74ff96e0b7c7a11d1b4131891b83adde621c1 Mon Sep 17 00:00:00 2001

From: Rainer Hochecker 

Date: Mon, 2 Jan 2017 11:25:18 +0100

Subject: [PATCH] drm: add fourcc codes for 16bit R and GR


Signed-off-by: Rainer Hochecker 

---

 include/uapi/drm/drm_fourcc.h | 7 +++

 1 file changed, 7 insertions(+)


diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h

index a5890bf..f1ef9cb 100644

--- a/include/uapi/drm/drm_fourcc.h

+++ b/include/uapi/drm/drm_fourcc.h

@@ -41,10 +41,17 @@ extern "C" {

 /* 8 bpp Red */

 #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */



+/* 16 bpp Red */

+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15: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 */



+/* 32 bpp GR */

+#define DRM_FORMAT_RG32 fourcc_code('R', 'G', '3', '2') /* [31:0] G:R
16:16 little endian */

+#define DRM_FORMAT_GR32 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
16:16 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 */

-- 

2.9.3

[PATCH v2] drm: add fourcc codes for 16bit R and GR

2017-01-03 Thread Rainer Hochecker 
From: Rainer Hochecker 

Now sent with git send-email:

Signed-off-by: Rainer Hochecker 
---
 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..f1ef9cb 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */

+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15: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 */

+/* 32 bpp GR */
+#define DRM_FORMAT_RG32fourcc_code('R', 'G', '3', '2') /* 
[31:0] G:R 16:16 little endian */
+#define DRM_FORMAT_GR32fourcc_code('G', 'R', '3', '2') /* 
[31:0] G:R 16:16 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 */
-- 
2.9.3

[PATCH v3] drm: add fourcc codes for 16bit R and RG

2017-01-04 Thread Rainer Hochecker 
From: Rainer Hochecker 

This adds fourcc codes for 16bit planes required for DRM buffer
export to mesa.

Signed-off-by: Rainer Hochecker 
---
 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..85079cd 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */

+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15: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 */

+/* 32 bpp GR */
+#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] G:R 
16:16 little endian */
+#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
16:16 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 */
-- 
2.9.3

[PATCH v4] drm: add fourcc codes for 16bit R and RG

2017-01-04 Thread Rainer Hochecker 
From: Rainer Hochecker 

Signed-off-by: Rainer Hochecker 
---
 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..4d65fb6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */

+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15: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 */

+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] G:R 
16:16 little endian */
+#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
16:16 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 */
-- 
2.9.3

[PATCH v5] drm: add fourcc codes for 16bit R and RG

2017-01-04 Thread Rainer Hochecker 
From: Rainer Hochecker 

Thanks for bearing with me. My ml skills have greatly improved now :)

v5 of patch:

This adds fourcc codes for 16bit planes required for DRM buffer
export to mesa.

Signed-off-by: Rainer Hochecker 
---
 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..e7f6bcd 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */

+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15: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 */

+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
16:16 little endian */
+#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
16:16 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 */
-- 
2.9.3

[PATCH v6] drm: add fourcc codes for 16bit R and RG

2017-01-04 Thread Rainer Hochecker 
From: Rainer Hochecker 

This adds fourcc codes for 16bit planes required for DRM buffer
export to mesa.

Signed-off-by: Rainer Hochecker 
---
 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..d230e58 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */

+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R 
little endian */
+
 /* 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 */

+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
16:16 little endian */
+#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
16:16 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 */
-- 
2.9.3

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-06-16 Thread Rainer Hochecker 
Daniel,

Peter posted me some snippets about your discussion around vblank that
confused me. Our use case is as follows:
We synchronise our video player clock to the pace of the display. Assume we
play some 23.976 content and the actual refresh rate is 24hz. We increment
the clock every vblank, that makes the clock run faster. Audio is resampled
to the faster running clock.
For this we just need an event fired for vblank.

Another requirement not directly related to 1)
We would like to know when a frame in actually presented on screen. Now
this is only guessing.

Rainer

On Wed, Jun 15, 2016 at 10:57 AM, Daniel Vetter 
wrote:

> On Wed, Jun 15, 2016 at 9:29 AM, Michel Dänzer  wrote:
> > On 14.06.2016 18:35, Daniel Vetter wrote:
> >> On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer 
> wrote:
> >>> On 14.06.2016 18:03, Daniel Vetter wrote:
>  Somehow this escaped us, this is a KMS ioctl which should only be used
>  by the master (which is the thing that's also in control of kms
>  resources). Everything else is bound to result in fail.
> 
>  Clients shouldn't have a trouble coping with this, since a pile of
>  drivers don't support vblank waits (or just randomly fall over when
>  using them). Note that the big motivation for abusing this like mad
>  seems to be that EGL doesn't have OML_sync, but somehow it didn't
>  cross anyone's mind that adding OML_sync to EGL would be useful.
> >>>
> >>> That may be one motivation, but it's certainly not the only one.
> >>> DRM_IOCTL_WAIT_VBLANK is used by apps which don't use EGL or any
> similar
> >>> API at all.
> >>
> >> Hm, what else?
> >
> > Off the top of my head, I know specifically about compton and xfwm4.
> > There's certainly more.
>
> But do they anything more fancy than what could be achieved with
> OML_sync too? Or is the issue that they don't want to use EGL/GLX? In
> that case I think it's reasonable to ask them to use bare-metal
> Present, since that's not any less portable than using the vblank
> ioctl.
>
> > Note that as I mentioned before in the other thread, I absolutely agree
> > that DRM_IOCTL_WAIT_VBLANK isn't supposed to be used directly. But the
> > fact of the matter is that it is being used like that (possibly has been
> > since before the DRM master concept even existed), and presumably it
> > actually works with simple setups (which might be the majority). So
> > there might be some backlash if it suddenly stops working.
>
> Fully agreed. Hence just RFC, and yes we need to get the EGL extension
> in place first, and at least kick most of the popular apps to have
> their code ready, and wait a bit, and wait some more, before we can
> nuke the ioctl from the kernel for non-master. It'll probably take 5
> years if we're fast :( I do think that we should be ok with breaking
> the last few hold-outs, but we definitely need to have an alternate
> solution for EGL ready. Hence why I want to know whether there's
> anyone who's using this outside of EGL.
>
> Really this was just drive-by that I spotted while looking around at
> stuff for our other discussion around vblanks.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-06-17 Thread Rainer Hochecker 
Daniel,

I agree. GLX_OML_sync_control fulfils all our requirements apart from being
available for EGL. It would be great to have it available for EGL. In
regard to Wayland this is really important. For the time being Kodi stopped
supporting Wayland because a/v sync is not possible on that platform.

Rainer

On Thu, Jun 16, 2016 at 6:17 PM, Daniel Vetter 
wrote:

> On Thu, Jun 16, 2016 at 3:02 PM, Rainer Hochecker 
> wrote:
> > Daniel,
> >
> > Peter posted me some snippets about your discussion around vblank that
> > confused me. Our use case is as follows:
> > We synchronise our video player clock to the pace of the display. Assume
> we
> > play some 23.976 content and the actual refresh rate is 24hz. We
> increment
> > the clock every vblank, that makes the clock run faster. Audio is
> resampled
> > to the faster running clock.
> > For this we just need an event fired for vblank.
> >
> > Another requirement not directly related to 1)
> > We would like to know when a frame in actually presented on screen. Now
> this
> > is only guessing.
>
>
> If you do vblank support right (which means GLX_OML_sync_control, it
> should work on mesa/glx but not anywhere else unfortunately) you get
> both. That's what I mean with calling the vblank ioctl directly is a
> hack: It's only really one half of correctly done a/v sync, you get
> the clock source but still have no idea when the frames actually show
> up. GLX_OML_sync_control (and a port to EGL/wayland, if someone
> bothers with that) gives you that control, plus ofc still a clock
> source which is as accurate as the current one (since it's the same).
>
> Note that DRI2/DRI3 and wayland all support this already, it's just a
> matter of wiring it up as an EGL extension. And of course it won't
> work on nvidia blobs because they just suck at this and don't want to
> let apps control all the double/triple buffering and whatever else
> they have in their driver.
>
> Note that the only reason this works on mesa is because Mario Kleiner
> really cares about it, and fixed up all the bugs across the entire
> stack (meas, X, kernel drivers). Mario might be interested in an EGL
> version of all this, not sure. Adding him.
>
> Oh and: Please feel free to add other video players and folks
> interested in this, I don't know them really at all.
>
> Cheers, Daniel
>
> >
> > Rainer
> >
> > On Wed, Jun 15, 2016 at 10:57 AM, Daniel Vetter 
> > wrote:
> >>
> >> On Wed, Jun 15, 2016 at 9:29 AM, Michel Dänzer 
> wrote:
> >> > On 14.06.2016 18:35, Daniel Vetter wrote:
> >> >> On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer 
> >> >> wrote:
> >> >>> On 14.06.2016 18:03, Daniel Vetter wrote:
> >> >>>> Somehow this escaped us, this is a KMS ioctl which should only be
> >> >>>> used
> >> >>>> by the master (which is the thing that's also in control of kms
> >> >>>> resources). Everything else is bound to result in fail.
> >> >>>>
> >> >>>> Clients shouldn't have a trouble coping with this, since a pile of
> >> >>>> drivers don't support vblank waits (or just randomly fall over when
> >> >>>> using them). Note that the big motivation for abusing this like mad
> >> >>>> seems to be that EGL doesn't have OML_sync, but somehow it didn't
> >> >>>> cross anyone's mind that adding OML_sync to EGL would be useful.
> >> >>>
> >> >>> That may be one motivation, but it's certainly not the only one.
> >> >>> DRM_IOCTL_WAIT_VBLANK is used by apps which don't use EGL or any
> >> >>> similar
> >> >>> API at all.
> >> >>
> >> >> Hm, what else?
> >> >
> >> > Off the top of my head, I know specifically about compton and xfwm4.
> >> > There's certainly more.
> >>
> >> But do they anything more fancy than what could be achieved with
> >> OML_sync too? Or is the issue that they don't want to use EGL/GLX? In
> >> that case I think it's reasonable to ask them to use bare-metal
> >> Present, since that's not any less portable than using the vblank
> >> ioctl.
> >>
> >> > Note that as I mentioned before in the other thread, I absolutely
> agree
> >> > that DRM_IOCTL_WAIT_VBLANK isn't supposed to be used directly. But the
> >> > fact of the matter is that it is being used

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-06-20 Thread Rainer Hochecker 
Thanks a lot.
Would you know if/when Wayland will support OpenGL?

Rainer

On Mon, Jun 20, 2016 at 4:46 PM, Daniel Stone  wrote:

> Hi Rainer,
>
> On 17 June 2016 at 22:00, Rainer Hochecker  wrote:
> > I agree. GLX_OML_sync_control fulfils all our requirements apart from
> being
> > available for EGL. It would be great to have it available for EGL. In
> regard
> > to Wayland this is really important. For the time being Kodi stopped
> > supporting Wayland because a/v sync is not possible on that platform.
>
> This isn't true. For Wayland, you can use the wp_presentation_time
> extension:
>
> https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/presentation-time/presentation-time.xml
>
> If you're using the zwp_linux_dmabuf extension directly, then you can
> easily and obviously use the extension to get feedback, and there are
> examples of using this. But even if you're using EGL, Wayland's EGL
> client platform has the property that a wl_surface::commit request
> must be issued from inside eglSwapBuffers. So you can make use of this
> to issue a presentation_time feedback request immediately before
> calling eglSwapBuffers, which will return a unique event giving you
> the exact time that the buffer swap was actually displayed on screen.
> This is far better than vblank requests which only give you hardware
> clock ticks, and tell you nothing about actual display time.
>
> I do discuss this with Peter occasionally, but please get in touch if
> you feel there is anything else missing, because we have gone to great
> lengths to make Wayland as good as it possibly can be for exactly
> these usecases.
>
> Cheers,
> Daniel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/9348a018/attachment-0001.html>

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-06-21 Thread Rainer Hochecker 
Are you saying that this is outdated:
https://wayland.freedesktop.org/faq.html#heading_toc_j_12

*A more subtle point is that libGL.so includes the GLX symbols, so linking
to that library will pull in all the X dependencies. This means that we
can't link to full GL without pulling in the client side of X, so we're
using GLES2 for now. Longer term, we'll need a way to use full GL under
Wayland.*

On Tue, Jun 21, 2016 at 1:27 AM, Daniel Stone  wrote:

> Hi,
>
> On 21 June 2016 at 04:24, Rainer Hochecker  wrote:
> > Thanks a lot.
> > Would you know if/when Wayland will support OpenGL?
>
> Er, it always has ... ?
>
> It will never support GLX (as the name implies, that's X-specific),
> but EGL is perfectly capable of creating OpenGL contexts. It works
> fine.
>
> Cheers,
> Daniel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/427ca03b/attachment-0001.html>

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-06-21 Thread Rainer Hochecker 
Thanks for clarification. That changes my view on Wayland.

Cheers,
Rainer

On Tue, Jun 21, 2016 at 7:01 AM, Daniel Stone  wrote:

> Hi,
>
> On 21 June 2016 at 14:57, Rainer Hochecker  wrote:
> > Are you saying that this is outdated:
> > https://wayland.freedesktop.org/faq.html#heading_toc_j_12
> >
> > A more subtle point is that libGL.so includes the GLX symbols, so
> linking to
> > that library will pull in all the X dependencies. This means that we
> can't
> > link to full GL without pulling in the client side of X, so we're using
> > GLES2 for now. Longer term, we'll need a way to use full GL under
> Wayland.
>
> Badly worded, really.
>
> libGL.so includes the GLX API entrypoints, so your libGL will link to
> X11. For that reason - and because there's no need for it to use full
> GL - Weston uses GLES2 for its own composition. For clients, if you
> don't care about this, then you can use libGL + EGL (this has always
> worked), or there's also libglvnd's libOpenGL (this is new). Given
> that, it should be reworded.
>
> Cheers,
> Daniel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/68ea0658/attachment-0001.html>

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-06-23 Thread Rainer Hochecker 
I spent some time reading and investigating on this. Bear with me, I am
doing Kodi development in my spare time and may not be up-to-date on all
platforms. Seems Wayland is much better suited to serve as reference
platform as X11 does. Is that correct? If so I don't request OML_sync_control
for EGL. Don't waste resources and let the old crap die.

Rainer

On Tue, Jun 21, 2016 at 7:15 AM, Rainer Hochecker 
wrote:

> Thanks for clarification. That changes my view on Wayland.
>
> Cheers,
> Rainer
>
> On Tue, Jun 21, 2016 at 7:01 AM, Daniel Stone 
> wrote:
>
>> Hi,
>>
>> On 21 June 2016 at 14:57, Rainer Hochecker  wrote:
>> > Are you saying that this is outdated:
>> > https://wayland.freedesktop.org/faq.html#heading_toc_j_12
>> >
>> > A more subtle point is that libGL.so includes the GLX symbols, so
>> linking to
>> > that library will pull in all the X dependencies. This means that we
>> can't
>> > link to full GL without pulling in the client side of X, so we're using
>> > GLES2 for now. Longer term, we'll need a way to use full GL under
>> Wayland.
>>
>> Badly worded, really.
>>
>> libGL.so includes the GLX API entrypoints, so your libGL will link to
>> X11. For that reason - and because there's no need for it to use full
>> GL - Weston uses GLES2 for its own composition. For clients, if you
>> don't care about this, then you can use libGL + EGL (this has always
>> worked), or there's also libglvnd's libOpenGL (this is new). Given
>> that, it should be reworded.
>>
>> Cheers,
>> Daniel
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160623/c08e8fa8/attachment-0001.html>

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-07-13 Thread Rainer Hochecker 
Whatever action is taken, it is fine for Kodi. GLX+OML_sync_control is not
an option anymore because we need EGL for vaapi. But we can fall back to
the invisible window for getting vsync. I never tried using EGL and GLX in
the same application, different windows. Any reason why this should not
work?

Rainer

On Tue, Jul 12, 2016 at 12:29 PM, Daniel Vetter  wrote:

> On Fri, Jun 24, 2016 at 06:55:55AM +1000, Daniel Stone wrote:
> > Hi Rainer,
> >
> > On 24 June 2016 at 05:54, Rainer Hochecker  wrote:
> > > I spent some time reading and investigating on this. Bear with me, I am
> > > doing Kodi development in my spare time and may not be up-to-date on
> all
> > > platforms. Seems Wayland is much better suited to serve as reference
> > > platform as X11 does. Is that correct? If so I don't request
> > > OML_sync_control for EGL. Don't waste resources and let the old crap
> die.
> >
> > I certainly think so, for a number of reasons. I don't believe X11
> > will ever be as accurate or as efficient as Wayland can be.
>
> Seconded. I think GLX+OML_sync_control for X11 and Wayland with EGL and
> the frame timing Daniel Stone laid out (already should work in both cases)
> seems like the perfect solution.
>
> What kind of transition plan would be reasonable? Should we start with a
> printk_once to inform userspace developers that they should change their
> code, and then eventually (after a few years or so) remove that ioctl?
> Maybe first behind a module option?
>
> Who should all be on cc for such a change?
>
> I'd like to get this started, it'll take years no matter what ...
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160713/2b76e6ae/attachment-0001.html>

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-07-13 Thread Rainer Hochecker 
We have been using this for years now and did not observe issues you
mentioned. I would be surprised if a child window refreshes in a different
rate than the main window
Am 13.07.2016 11:44 schrieb "Michel Dänzer" :

On 13.07.2016 15:50, Rainer Hochecker wrote:
> Whatever action is taken, it is fine for Kodi. GLX+OML_sync_control is
> not an option anymore because we need EGL for vaapi. But we can fall
> back to the invisible window for getting vsync. I never tried using EGL
> and GLX in the same application, different windows. Any reason why this
> should not work?

An invisible window may not synchronize with the same output refresh
cycle as your output window.


--
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160713/c2ad5b90/attachment.html>

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-07-13 Thread Rainer Hochecker 
GLX can't interop with libva in a reasonable way. That was the reason why
we switched to EGL
Am 13.07.2016 11:48 schrieb "Daniel Vetter" :

On Wed, Jul 13, 2016 at 06:43:37PM +0900, Michel Dänzer wrote:
> On 13.07.2016 15:50, Rainer Hochecker wrote:
> > Whatever action is taken, it is fine for Kodi. GLX+OML_sync_control is
> > not an option anymore because we need EGL for vaapi. But we can fall
> > back to the invisible window for getting vsync. I never tried using EGL
> > and GLX in the same application, different windows. Any reason why this
> > should not work?
>
> An invisible window may not synchronize with the same output refresh
> cycle as your output window.

Why do you need EGL for libva? Besides that noob question from me, no idea
how well EGL/GLX can interop at all ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160713/899cfec0/attachment-0001.html>

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

2016-07-25 Thread Rainer Hochecker 
Am 25.07.2016 08:38 schrieb "Michel Dänzer" :
>
> On 13.07.2016 18:49, Rainer Hochecker wrote:
> > We have been using this for years now and did not observe issues you
> > mentioned. I would be surprised if a child window refreshes in a
> > different rate than the main window
>
> The Xorg driver decides which CRTC to synchronize with based on the
> window geometry. For a window with no visible geometry, it may choose a
> different CRTC than for the visible output window. In the case of DRI3,
> the Xorg Present extension code may even fall back to the fake CRTC in
> that case, which only generates a fake vblank event once every second.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>

That means that we won't have a solution for X11 with EGL for Intel systems
anymore.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160725/52b4ca22/attachment.html>