On Mon, 2012-07-16 at 21:51 -0700, Bill Spitzak wrote:
> I am attempting to build the newest git respository of wayland/weston.
>
> Weston was complaining about missing GLSL symbol
> PFNEGLUNBINDWAYLANDDISPLAYWL
>
> So I tried to pull and recompile mesa (I have up to now been able to
> work wi
On Mon, 2012-07-16 at 22:00 -0700, Bill Spitzak wrote:
> I guesses that --disable-glx would help and it did, but instead I ran
> into something compiling mesa that seems to be a more serious
> wayland-related problem:
>
> In file included from backends/dri/gbm_dri.c:48:0:
> backends/dri/../../.
I guesses that --disable-glx would help and it did, but instead I ran
into something compiling mesa that seems to be a more serious
wayland-related problem:
In file included from backends/dri/gbm_dri.c:48:0:
backends/dri/../../../egl/wayland/wayland-drm/wayland-drm.h:5:41: fatal
error: wayland
I am attempting to build the newest git respository of wayland/weston.
Weston was complaining about missing GLSL symbol
PFNEGLUNBINDWAYLANDDISPLAYWL
So I tried to pull and recompile mesa (I have up to now been able to
work with one I compiled a few months ago).
The configure line I used for
Alex,
Thanks for the patch :) After a preliminary glance, it seems ok however I will
not be able to commit this until I have had time to test it. I am currently
engaged with a few other projects at work so it may be some time before I can
get to this :( but I will save it in my TODO list and ge
Hello,
I'm trying to run one of the QtCompositor examples (qwindow-compositor) on
VMware from my Linux distribution which doesn't support X11 on purpose.
Mesa was built from git (checked out July 2nd at midnight) with the following
options:
--with-gallium-drivers=r300,r600,nouveau,svga,sw
On Mon, Jul 16, 2012 at 05:32:24PM +0300, Tiago Vignatti wrote:
> Signed-off-by: Tiago Vignatti
> ---
> v2: handle enter motion, for unmapped windows; weston_wm_destroy_cursors for
> destroying cursors properly.
>
> src/xwayland/window-manager.c | 163
>
On Mon, Jul 16, 2012 at 05:32:23PM +0300, Tiago Vignatti wrote:
> It's in fact based on the core of libXcursor, which doesn't bring any Xlib
> dependency.
>
> Signed-off-by: Tiago Vignatti
> ---
> v2: no file split; removed a bunch of xcb dependencies; style nit-picking
> fixed.
Looks good, than
On Mon, Jul 16, 2012 at 05:32:22PM +0300, Tiago Vignatti wrote:
> we were using wrong iterator for xcb_render_pictforminfo_t type, the
We're just using the wrong length. The xcb iterators aren't really
worth the trouble in my opinion, a regular for loop through the array
is a lot more straight fo
On Mon, Jul 16, 2012 at 02:15:48PM +0300, Ander Conselvan de Oliveira wrote:
> If the grab surface happens to be unresponsive, the busy cursor grab
> will be started and that will cause the grab surface to receive focus,
> which in turn leads to it being pingged again. Break the cycle by not
> send
On Mon, Jul 16, 2012 at 05:12:24PM +0300, Tiago Vignatti wrote:
> enter handler wasn't updating sprite coordinates based on the Wayland event
> just sent, failing when forwarding the correct EnterNotify to the X client.
>
> There was a doubt regarding whether ProcessInputEvents should be called ju
On Mon, Jul 16, 2012 at 04:20:12PM +0800, Juan Zhao wrote:
> Hi there,
> When I enabled mesa debug mode, westen reported one seg-fault error. Any
> ideas about it? Should we remove that assert for the "none" format, or
> some decent solution?
> The backtrace is like this:
I fixed intel_create_imag
On 16.07.2012 16:32, Tiago Vignatti wrote:
we were using wrong iterator for xcb_render_pictforminfo_t type, the
formats_reply->length; valgrind was shouting it loudly. Another issue this
patch addresses is that now find_depth returns the first util and valid format
that matches the desired depth;
This patch sets the cursor for the frame window only.
The other case left is when the client itself performs a grab instead the
titlebar drag. E.g. google-chrome without decoration does move a window (when
click-n-drag the bar on the side of the tabs) but the cursor doesn't set back
to the default
XCURSOR_SIZE is used on libXcursor to change the cursor size and toytoolkit
should read it as well for consistency with xwayland. If the env var is not
set, size 32 is hardcoded for both toytoolkit and xwayland.
Signed-off-by: Tiago Vignatti
---
v2: make cursor size configurable now via env var o
More pretty and also consistent with toytoolkit.
Signed-off-by: Tiago Vignatti
---
v2: set root cursor inside weston_wm_create.
src/xwayland/window-manager.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/src/xwayland/window-manager.c b/src/xwayland/windo
Signed-off-by: Tiago Vignatti
---
v2: handle enter motion, for unmapped windows; weston_wm_destroy_cursors for
destroying cursors properly.
src/xwayland/window-manager.c | 163 +
src/xwayland/xwayland.h |2 +
2 files changed, 165 insertions(+)
It's in fact based on the core of libXcursor, which doesn't bring any Xlib
dependency.
Signed-off-by: Tiago Vignatti
---
v2: no file split; removed a bunch of xcb dependencies; style nit-picking
fixed.
configure.ac |2 +-
src/xwayland/window-manager.c | 77 +++
we were using wrong iterator for xcb_render_pictforminfo_t type, the
formats_reply->length; valgrind was shouting it loudly. Another issue this
patch addresses is that now find_depth returns the first util and valid format
that matches the desired depth; it doesn't continue through the loop until t
enter handler wasn't updating sprite coordinates based on the Wayland event
just sent, failing when forwarding the correct EnterNotify to the X client.
There was a doubt regarding whether ProcessInputEvents should be called just
after SetCursorPosition or not in order to dequeue the event. When th
The grab surface does not depend on any of the shell surface
functionality, so don't allocated one.
---
clients/desktop-shell.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index fbc0604..cf28246 100644
--- a/clients/de
It is possible that a client loses the focus between receiving a
pointer.enter event and sending a pointer.set_cursor request. In that
case, the cursor surface might not be mapped and the frame callback
requested on it will never trigger.
Work around this by trying to remap the cursor surface when
If the grab surface happens to be unresponsive, the busy cursor grab
will be started and that will cause the grab surface to receive focus,
which in turn leads to it being pingged again. Break the cycle by not
sending pings to it. If the shell is unresponsive it won't be able to
set the busy cursor
On 07/16/2012 10:14 AM, juan.j.z...@linux.intel.com wrote:
From: Juan Zhao
When we're launching applications, we meet weston random unresponsive issue.
Regarding the backtrace, it is caused by set_busy_cursor->shell_grab_start->
wl_pointer_set_focus->wl_signal_emit->handle_pointer_focus->set_
It seems to be some mistake in adding YUV texture support.
For xrgb, the following patch works for me. Additional consideration is
required for yuv format( I can try it tomorrow).
>From 21682938f7ac2ab64e751b07e3bcda0516d4c6e9 Mon Sep 17 00:00:00 2001
From: Zhao Halley
Date: Mon, 16 Jul 2012 17
From: Alex Wu
The current wayland_egl engine uses a global singleton EGLContext
object to render context. All Evas_GL_Wl_Window objects, which
wraps EGLSurface, share this object, so we have no chance to
differentiate the frame buffer configuration for each EGLSurface.
When calling elm_win_alpha
Hi there,
When I enabled mesa debug mode, westen reported one seg-fault error. Any
ideas about it? Should we remove that assert for the "none" format, or
some decent solution?
The backtrace is like this:
(gdb) bt
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb7d5ccc1 in raise () from /lib/libc.s
From: Juan Zhao
When we're launching applications, we meet weston random unresponsive issue.
Regarding the backtrace, it is caused by set_busy_cursor->shell_grab_start->
wl_pointer_set_focus->wl_signal_emit->handle_pointer_focus->set_busy_cursor.
The busy cursor will be set by ping_timeout_handl
28 matches
Mail list logo
