[PATCH 6/6] src/shell.c: restore app when workspace_num > 1 on unplugged output

when workspace_num > 1, the surface on hiden workspace is moved beyond any output through animation, but surface->output point to the last output of weston_compositor->output_list in weston_surface_assign_output(). So surface->output may point to a wrong output which isn't the output the surface be

[PATCH 3/6] src/shell.c: restroe app run on non default and unplugged output

if the unplugged output isn't the default output, move cursor surface and APP widow to default output Signed-off-by: Xiong Zhang --- src/compositor-drm.c | 2 + src/shell.c | 135 +++ 2 files changed, 137 insertions(+) diff --git a/src/

[PATCH 4/6] src/compositor.c shell.c: restroe app run on default and unplugged output

if the unplugged output is the first default output, the second output will move to the first working as default output. Mark the surface on unplaugged output as dirty, so the next output repaint, these surface will reassign output and get the right output. At the same time when moving output, the

[PATCH 1/6] srccompositor.c: set surface->plane from destroyed plane to NULL

In drm backend, the cursor_surface->plane point to drm_output->cursor_plane. when this output is removed, drm_output->cursor_plane is destroyed, but cursor_surface->plane still point to destroyed plane. So once mouse move to this cursor_surface and system will repaint this cursor_surface, segment f

[PATCH 5/6] clients/window.c, desktop-shell.c: deal with output unplug on client side

when output is removed, weston-desktop-shell should destroy panel and background surface on destroyed output. Signed-off-by: Xiong Zhang --- clients/desktop-shell.c | 20 clients/window.c| 32 clients/window.h| 3 +++ 3 files

[PATCH 2/6] src/shell.c: register output->destroy_signal handler

setup_output_destroy_handler() deal with output created at drm backend initialize time. handle_output_create() deal with output created by hot plug handler output_destroy_handler is removed when output was unplugged or shell is destroyed. Signed-off-by: Xiong Zhang --- src/shell.c | 75 +

Re: [PATCH 1/2] Patch to the Xserver to support AsyncSwap

I should have add a link to the initial patch: http://lists.x.org/archives/xorg-devel/2011-June/023102.html Other versions of the patch are: _http://lists.x.org/archives/xorg-devel/2012-November/034446.html

[PATCH 2/2] Add new XWayland API.

The new API: .Allows to use the frame event. .Introduces a new object: xwl_buffer, that allow to manipulate the buffer sent to the Wayland compositor. .Allows to use the release event. Signed-off-by: Axel Davy --- hw/xfree86/xwayland/Makefile.am| 2 + hw/xfree86/xwayland/xwayland-buffe

[PATCH 1/2] Patch to the Xserver to support AsyncSwap

The patch is a modified version of a Chris Wilson patch of 2011. It makes the X server call AsyncSwap, defined by the DDX, when it does a dri2 swap and swap_interval is 0. It allows the DDX to avoid the copy if possible, and reduce tearings. Signed-off-by: Axel Davy --- hw/xfree86/dri2/dri2.c |

[PATCH 0/2] Add New XWayland API

The current XWayland API has no functionality to help the DDXs implement ScheduleSwap. This new API proposal introduces functions to manipulate the frame event, the release event, and to manipulate the buffers that the Wayland compositor sees. The first patch is not linked directly to XWayland,

Re: Making Wayland accessible

Personally I am very worried about clients doing this. My main concern is clients acting differently than each other. This will happen even if every one of them is using a carefully written toolkit that implements all defined wayland behavior because they may be running on different hosts with

Re: [RFC] wl_surface video protocol extension

2013/10/16 Daniel Stone > On 16 October 2013 17:09, Jonas Kulla wrote: > > it might just be a stupid thought of mine, but it would be kinda cool > > if there was wayland protocol for creating an EGLStream [1] backed > > surface. > > It would be nice, but TTBOMK the only EGLStream implementation

SIGBUS when writing to a wl_shm surface on a full tmpfs / ftruncate() vs fallocate()

Hi, When creating a wl_shm pool with os_create_anonymous_file(), the underlying storage file is created on a tmpfs, and its size is set with ftruncate(). Though, when the tmpfs isn't big enough to hold this file, there is no error at the pool creation, since it is handled as a sparse file and

Re: [RFC] wl_surface video protocol extension

Hi, On 16 October 2013 17:09, Jonas Kulla wrote: > it might just be a stupid thought of mine, but it would be kinda cool > if there was wayland protocol for creating an EGLStream [1] backed > surface. It would be nice, but TTBOMK the only EGLStream implementation is in the Tegra EGL stack, which

Re: Making Wayland accessible

Hi, just replying to this part: On 15 October 2013 22:05, Matthias Clasen wrote: > - input tweaks like slow keys or bounce keys or hover-to-click naturally fit > in the event dispatching in the compositor In the same spirit of having key repeat on the client side, I think that slow, bounce and

Re: [RFC] wl_surface video protocol extension

2013/10/16 Jonas Kulla > 2013/10/16 Frederic Plourde > >> Hi everybody >> >> We're having needs for a streaming_video-capable wl_surface. An extended >> surface that could "queue buffers up" along with presentation timestamps in >> the compositor so that videosink clients (like gstreamer's wayla

Re: [RFC] wl_surface video protocol extension

2013/10/16 Frederic Plourde > Hi everybody > > We're having needs for a streaming_video-capable wl_surface. An extended > surface that could "queue buffers up" along with presentation timestamps in > the compositor so that videosink clients (like gstreamer's wayland > videosink) could more effect

[RFC] wl_surface video protocol extension

Hi everybody We're having needs for a streaming_video-capable wl_surface. An extended surface that could "queue buffers up" along with presentation timestamps in the compositor so that videosink clients (like gstreamer's wayland videosink) could more effectively and precisely synchronize audio

Re: [PATCH 2/2] protocol: add state set functions for maximized and fullscreen.

On Wed, Oct 16, 2013 at 2:53 AM, Kristian Høgsberg wrote: > On Tue, Oct 15, 2013 at 8:05 AM, wrote: >> From: Rafael Antognolli >> >> These functions only differ from the previous one because they request >> that the given state is set, without changing the surface type, thus >> removing any pre

[PATCH] xdg_shell: Add a new shell protocol.

From: Rafael Antognolli xdg_shell is a protocol aimed to substitute wl_shell in the long term, but will not be part of the wayland core protocol. It starts as a non-stable API, aimed to be used as a development place at first, and once features are defined as required by several desktop shells, w

Re: [PATCH 3/7] Make weston spawn weston-launch

Hi On Tue, Oct 15, 2013 at 8:07 PM, Kristian Høgsberg wrote: > On Tue, Oct 15, 2013 at 02:29:58PM +0200, David Herrmann wrote: >> This is a rather complete rewrite of weston-launch. Instead of spawning >> weston from weston-launch, we do the inverse now. Whenever weston is >> spawned with a backe

[PATCH] wayland: Don't leak wl_drm global when unbinding display

From: Ander Conselvan de Oliveira --- src/egl/wayland/wayland-drm/wayland-drm.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c b/src/egl/wayland/wayland-drm/wayland-drm.c index 06bd18c..2f5acb2 100644 --- a/src/egl/wayland

Re: [PATCH 1/2] xdg_shell: Add a new shell protocol.

On Tue, 15 Oct 2013 12:17:31 -0300 Rafael Antognolli wrote: > Hi Pekka, > > I just updated it to cover what you mentioned. The diff from the > previous one is: > > http://pastebin.ca/2466952 Hi Rafael, the diff looks good! :-) Thanks, pq ___ wayla