On 03/20/2012 05:02 PM, Kristian Hoegsberg wrote:
> On Tue, Mar 20, 2012 at 11:54:56AM +0200, Ander Conselvan de Oliveira wrote:
>> When the compositor is in a repaint cycle, input is processed only once
>> per frame. However, a call to evdev_input_device_data() would handle at
>> most 8 events at
On Tue, Mar 20, 2012 at 12:14:33AM +0100, Rafał Mielniczuk wrote:
> From: Rafal Mielniczuk
>
> How to reproduce: rotate the surface to something like 45 degrees,
> resize it drastically, continue to rotate. The surface will jump
> some space and the rotation point will not be in the center
> of t
On Tue, Mar 20, 2012 at 11:54:56AM +0200, Ander Conselvan de Oliveira wrote:
> When the compositor is in a repaint cycle, input is processed only once
> per frame. However, a call to evdev_input_device_data() would handle at
> most 8 events at time. When there was more than 8 events pending for a
>
Your MUA seems to spit out 6km long lines, which makes it very
hard to read when you also post code so I can't auto-reformat
on my end. I'll give it a go though.
On 03/20/2012 06:39 PM, Bill Spitzak wrote:
> I may not be understanding the problem, or maybe my assumption that
> the destruction of a
On Tue, Mar 20, 2012 at 01:48:46AM +0800, zhaojuan...@gmail.com wrote:
> From: Juan Zhao
>
> Initializing pitch to 1 to avoid xxx/pitch errors
> This won't influence the valid texture coordinate calculation, because
> in that case buffer_attach will provide the correct value.
> ---
Thanks, look
On Sat, Mar 17, 2012 at 03:22:03PM -0700, Bill Spitzak wrote:
> Pausing weston (with ^Z in the shell) and putting it in the
> background made it hang.
>
> It actually never called sigchld when I killed or made clients exit,
> so it is not clear if this handler is needed at all.
Oh, yeah, oops. T
On Sat, Mar 17, 2012 at 01:43:52PM -0700, Bill Spitzak wrote:
> This makes the compositor and demo clients work on the current
> nouveau nvfx driver. Obviously does not fix any clients that
> actually want a depth buffer, but this does allow more people to at
> least try wayland.
Ok, yeah, that's
On Sat, Mar 17, 2012 at 07:09:39PM +0200, ustun.ergeno...@gmail.com wrote:
> From: Üstün Ergenoğlu
Yeah, not a bad idea.
thanks,
Kristian
> Signed-off-by: Üstün Ergenoğlu
> ---
> configure.ac | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac
On Fri, Mar 16, 2012 at 05:33:03PM -0300, Tiago Vignatti wrote:
> mtdev library translates all multitouch based devices to the slotted evdev
> protocol. It provides an uniform interface for Weston, which eases mt
> implementation when dealing with a big variety of devices.
>
> Weston on drm now di
On Fri, Mar 16, 2012 at 05:25:11PM +0200, Ander Conselvan de Oliveira wrote:
> Commit f992b2fc removed the saved keyboard focus logic to fix a crash
> when the saved surface is destroyed. However, setting keyboard focus to
> the first surface on the list ends up trying to set the focus to the
> cur
On Wed, Mar 14, 2012 at 10:07:58PM +0200, ustun.ergeno...@gmail.com wrote:
> From: Ustun Ergenoglu
Thanks, applied.
Kristian
> Otherwise a non-existent file in the configuration crashes the desktop shell.
>
> Signed-off-by: Ustun Ergenoglu
> ---
> clients/cairo-util.c |4
> 1 files
On Wed, Mar 14, 2012 at 02:47:40PM +0200, Ander Conselvan de Oliveira wrote:
> ---
> Figured that now that we have unit tests, I should write a test that
> fails without the previous patch and passes with it.
Thanks Ander.
Kristian
> tests/Makefile.am |7 -
> tests/event-loop-test
On Tue, Mar 13, 2012 at 01:16:13PM +0200, Ander Conselvan de Oliveira wrote:
> The post-dispatch check on wl_event_loop_dispatch() was not being run
> if epoll_wait returned 0 events, making the check unreliable.
> ---
>
> With the changes on Weston to process input during output repaint, this
> b
On Tue, Mar 20, 2012 at 12:45 PM, Kristian Hoegsberg
wrote:
> On Sun, Mar 11, 2012 at 07:48:45PM -0500, Rob Clark wrote:
>> From: Rob Clark
>>
>> For deferred rendering GPUs, some magic under the hood of eglSwapBuffers()
>> is responsible for making sure rendering has actually started. (glFlush(
On Mon, Mar 12, 2012 at 07:40:09PM -0300, Tiago Vignatti wrote:
> now it goes from 0 to 255.
Looks good, thanks.
Kristian
> Signed-off-by: Tiago Vignatti
> ---
> src/compositor-drm.c | 12 ++--
> src/compositor.h |2 +-
> src/shell.c | 17 +++--
> 3 file
On Mon, Mar 12, 2012 at 07:40:08PM -0300, Tiago Vignatti wrote:
> Signed-off-by: Tiago Vignatti
Thanks, applied.
Kristian
> ---
> tests/Makefile.am|9 ++-
> tests/setbacklight.c | 191
> ++
> 2 files changed, 199 insertions(+), 1 deletio
On Sun, 11 Mar 2012 19:48:43 -0500
Rob Clark wrote:
> From: Rob Clark
>
> ---
> src/compositor-drm.c |9 -
> 1 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 500ec15..cf9a937 100644
> --- a/src/compositor-drm.c
>
On Mon, Mar 12, 2012 at 04:06:01PM +0800, zhiwen...@linux.intel.com wrote:
> From: Alex Wu
>
> In case of no regular window, switcher will crash in switch_next()
> due to "next == NULL" and in switcher_destroy() due to
> "switcher->current == NULL".
Thanks, applied.
Kristian
> ---
> src/shell.
On Sun, Mar 11, 2012 at 07:48:45PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> For deferred rendering GPUs, some magic under the hood of eglSwapBuffers()
> is responsible for making sure rendering has actually started. (glFlush()
> doesn't do the trick.)
>
> I've managed to make weston drm co
I may not be understanding the problem, or maybe my assumption that the
destruction of a "source" is not under Wayland's control.
My opinion is that "deferred deletion" is a bad idea. There may be other
objects being destroyed that destroy the source, and they rely on the
source actually disap
On 03/16/2012 04:41 PM, Tiago Vignatti wrote:
On 03/16/2012 04:39 PM, David Herrmann wrote:
Hi Tiago
On Fri, Mar 16, 2012 at 8:37 PM, Tiago Vignatti
wrote:
Hi,
On 03/16/2012 12:42 PM, Николай Антонов wrote:
It's high time to begin discussing application ideas with mentoring
organizations
On 03/20/2012 05:06 AM, Pekka Paalanen wrote:
On Tue, 20 Mar 2012 00:57:49 -0300
Tiago Vignatti wrote:
+ if (help) {
+ dump_options(core_options, ARRAY_LENGTH(core_options));
+ argv[argc] = strdup("--help");
+ argc++;
How do you know there is s
On 03/20/2012 06:54 AM, Ander Conselvan de Oliveira wrote:
When the compositor is in a repaint cycle, input is processed only once
per frame. However, a call to evdev_input_device_data() would handle at
most 8 events at time. When there was more than 8 events pending for a
given frame, input lag
On Tue, Mar 20, 2012 at 3:40 PM, Kristian Høgsberg wrote:
> On Tue, Mar 20, 2012 at 9:21 AM, Jonas Ådahl wrote:
>> Instead of directly destroying an event source upon removal only destroy
>> it in case its event loop is not dispatching. If dispatching the event
>> source is marked for destruction
On Tue, Mar 20, 2012 at 9:21 AM, Jonas Ådahl wrote:
> Instead of directly destroying an event source upon removal only destroy
> it in case its event loop is not dispatching. If dispatching the event
> source is marked for destruction and added to the check list and
> destroyed in post_dispatch_ch
On 03/20/2012 02:28 PM, Jonas Ådahl wrote:
> On Tue, Mar 20, 2012 at 2:22 PM, Andreas Ericsson wrote:
>> When a dispatch for sourceA wishes to remove sourceB and sourceB
>> has input that isn't yet processed, we would run into the dreaded
>> "undefined behaviour" previously.
>>
>> With this patch,
On 03/20/2012 02:21 PM, Jonas Ådahl wrote:
> Instead of directly destroying an event source upon removal only destroy
> it in case its event loop is not dispatching. If dispatching the event
> source is marked for destruction and added to the check list and
> destroyed in post_dispatch_check(); if
On 03/20/2012 03:21 PM, Jonas Ådahl wrote:
Instead of directly destroying an event source upon removal only destroy
it in case its event loop is not dispatching. If dispatching the event
source is marked for destruction and added to the check list and
destroyed in post_dispatch_check(); if not it
On Tue, Mar 20, 2012 at 2:22 PM, Andreas Ericsson wrote:
> When a dispatch for sourceA wishes to remove sourceB and sourceB
> has input that isn't yet processed, we would run into the dreaded
> "undefined behaviour" previously.
>
> With this patch, the destroyed source is marked as such by its
> r
When a dispatch for sourceA wishes to remove sourceB and sourceB
has input that isn't yet processed, we would run into the dreaded
"undefined behaviour" previously.
With this patch, the destroyed source is marked as such by its
removal function and ignored while processing input. We free() it
only
Instead of directly destroying an event source upon removal only destroy
it in case its event loop is not dispatching. If dispatching the event
source is marked for destruction and added to the check list and
destroyed in post_dispatch_check(); if not it is destroyed immediately.
Signed-off-by: Jo
On 03/20/2012 01:19 PM, Ander Conselvan de Oliveira wrote:
> Hi,
>
> See comments below.
>
> On 03/20/2012 12:31 PM, Andreas Ericsson wrote:
>> When a dispatch for sourceA wishes to remove sourceB and sourceB
>> has input that isn't yet processed, we would run into the dreaded
>> "undefined behav
Hi,
See comments below.
On 03/20/2012 12:31 PM, Andreas Ericsson wrote:
When a dispatch for sourceA wishes to remove sourceB and sourceB
has input that isn't yet processed, we would run into the dreaded
"undefined behaviour" previously.
With this patch, the destroyed source is ignored while pr
When a dispatch for sourceA wishes to remove sourceB and sourceB
has input that isn't yet processed, we would run into the dreaded
"undefined behaviour" previously.
With this patch, the destroyed source is ignored while processing
input and is later free()'d in the post_dispatch_check() loop.
Sig
On 03/19/2012 09:44 PM, Bill Spitzak wrote:
>
>
> Jonas Ådahl wrote:
>> On Mon, Mar 19, 2012 at 7:10 PM, Bill Spitzak
>> wrote:
>>> Jonas Ådahl wrote:
>>>
That would not work because ep[i].data.ptr will already be
loaded with the source pointer pointing to deallocated memory.
It
When the compositor is in a repaint cycle, input is processed only once
per frame. However, a call to evdev_input_device_data() would handle at
most 8 events at time. When there was more than 8 events pending for a
given frame, input lag would occur. This was most visible with multi
touch input.
T
On Mon, Mar 19, 2012 at 9:44 PM, Bill Spitzak wrote:
>
>
> Jonas Ådahl wrote:
>>
>> On Mon, Mar 19, 2012 at 7:10 PM, Bill Spitzak wrote:
>>>
>>> Jonas Ådahl wrote:
>>>
That would not work because ep[i].data.ptr will already be loaded with
the source pointer pointing to deallocated memor
On Tue, 20 Mar 2012 00:57:49 -0300
Tiago Vignatti wrote:
> >> + if (help) {
> >> + dump_options(core_options, ARRAY_LENGTH(core_options));
> >> + argv[argc] = strdup("--help");
> >> + argc++;
> >
> > How do you know there is space in argv[] to add that?
> > Also, doesn
38 matches
Mail list logo
