On Sun, Oct 27, 2013 at 10:24:57PM -0500, Jason Ekstrand wrote:
> This fixes the problem where animations will wait to play until input is
> received. In general, it also makes the backend far more responsive.
>
> Signed-off-by: Jason Ekstrand
> ---
> src/compositor-wayland.c | 3 +++
> 1 file
On Sun, Oct 27, 2013 at 10:24:53PM -0500, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> ---
> src/compositor-wayland.c | 76
> ++--
> 1 file changed, 41 insertions(+), 35 deletions(-)
>
> diff --git a/src/compositor-wayland.c b/src/composito
Bill,
Because I want to respond to everything in one e-mail, I'm going to try and
address your comments here even though they may not show up.
On Wed, Oct 30, 2013 at 3:19 PM, Rafael Antognolli wrote:
> Hi, I'm back to work on this, hopefully this time in a
> non-intermittent way. Some comments b
This allows the caller to specify whether the wl_buffer.release event (if
one is generated) should be sent immediately or queued for later. This
only makes a difference if this weston_buffer_reference call will release
the buffer. If there are other references to the buffer remaining, the
argumen
On Wed, Oct 30, 2013 at 3:59 AM, Tomeu Vizoso wrote:
> On 30 October 2013 09:44, Neil Roberts wrote:
> > Tomeu Vizoso writes:
> >
> >> What I fail to see is why a single sync should be enough, as we don't
> >> know when the GPU will signal that it's done with the buffer that we
> >> are waiting
Rafael Antognolli wrote:
I'm sorry, but I fail to understand how a user could choose between
click to focus, or sloopy focus, if that's up to the client to
implement it. Wouldn't this lead to something like: if I use this
video player A, but it only implements sloopy focus, and I want click
to f
Hi, I'm back to work on this, hopefully this time in a
non-intermittent way. Some comments below:
On Thu, Oct 24, 2013 at 12:00 AM, Bill Spitzak wrote:
> Jason Ekstrand wrote:
>
>> At this point, I think I can propose a solution which should allow for
>> client control while still keeping the com
> -Original Message-
> From: wayland-devel-boun...@lists.freedesktop.org
> [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Kristian
> Høgsberg
> Sent: Wednesday, October 30, 2013 8:48 AM
> To: Marek Ch
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: Wayland integ
Many thanks, Stefan!!! It did helped :)
Any feedback regarding ACLOCAL is still appreciated.
P.S. I'm sorry for not saying hello to everyone. I was writing for the
first time after all (but forgot).
HI EVERYONE!!!
On Wed, Oct 30, 2013 at 5:11 PM, Stefan Schmidt wrote:
> Hello.
>
>
>
> On 10/3
On Wed, Oct 30, 2013 at 08:33:21AM +0100, Marek Ch wrote:
> Hi,
>
> I've been recently writing a simple test framework and tests for wayland
> protocol. It should focus on testing display<->client interaction.
> The framework contains functions for creating wayland display, one client's
> process
On Sun, Oct 27, 2013 at 09:32:54PM -0500, Jason Ekstrand wrote:
> Without this commit, the client will segmentation fault due to accessing
> the frame after everything has been destroyed.
>
> ---
> clients/window.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Yup, I hit this a couple
On Oct 30, 2013 3:59 AM, "Tomeu Vizoso" wrote:
>
> On 30 October 2013 09:44, Neil Roberts wrote:
> > Tomeu Vizoso writes:
> >
> >> What I fail to see is why a single sync should be enough, as we don't
> >> know when the GPU will signal that it's done with the buffer that we
> >> are waiting to b
Hello.
On 10/30/2013 01:48 PM, Artsiom Anikeyenka wrote:
Any help on that? I'm not good at GNU build tools so it's hard to me to
figure out the reason. I'll be working on that, but maybe meanwhile
you'll give me a hint?
Where do you install wayland after building? To me it seems the place
wh
Any help on that? I'm not good at GNU build tools so it's hard to me to
figure out the reason. I'll be working on that, but maybe meanwhile you'll
give me a hint?
So I just built all the prerequisites without errors but while building
Weston I got that error and I can't work it around. I've seen s
On 30 October 2013 09:44, Neil Roberts wrote:
> Tomeu Vizoso writes:
>
>> What I fail to see is why a single sync should be enough, as we don't
>> know when the GPU will signal that it's done with the buffer that we
>> are waiting to be released.
>
> You are right that we don't know when the GPU
Tomeu Vizoso writes:
> What I fail to see is why a single sync should be enough, as we don't
> know when the GPU will signal that it's done with the buffer that we
> are waiting to be released.
You are right that we don't know when the GPU will release the buffer.
However we are not waiting for
Hi,
I've been recently writing a simple test framework and tests for wayland
protocol. It should focus on testing display<->client interaction.
The framework contains functions for creating wayland display, one client's
process and a few functions for communication between them (client can ask
for
>> > 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
18 matches
Mail list logo
