> I agree this all seems incredibly unlikely, and would love suggestions.
You probably have already done it, but in case not check your RAM with
memcheck and run a long selfcheck on the hdd with smartctl just to be sure.
Especially RAM errors can have peculiar effects, i.e I once had a system wo
On Monday 27 February 2012 12:52:16 David Jackson wrote:
> if the wayland API does not support high level vector graphics that itself
> makes me skeptical of wayland, to offload rendering to the GPU requires a
> high level vector rendering API used by apps to send vector graphics to the
> window sy
On Wednesday 15 February 2012 09:35:40 Pekka Paalanen wrote:
> Looks ok as a stop-gap measure to me, FWIW.
I somehow managed to skip a line from the first commit, and then forgot it in
the patch... there must be a line like:
struct weston_input_device *device;
before wl_list_for_each, or the co
if a client crashes during drag and drop a notify_motion
can be triggered after the surface has been destroyed, so traverse
all the input devices and look reset the corresponding grab
focus.
---
src/compositor.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/comp
gmail crippled my first patch, so here another try with git-send-email
Pavel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi! I was playing a little bit with wayland/weston after the 0.85
release, and mixed
up the installation paths making the clients/dnd example crash after
the first click.
While this is not a problem (for the compositor), there is a dangling
pointer in
device->grab->focus.
When I tried to drag a flo
