>>
>
> 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 co
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 issues you
mentioned. I would be surprise
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 surprised if a child window refreshes in
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 ge
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 d
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, d
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 Kod
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 fi
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 get
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
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.
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 X1
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
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
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.
Cheer
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
> >
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 sid
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
> suppor
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 E
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
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
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, tha
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
>>> res
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 m
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, sinc
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
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 j
27 matches
Mail list logo
