On Mon, Oct 28, 2013 at 9:39 PM, Zhao, Halley wrote:
> Video player use frame callback on an event queue, sometimes there is
> synchronization issue.
>
> After looked at other usage of event queue, I found:
>
> In order to avoid blocking by wl_display_dispatch_queue(), a padding
> callba
Video player use frame callback on an event queue, sometimes there is
synchronization issue.
After looked at other usage of event queue, I found:
In order to avoid blocking by wl_display_dispatch_queue(), a padding callback
of wl_display_sync is added on purpose.
Is my understanding correct?
Here
On Mon, Oct 28, 2013 at 9:10 AM, Neil Roberts wrote:
> Just to be clear, I think the discussion about whether to queue release
> events is no longer related to implementing eglSwapInterval(0) so it
> shouldn't hold up the patch. As far as I understand if you want to
> render at the maximum rate y
Hi,
On 28 October 2013 15:47, Axel Davy wrote:
> On 28/10/2013, Frederic Plourde wrote :
>> I don't know about current/future driver support for this new GSYNC
>> technology... but you know what, I definitely agree with Pekka as we should
>> get this protocol and basic buffer queuing implementati
On Mon, Oct 28, 2013 at 10:17:45AM +0100, Tomeu Vizoso wrote:
> And also remove the vfunc definitions from the compositor as they
> are unused now.
> ---
> src/compositor.c | 9 -
> src/compositor.h | 2 --
> src/rpi-renderer.c | 29 -
> 3 files changed, 2
On 28/10/2013, Daniel Stone wrote :
For programers having to cope with X and Wayland, and to better support the
Present extension, I reiterate my suggestion
to do something similar to the X Present extension.
Anything in particular? I'm well aware of Present, but am not entirely
sure what you'r
Hi,
On 28 October 2013 21:13, Axel Davy wrote:
> On 28/10/2013, Daniel Stone wrote :
>>> For programers having to cope with X and Wayland, and to better support
>>> the
>>> Present extension, I reiterate my suggestion
>>> to do something similar to the X Present extension.
>>
>> Anything in parti
On 28/10/2013, Frederic Plourde wrote :
I don't know about current/future driver support for this new GSYNC
technology... but you know what, I definitely agree with Pekka as we
should get this protocol and basic buffer queuing implementation
reviewd and working for the general case for now and
Here is an updated version of the patch to address Axel Davy's
concerns and change the wording of the extension to make it clear that
the function can return EGL_BAD_MATCH for any reason which prevents
the buffer from being represented as a wl_buffer and not just due to
differences in the format. T
Just to be clear, I think the discussion about whether to queue release
events is no longer related to implementing eglSwapInterval(0) so it
shouldn't hold up the patch. As far as I understand if you want to
render at the maximum rate you need four buffer slots and being able to
disable the queuing
On 13-10-28 08:18 AM, Axel Davy wrote:
On Mon, 28 Oct 2013, Pekka Paalanen wrote:
The only immediate effect I could see for the protocol proposal is
to replace the frequency field in a "monitor refresh rate changed"
event with a min and max duration, or whatever that could actually
describe ho
Hi,
On 28 October 2013 11:19, Tomeu Vizoso wrote:
> I'm still concerned about platforms with high resolution displays but
> relatively little memory.
>
> I'm thinking of the RPi, but my understanding is that Android goes to
> great lengths to reduce the number of buffers that clients have to
> ke
On Mon, 28 Oct 2013, Pekka Paalanen wrote:
The only immediate effect I could see for the protocol proposal is
to replace the frequency field in a "monitor refresh rate changed"
event with a min and max duration, or whatever that could actually
describe how GSYNC affects timings.
I don't under
On 25 October 2013 16:50, Neil Roberts wrote:
> Ok, here is version 4 of the patch taking into account the discussion
> with Jason Ekstrand. The assumption is that if we have enough buffer
> slots then we should always get a release event immediately after one
> of the attaches.
I'm still concern
On Mon, 21 Oct 2013 10:50:05 -0400
Frederic Plourde wrote:
> On 13-10-18 05:59 PM, James Courtier-Dutton wrote:
> > We would also need the API to be compatible with "G-Sync".
> >
> > http://www.pcper.com/news/Graphics-Cards/NVIDIA-Announces-G-Sync-Variable-Refresh-Rate-Monitor-Technology
> >
> >
And also remove the vfunc definitions from the compositor as they
are unused now.
---
src/compositor.c | 9 -
src/compositor.h | 2 --
src/rpi-renderer.c | 29 -
3 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/src/compositor.c b/src/compos
Hi Axel
On Mon, Oct 28, 2013 at 12:34 AM, Axel Davy wrote:
>
> On 22/10/2013 17:23, David Herrmann wrote :
>
> Btw., I got this working with i915 by allowing GEM_OPEN/GEM_FLINK on
> the render-node. So if someone else tests this, you might need the
> same hacks. I will try to find the code in mes
On 10/25/2013 10:30 PM, Kristian Høgsberg wrote:
On Fri, Oct 25, 2013 at 04:26:33PM +0300, Ander Conselvan de Oliveira wrote:
Remove create_surface() and destroy_surface() from the renderer
interface and change the renderers to create surface state on demand
and destroy it using the weston_surfa
On 10/25/2013 06:27 PM, Jason Ekstrand wrote:
Ander,
When I was working on views, I really wanted to get rid of the
create_surface functions too... Thanks. That said, you should probably
also get rid of create_view (It's only used by rpi).
I wrote these patches before the views work was merged
On 27 October 2013 18:46, Paul wrote:
> Hi,
>
> I have been trying to build the latest Weston on my Raspberry Pi.
> In a recent patch there is a call to a new function
> 'vc_dispmanx_set_wl_buffer_in_use'.
> This is declared as a stub in 'rpi-bcm-stubs.h'.
> I have updated my Raspberry Pi to the l
20 matches
Mail list logo
