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

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

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

On 05/05/2017 09:35 PM, Daniel Vetter wrote: On Mon, Jul 25, 2016 at 1:15 PM, Rainer Hochecker wrote: 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

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

On Mon, Jul 25, 2016 at 1:15 PM, Rainer Hochecker wrote: > 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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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.

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

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 >

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

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

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

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 >

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

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

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

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

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

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

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

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,

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

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

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

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

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

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,

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

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

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

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