Is changing the signal handler rapidly wasteful?
It seems annoying to have this overhead to fix this problem. Could the
signal handler *always* be replaced, and just have a (per thread?) flag
that is turned on/off indicating how it can behave. Or could there be a
zero-cost method: the signal h
On Tue, Oct 01, 2013 at 12:53:03PM +0200, Tomeu Vizoso wrote:
> The EGL implementation on the RPi allocates a front and a back
> DispmanX resources for each EGLSurface, which we composite along
> the others.
Is this something you want in 1.3? We're the RC phase now and I hope
to release 1.3 this
On Tue, Oct 01, 2013 at 12:30:17PM +0200, Tomeu Vizoso wrote:
> With this patch plus the one I just sent about drop_privileges,
> weston-launch can be used on the rpi.
>
> Thanks!
Great, thanks for checking. Both patches are in master and will be in 1.3.
Kristian
> Tomeu
>
>
> On 27 Septembe
On Tue, Oct 01, 2013 at 12:27:19PM +0200, Tomeu Vizoso wrote:
> As struct wl_buffer has been deprecated since 1.2.
> ---
> src/weston-egl-ext.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Right, didn't see this warning as I typically compile against mesa.
Kristian
> diff --git
On Tue, Oct 01, 2013 at 12:20:29PM +0200, Tomeu Vizoso wrote:
> ---
> src/weston-launch.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
That looks good, applied.
Kristian
> diff --git a/src/weston-launch.c b/src/weston-launch.c
> index 525c61c..1b560af 100644
> --- a/src/weston-laun
On Mon, Sep 30, 2013 at 12:40:28PM +0200, Giulio Camuffo wrote:
> ---
> src/compositor.c | 16
> src/compositor.h | 11 ++-
> src/input.c | 18 +++---
> 3 files changed, 41 insertions(+), 4 deletions(-)
I think this idea makes sense, but let's do it after
On Mon, Sep 30, 2013 at 10:07:42PM +0200, Axel Davy wrote:
> Hi All,
>
> I've published a new XWayland DDX based on Glamor.
>
> The source code is inspired from the Radeon DDX.
>
> I've tested it on an intel hd4000 and an Amd hd7730m without issues.
> (Need a recent Xserver with XWayland support
On Mon, Sep 30, 2013 at 10:06:39PM -0500, Aaron Faanes wrote:
> ---
> src/compositor-wayland.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks, applied.
Kristian
> diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
> index 2b8b956..77b2a2c 100644
> --- a/src/composi
Hi
José Bollo writes:
> That is a really interesting point.
> I have two questions about it:
> - Is it normal that the client trucates the buffer? Is your patch
>designed to allow normal operations? or to allow forbiden uses?
> - If it is not "normal", is there good reasons to continue to
Hi,
On 1 October 2013 05:53, Tomeu Vizoso wrote:
> The EGL implementation on the RPi allocates a front and a back
> DispmanX resources for each EGLSurface, which we composite along
> the others.
> ---
>
> Remaining issues:
>
> * The EGL side isn't sending sync messages from SwapBuffers while wait
The EGL implementation on the RPi allocates a front and a back
DispmanX resources for each EGLSurface, which we composite along
the others.
---
Remaining issues:
* The EGL side isn't sending sync messages from SwapBuffers while waiting
for buffer.release events, so it requires weston to post th
With this patch plus the one I just sent about drop_privileges,
weston-launch can be used on the rpi.
Thanks!
Tomeu
On 27 September 2013 19:58, Adrian Negreanu wrote:
> From: Adrian Negreanu
>
> Add drm_set_master and drm_drop_master
> as wrappers for drm(Set|Drop)Master, when building compo
As struct wl_buffer has been deprecated since 1.2.
---
src/weston-egl-ext.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/weston-egl-ext.h b/src/weston-egl-ext.h
index bab87be..8ddf97f 100644
--- a/src/weston-egl-ext.h
+++ b/src/weston-egl-ext.h
@@ -42,15 +42,15 @@
---
src/weston-launch.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/weston-launch.c b/src/weston-launch.c
index 525c61c..1b560af 100644
--- a/src/weston-launch.c
+++ b/src/weston-launch.c
@@ -577,7 +577,8 @@ launch_compositor(struct weston_launch *wl, int argc, char
That is a really interesting point.
I have two questions about it:
- Is it normal that the client trucates the buffer? Is your patch
designed to allow normal operations? or to allow forbiden uses?
- If it is not "normal", is there good reasons to continue to
serve a nasty client?
Just curi
15 matches
Mail list logo