Re: [RFC Weston 00/10] Sub-surfaces v2
On Wed, 6 Mar 2013 12:58:58 -0800 Daniel Stone dan...@fooishbar.org wrote: Hi, On 22 February 2013 07:07, Pekka Paalanen ppaala...@gmail.com wrote: The biggest improvement over v1 is that we have some thought-out commit behaviours. It is possible to resize a window so that all surfaces stay in sync on screen, and it is also possible to have sub-surfaces running on their own (i.e. without commit the parent surface, too). One thing I noticed is that a subsurface is defined to be mapped as soon as it has a valid buffer attached, and its parent is mapped. Presumably this means that if: - the parent window is already mapped - the child is brought into being, and attaches a buffer as part of this - a subsurface is created for the child then the subsurface will be mapped before the parent has had a chance to either repaint itself, or even call set_position. So maybe that's something we need to look at for the embed (as opposed to decoration) case, either with an explicit map request, or just adding 'and set_position has been called' to the list of map conditions. I think the parent-cached commit mode, which also happens to be the default, takes care of that: 1. main surface A created and mapped, as usual, is on screen 2. create wl_surface B 3. make B a sub-surface, with A as its parent, gets parent-cached commit mode 4. start feeding frames continously to wl_surface B, calling B.commit and all 5. send wl_subsurface.set_position for B 6. update A, and A.commit You can do steps 3-5 in any possible order, and it is guaranteed that the surface B will be mapped only at step 6. To have an effective attach (on B), you have to B.commit, but what B.commit does depends on the commit mode, so it is not effective until the parent is committed while in parent-cached mode. Also, a wl_surface without any role will not get mapped under desktop shell. Is it ok to rely on the shell like this, or should we support shells that map anonymous surfaces? OTOH, is it really too much to require, that you create the wl_subsurface before committing the first buffer to the sub-surface's wl_surface? It's also undefined what the commit_mode is for a new wl_subsurface object - and having the commit mode initially set to parent-cached might be enough to get around the map issue. Also, if the commit mode is parent-cached, changes are made which are put into the cache, and commit mode is then changed to immediate before the parent is committed, will the cached changes be committed? It's about the only semantics I can think of which really make sense for this. Yes, I flush the cache always, when a commit-to-current-state happens. I should add a mention about that. I'm very happy you saw that corner case from the spec ;-) This might all be fixed in the implementation, but it's not clear from the spec. Default commit mode is mentioned here: http://cgit.collabora.com/git/user/pq/weston.git/tree/protocol/subsurface.xml?h=subsurface-v2#n207 But maybe better move it to the general description. - Input events still very much unexplored. The demo just punts them. At the very least, we're going to need flags on enter/leave events to note when the pointer left towards a subsurface. Why exactly? The client will receive an enter for the sub-surface as the very next thing. If it is about the race of an app repainting between leave and enter, we have the same problem elsewhere, too, and should solve it globally, and I'd like krh's input on that. I can imagine we will hit the same problem in some shell use cases, too, e.g. keyboard focus entering a menu or tooltip surface. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC Weston 00/10] Sub-surfaces v2
On Thu, 07 Mar 2013 07:25:17 +0100 Kai-Uwe Behrmann k...@gmx.de wrote: Hello Pekka, Am 22.02.2013 16:07, schrieb Pekka Paalanen: - A totally new demo client presenting sub-surfaces, including Cairo-image rendered window with a pure EGL/GL widget in a sub-surface, running independently, but still without glitches on resize (sans bugs). http://people.collabora.com/~pq/subsurface-2.png The above example shows non overlapping regions. For a more throughout test, I would expect overlapping regions with and without alpha to test Z-order behaviour. There's a hge amount of test code that could be written. Z-order code is largely untested, and actually still incomplete even in the implementation (place_above/below are effective immediately instead of on parent commit like they should be). The biggest improvement over v1 is that we have some thought-out commit behaviours. It is possible to resize a window so that all surfaces stay in sync on screen, and it is also possible to have sub-surfaces running on their own (i.e. without commit the parent surface, too). What is the default behaviour of repainting in regards to Z-order? Draw all surfaces? I other words, is the possibility to have sub-surfaces running on their own only optional? Sorry, I don't understand the question. In v2 proposal, which does not support nesting, all sub-surfaces are siblings. They have no effect on each other's rendering. Also, as they are all siblings, Z-order is a completely orthogonal attribute to commit mode or rendering. Nesting support is coming, though. Could you rephrase the question? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] protocol: remove implicit attach semantics
To match the Weston commit e7144fd175d1d68b91aa0cec7ab63381b79385a9: Author: Kristian Høgsberg k...@bitplanet.net Date: Mon Mar 4 12:11:41 2013 -0500 compositor: Only send release event in response to wl_surface.attach Remove the implicit attach semantics from wl_surface.commit and .attach. Before, if you did this on a wl_surface: attach, commit, commit, you would receive wl_buffer.release for both commits. After this change, you will only receive wl_buffer.release for the first commit. To get a second release, the same buffer must be attached again. There is no need for the implicit attach on the second commit. If the compositor needs the wl_buffer for repainting, it will not release it to begin with. If the compositor does not need to keep the wl_buffer around for repainting, it will not need it for a new commit either. Signed-off-by: Pekka Paalanen ppaala...@gmail.com --- protocol/wayland.xml | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 0ce68ef..9d276f8 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -755,10 +755,10 @@ The initial surface contents are void; there is no content. wl_surface.attach assigns the given wl_buffer as the pending wl_buffer. - wl_surface.commit applies the pending wl_buffer as the new + wl_surface.commit makes the pending wl_buffer the new surface contents, and the size of the surface becomes the size of - the wl_buffer. The wl_buffer is also kept as pending, until - changed by wl_surface.attach or the wl_buffer is destroyed. + the wl_buffer. After commit, there is no pending buffer until the + next attach. Committing a pending wl_buffer allows the compositor to read the pixels in the wl_buffer. The compositor may access the pixels at any @@ -770,8 +770,6 @@ event, and is not used by the compositor. Destroying the wl_buffer after wl_buffer.release does not change the - surface contents, even if the wl_buffer is still pending for the - next commit. In such case, the next commit does not change the surface contents. However, if the client destroys the wl_buffer before receiving wl_buffer.release, the surface contents become undefined immediately. @@ -788,11 +786,10 @@ request name=damage description summary=mark part of the surface damaged This request is used to describe the regions where the pending - buffer (or if pending buffer is none, the current buffer as updated - in-place) on the next wl_surface.commit will be different from the - current buffer, and needs to be repainted. The pending buffer can be - set by wl_surface.attach. The compositor ignores the parts of the - damage that fall outside of the surface. + buffer is different from the current surface contents, and where + the surface therefore needs to be repainted. The pending buffer must + be set by wl_surface.attach before sending damage. The compositor + ignores the parts of the damage that fall outside of the surface. Damage is double-buffered state, see wl_surface.commit. @@ -894,7 +891,7 @@ On commit, a pending wl_buffer is applied first, all other state second. This means that all coordinates in double-buffered state are relative to the new wl_buffer coming into use, except for - wl_surface.attach itself. If the pending wl_buffer is none, the + wl_surface.attach itself. If there is no pending wl_buffer, the coordinates are relative to the current surface contents. All requests that need a commit to become effective are documented -- 1.7.12.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC Weston 00/10] Sub-surfaces v2
Am 07.03.2013 11:44, schrieb Pekka Paalanen: On Thu, 07 Mar 2013 07:25:17 +0100 Kai-Uwe Behrmann k...@gmx.de wrote: The biggest improvement over v1 is that we have some thought-out commit behaviours. It is possible to resize a window so that all surfaces stay in sync on screen, and it is also possible to have sub-surfaces running on their own (i.e. without commit the parent surface, too). What is the default behaviour of repainting in regards to Z-order? Draw all surfaces? I other words, is the possibility to have sub-surfaces running on their own only optional? Sorry, I don't understand the question. In v2 proposal, which does not support nesting, all sub-surfaces are siblings. They have no effect on each other's rendering. Also, as they are all siblings, Z-order is a completely orthogonal attribute to commit mode or rendering. Nesting support is coming, though. Could you rephrase the question? I will try. Statement: The flattened output of overlapping transparent regions depend on the intented order of painting the graph during compositing. Question: Does your following annotation has a side effect on the painting(Z) order of transparent content? and it is also possible to have sub-surfaces running on their own (i.e. without commit the parent surface, too) kind regards Kai-Uwe ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC Weston 00/10] Sub-surfaces v2
On Thu, 07 Mar 2013 12:32:21 +0100 Kai-Uwe Behrmann k...@gmx.de wrote: Am 07.03.2013 11:44, schrieb Pekka Paalanen: On Thu, 07 Mar 2013 07:25:17 +0100 Kai-Uwe Behrmann k...@gmx.de wrote: The biggest improvement over v1 is that we have some thought-out commit behaviours. It is possible to resize a window so that all surfaces stay in sync on screen, and it is also possible to have sub-surfaces running on their own (i.e. without commit the parent surface, too). What is the default behaviour of repainting in regards to Z-order? Draw all surfaces? I other words, is the possibility to have sub-surfaces running on their own only optional? Sorry, I don't understand the question. In v2 proposal, which does not support nesting, all sub-surfaces are siblings. They have no effect on each other's rendering. Also, as they are all siblings, Z-order is a completely orthogonal attribute to commit mode or rendering. Nesting support is coming, though. Could you rephrase the question? I will try. Statement: The flattened output of overlapping transparent regions depend on the intented order of painting the graph during compositing. Question: Does your following annotation has a side effect on the painting(Z) order of transparent content? and it is also possible to have sub-surfaces running on their own (i.e. without commit the parent surface, too) Hmm, no. Whether you commit or not on a parent surface, has no effect on the Z-order of sub-surfaces on its own. How could it have? The parent surface is still there in the same state it was before, if you don't commit it. Sub-surfaces running on their own simply means, that a wl_surface.commit on such a sub-surface will be effective immediately, instead of waiting for the parent surface to be committed. This allows a widget in a sub-surface to animate on its own, without requiring other surfaces to be committed every time it updates. Committing new state to surfaces, and compositor's repainting are quite orthogonal. The compositor is free to repaint as often or seldom as it wants. Committing does not affect the Z-order or repainting order, unless you explicitly change the Z-order with a place_above/below request. I guess I still cannot imagine what side-effects there could possibly be. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC Weston 00/10] Sub-surfaces v2
Am 07.03.2013 12:56, schrieb Pekka Paalanen: On Thu, 07 Mar 2013 12:32:21 +0100 Kai-Uwe Behrmann k...@gmx.de wrote: Statement: The flattened output of overlapping transparent regions depend on the intented order of painting the graph during compositing. Question: Does your following annotation has a side effect on the painting(Z) order of transparent content? and it is also possible to have sub-surfaces running on their own (i.e. without commit the parent surface, too) Committing new state to surfaces, and compositor's repainting are quite orthogonal. The compositor is free to repaint as often or seldom as it wants. Committing does not affect the Z-order or repainting order, unless you explicitly change the Z-order with a place_above/below request. Ok, I now understand the difference between paint and commit. That makes sense and answers my question. thanks and kind regards Kai-Uwe ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] Fix memory leaks
Fix a couple leaks caught by valgrind. --- src/gl-renderer.c |2 ++ src/shell.c |1 + 2 files changed, 3 insertions(+) diff --git a/src/gl-renderer.c b/src/gl-renderer.c index a5dc2f3..3dfcd15 100644 --- a/src/gl-renderer.c +++ b/src/gl-renderer.c @@ -1663,6 +1663,8 @@ gl_renderer_destroy(struct weston_compositor *ec) eglTerminate(gr-egl_display); eglReleaseThread(); + + free(gr); } static int diff --git a/src/shell.c b/src/shell.c index 3da5321..5a09bb6 100644 --- a/src/shell.c +++ b/src/shell.c @@ -2002,6 +2002,7 @@ destroy_shell_surface(struct shell_surface *shsurf) wl_list_remove(shsurf-surface_destroy_listener.link); shsurf-surface-configure = NULL; ping_timer_destroy(shsurf); + free(shsurf-title); wl_list_remove(shsurf-link); free(shsurf); -- 1.7.10.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Non-Intel DDXes need love
These: https://github.com/RAOF/xf86-video-ati -b xwayland (Radeon / AMD) https://github.com/RAOF/xf86-video-nouveau -b xwayland (Nvidia) Instructions here should be up to date: http://wayland.freedesktop.org/xserver.html Except the nvidia / nouveau stuff needs this: http://lists.freedesktop.org/archives/wayland-devel/2013-February/007370.html And probably something like this: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?h=xwaylandid=1f2427f562f93efdd6447217f41ec378279d189c RAOF says after that, the nvidia / nouveau DDX should be ready to commit upstream. He submitted it before, when these two patches weren't required, but it didn't get committed, probably just due to insufficient nagging. RAOF also says the radeon / amd / ati ddx needs some work: ATI still needs cleanup - from memory, specifically around the multi-monitor case. But I don't think this is a reason not to submit it upstream? I haven't found any xwayland problems specific to radeon while using it (without using multi-monitor). Also, it would be nice if there was a DDX that was hardware independent like wlshm, but with hardware acceleration. Glamor has come up a few times when talking about this: 09:31 ickle such as st/xa or glamor 09:33 pq also, http://www.freedesktop.org/wiki/Software/Glamor 21:46 RAOF Darxus: Using gbm + glamour? 09:28 pq GriffenJBS, no, unless you get your X to work with GLAMOR. 15:41 krh and add optionaly glamor acceleration to it 15:42 krh glamor is an egl/gles2 acceleration project 15:54 krh vignatti: xwayland support in xf8-video-intel is still useful, but it would be good to have a generic ddx that supports wayland, either with shm and sw rendering or egl+glamor The DDXes have a lot of similarity, and the Intel one is kept up to date, so you can probably use that as a reference for a lot. -- As humans, we are taught to forget that we are animals. - forward to Johnny The Homicidal Maniac http://www.ChaosReigns.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC Weston 00/10] Sub-surfaces v2
On 03/07/2013 02:32 AM, Pekka Paalanen wrote: At the very least, we're going to need flags on enter/leave events to note when the pointer left towards a subsurface. Why exactly? The client will receive an enter for the sub-surface as the very next thing. If it is about the race of an app repainting between leave and enter, we have the same problem elsewhere, too, and should solve it globally, and I'd like krh's input on that. I can imagine we will hit the same problem in some shell use cases, too, e.g. keyboard focus entering a menu or tooltip surface. I think this is another example that can be fixed by getting rid of the goal of making the server send exactly matching enter/leave events. If the old and new surface belong to the same client, the server sends only the enter event to the new surface. The client can figure out exactly what happened and at no time is it unsure whether the cursor is pointing at one of it's surfaces. Full proposal: All pointer motion produces one of three events, somewhat misleadingly labelled MOVE, ENTER, LEAVE. All of them have the pointer x/y position in the coordinate space of the target surface. MOVE has an accurate timestamp as it always matches an actual device event. The others may have inaccurate information as they are spontaneously generated by other actions by clients. When a pointer moves, a MOVE event is sent to exactly one surface. Normally this is the top-most one with a non-transparent pixel under the cursor, but there are grabs and other state that can send it to a different surface. The compositor also knows of all kinds of other reasons a pointer may suddenly be in a surface even without movement. This includes reordering and creation/destruction of surfaces, creation of pointers, and changes in grab. In this case it sends an ENTER event to the same surface that would have gotten the MOVE event if the movement ended at the current pointer position. Compositors can spuriously send ENTER at any time so that they do not have to track huge amounts of state, and clients must be prepared to handle any number of ENTER events. The compositor keeps track of the surface it last sent an ENTER or MOVE to, and when sending an ENTER or MOVE to a different surface, and they belong to different clients, it sends a LEAVE event to the previous surface. A LEAVE may also be sent if a pointer is destroyed. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Non-Intel DDXes need love
On Thu, Mar 7, 2013 at 6:51 PM, dar...@chaosreigns.com wrote: I haven't found any xwayland problems specific to radeon while using it (without using multi-monitor). I have an outstanding bug with XWayland and radeon. RAOF said he'd take a look at it, but it hasn't gotten any further. A simple way to trigger it is to open chromium-browser and try to re-order a tab by dragging it. This causes a segfault in some part of radeon that I can't remember what was. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] client: Check reference count only for destroyed proxies
The llvm static analyzer tool reported Use of memory after it is freed
in dispatch_event() because the proxy is used after being freed if the
reference count reaches zero without the destroyed flag being set. This
would never happen in practice because the owner of the proxy object
always holds a reference until calling wl_proxy_destroy() which would
also set the destroyed flag.
Since this is the case, it is safe to do the reference count check only
if the destroyed flag is set, as it can never reach zero if not.
This commit doesn't change the behavior of the function, but makes the
static analyzer more happy.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=61385
Signed-off-by: Jonas Ådahl jad...@gmail.com
---
src/wayland-client.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index 74e4657..3ead2ac 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -822,10 +822,10 @@ dispatch_event(struct wl_display *display, struct
wl_event_queue *queue)
proxy_destroyed = !!(proxy-flags WL_PROXY_FLAG_DESTROYED);
proxy-refcount--;
- if (!proxy-refcount)
- free(proxy);
-
if (proxy_destroyed) {
+ if (!proxy-refcount)
+ free(proxy);
+
wl_closure_destroy(closure);
return;
}
--
1.7.10.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
X.Org Google Summer of Code
It's that time of year again. The X.Org foundation is looking for volunteers to organize the Google Summer of Code application for the X.Org foundation. Historically the X.Org GSoC application has encompassed not just X, but the entire open source graphics ecosystem (mesa, X, kernel, wayland, etc.). Responsibilities would include coordinating the application with Google, updating the ideas pages, and helping to secure mentors. Having been involved with it for several years, I can say it is a very rewarding project for all involved. If you are interested, please email the board at bo...@foundation.x.org. Thanks! X.Org Foundation Board ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Introduce panel window list and surface minimize protocol
This series implements a window list for the panel. It introduces protocol for minimize/maximize control of shell_surfaces. It also provides a basic minimize implementation. Admittedly I am a little confused about the interface version system. I am wondering if we should have something such as a changlog file kept in the protocol folder. Aside from this, the window list seems to work pretty well with all the new functionality that it offers. Minimized buttons are hooked up by this series as well, which means we can start fleshing out the decorations in other clients and toolkits. The list operation is dynamic, supporting multiple outputs. Changed in v3: - Rebased to latest master - Addressed everything listed here: http://lists.freedesktop.org/archives/wayland-devel/2012-November/006485.html - Additional bug fixes Here is a breif video clip demoing the latest code: http://www.youtube.com/watch?v=nv5isdcxBcY ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland v3] protocol: Add minimize/maximize protocol
In order for clients to notify the compositor that they wish to be minimized, a minimize request is needed. This can be used to minimize the surface when a user clicks a minimize button for example. The compositor needs a way to tell clients to maximize and unmaximize their surfaces. The desktop shell client can ask the compositor to send a surface an (un)maximize event, in response to a panel button for example. The compositor can minimize and unminimize surfaces but clients can only request that its surface is minimized. The client doesn't need to be involved in a minimize action, unlike (un)maximize, it only needs a way to track its minimize state and request to be minimized. This patch adds minimize and unminimize protocol events for this purpose. Further, the term minimize is relatively subjective and defined by the implementation. Clients should not expect that minimized means the surface will be invisable to the user. There are several use cases where displaying minimized surfaces will be useful. Clients might want to change input handling or pause when minimized but nothing should change with regards to submitting surface buffer updates. --- protocol/wayland.xml | 38 +- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 0ce68ef..8fb5841 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -527,7 +527,7 @@ /request /interface - interface name=wl_shell_surface version=1 + interface name=wl_shell_surface version=2 description summary=desktop style meta data interface An interface implemented by a wl_surface. On server side the @@ -729,6 +729,42 @@ to the client owning the popup surface. /description /event + +!-- Version 2 additions -- + +request name=set_minimized + description summary=request minimize + A request from the client to notify the compositor that it wants to be + minimized. + /description +/request + +event name=maximize + description summary=suggest maximize + The maximize event is to signal to the client that it should become + maximized. + /description +/event + +event name=unmaximize + description summary=suggest unmaximize + The unmaximize event is to signal to the client that it should become + unmaximized. + /description +/event + +event name=minimize + description summary=minimize notification + The minimize event is to notify the client that it has been minimized. + /description +/event + +event name=unminimize + description summary=unminimize notification + The unminimize event is to notify the client that it has been + unminimized. + /description +/event /interface interface name=wl_surface version=2 -- 1.7.10.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 1/9] shell: Install protocol for surface_data objects
This patch introduces a new surface_data_manager interface that allows the compositor to send surface data to the shell client, using the accompanying surface_data object interface. This allows the shell client to receive information about surfaces to build a window list, for example. --- protocol/desktop-shell.xml | 42 ++ 1 file changed, 42 insertions(+) diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml index d48c3dd..2fed660 100644 --- a/protocol/desktop-shell.xml +++ b/protocol/desktop-shell.xml @@ -82,6 +82,48 @@ /enum /interface + interface name=surface_data version=1 +description summary=the surface data offer object + The shell can use this interface to receive surface information or make + requests for this surface. +/description +request name=destroy type=destructor + description summary=destroy surface request + The shell must send this request in response to a gone event so the + compositor can destroy the object properly. + /description +/request +event name=output_mask + description summary=send the surface object output_mask to the shell/ + arg name=output_mask type=uint/ +/event +event name=title + description summary=send the surface object title to the shell/ + arg name=title type=string/ +/event +event name=gone + description summary=destroy surface notification + The compositor should send this event to notify the shell that a + surface has been destroyed. The client must respond with a destroy + request. + /description +/event + /interface + + interface name=surface_data_manager version=1 +description summary=send surface object to shell + The compositor can offer surface data to a shell. The client can use + this interface as a way to receive special surface_data objects. +/description +event name=surface_object + description summary=surface object + Surface object sent to a shell. This object is intended to allow the + shell to initiate a surface_data object interface. + /description + arg name=id type=new_id interface=surface_data/ +/event + /interface + interface name=screensaver version=1 description summary=interface for implementing screensavers Only one client can bind this interface at a time. -- 1.7.10.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 2/9] shell: Implement panel window list
This patch uses the special surface_data interface to send information about
the surface to the shell. The shell then uses this information to render a
window list in the panel.
---
clients/desktop-shell.c | 479 +--
data/Makefile.am|1 +
data/list_item_icon.png | Bin 0 - 176 bytes
src/compositor.c|3 +
src/compositor.h|1 +
src/shell.c | 201
6 files changed, 671 insertions(+), 14 deletions(-)
create mode 100644 data/list_item_icon.png
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 41e7daa..2b5f7c8 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -44,6 +44,8 @@
#include desktop-shell-client-protocol.h
+#define MIN(x, y) (((x) (y)) ? (x) : (y))
+
extern char **environ; /* defined by libc */
struct desktop {
@@ -51,31 +53,55 @@ struct desktop {
struct desktop_shell *shell;
struct unlock_dialog *unlock_dialog;
struct task unlock_task;
+ struct wl_list surfaces;
struct wl_list outputs;
+ uint32_t output_count;
struct window *grab_window;
struct widget *grab_widget;
enum cursor_type grab_cursor;
+
+ struct surface_data_manager *surface_data_manager;
};
struct surface {
+ struct surface_data *surface_data;
+ struct desktop *desktop;
+ uint32_t output_mask;
+ char *title;
+
+ /* One window list item per panel of the surface's output_mask */
+ struct wl_list item_list;
+
+ struct wl_list link;
+};
+
+struct resize {
void (*configure)(void *data,
struct desktop_shell *desktop_shell,
uint32_t edges, struct window *window,
int32_t width, int32_t height);
};
+struct rgba {
+ float r, g, b, a;
+};
+
struct panel {
- struct surface base;
+ struct resize base;
struct window *window;
struct widget *widget;
struct wl_list launcher_list;
+ struct wl_list window_list;
+ struct rectangle window_list_rect;
+ uint32_t surface_count;
+ struct rgba focused_item;
struct panel_clock *clock;
};
struct background {
- struct surface base;
+ struct resize base;
struct window *window;
struct widget *widget;
};
@@ -83,11 +109,22 @@ struct background {
struct output {
struct wl_output *output;
struct wl_list link;
+ uint32_t id;
struct panel *panel;
struct background *background;
};
+struct list_item {
+ struct surface *surface;
+ struct widget *widget;
+ struct panel *panel;
+ cairo_surface_t *icon;
+ int focused, highlight;
+ struct wl_list link;
+ struct wl_list surface_link;
+};
+
struct panel_launcher {
struct widget *widget;
struct panel *panel;
@@ -249,6 +286,15 @@ set_hex_color(cairo_t *cr, uint32_t color)
}
static void
+get_hex_color_rgba(uint32_t color, float *r, float *g, float *b, float *a)
+{
+ *r = ((color 16) 0xff) / 255.0;
+ *g = ((color 8) 0xff) / 255.0;
+ *b = ((color 0) 0xff) / 255.0;
+ *a = ((color 24) 0xff) / 255.0;
+}
+
+static void
panel_redraw_handler(struct widget *widget, void *data)
{
cairo_surface_t *surface;
@@ -421,15 +467,46 @@ panel_button_handler(struct widget *widget,
}
static void
+panel_window_list_schedule_redraw(struct panel *panel)
+{
+ struct list_item *item;
+ int item_width, padding, x, w;
+
+ /* If there are no window list items, redraw the panel to clear it */
+ if (wl_list_empty(panel-window_list)) {
+ widget_schedule_redraw(panel-widget);
+ return;
+ }
+
+ item_width = (panel-window_list_rect.width / panel-surface_count);
+ padding = 2;
+
+ x = panel-window_list_rect.x + padding;
+ w = MIN(item_width - padding, 200);
+
+ wl_list_for_each(item, panel-window_list, link) {
+ widget_set_allocation(item-widget, x, 4, w, 24);
+
+ x += w + padding;
+ widget_schedule_redraw(item-widget);
+ }
+}
+
+static void
panel_resize_handler(struct widget *widget,
int32_t width, int32_t height, void *data)
{
struct panel_launcher *launcher;
+ struct rectangle launcher_rect;
+ struct rectangle clock_rect;
struct panel *panel = data;
int x, y, w, h;
-
+
x = 10;
y = 16;
+
+ launcher_rect.x = x;
+
wl_list_for_each(launcher, panel-launcher_list, link) {
w = cairo_image_surface_get_width(launcher-icon);
h = cairo_image_surface_get_height(launcher-icon);
@@ -437,12 +514,25 @@ panel_resize_handler(struct widget *widget,
x, y - h / 2, w + 1, h + 1);
x += w + 10;
}
[PATCH weston 3/9] shell: Install protocol for minimize, focus and close
--- protocol/desktop-shell.xml | 20 1 file changed, 20 insertions(+) diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml index 2fed660..51219d2 100644 --- a/protocol/desktop-shell.xml +++ b/protocol/desktop-shell.xml @@ -87,6 +87,18 @@ The shell can use this interface to receive surface information or make requests for this surface. /description +request name=minimize + description summary=ask the compositor to minimize the surface/ +/request +request name=unminimize + description summary=ask the compositor to unminimize the surface/ +/request +request name=focus + description summary=ask the compositor to focus the surface/ +/request +request name=close + description summary=ask the compositor to close the surface/ +/request request name=destroy type=destructor description summary=destroy surface request The shell must send this request in response to a gone event so the @@ -101,6 +113,14 @@ description summary=send the surface object title to the shell/ arg name=title type=string/ /event +event name=minimized + description summary=send the surface object minimize state to the shell/ + arg name=minimized type=int/ +/event +event name=focused + description summary=send the surface object focus state to the shell/ + arg name=focused type=int/ +/event event name=gone description summary=destroy surface notification The compositor should send this event to notify the shell that a -- 1.7.10.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 5/9] shell: Implement simple dnd for window list item reordering
This allows the user to rearrange the list items by drag-and-drop. There is no
drag icon, only preliminary functionality. Eventually, this could be expanded
to use the wayland dnd protocol.
---
clients/desktop-shell.c | 85 +++
1 file changed, 85 insertions(+)
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 582a19f..1fa7387 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -122,8 +122,10 @@ struct list_item {
struct panel *panel;
cairo_surface_t *icon;
int focused, highlight;
+ int x, y;
struct wl_list link;
struct wl_list surface_link;
+ struct wl_list reorder_link;
};
struct panel_launcher {
@@ -1145,6 +1147,9 @@ panel_list_item_motion_handler(struct widget *widget,
struct input *input,
{
struct list_item *item = data;
+ item-x = x;
+ item-y = y;
+
widget_set_tooltip(widget, basename((char *)item-surface-title), x,
y);
return CURSOR_LEFT_PTR;
@@ -1156,6 +1161,8 @@ panel_list_item_enter_handler(struct widget *widget,
struct input *input,
{
struct list_item *item = data;
+ item-x = x;
+ item-y = y;
item-highlight = 1;
item-focused = 1;
widget_schedule_redraw(widget);
@@ -1243,6 +1250,79 @@ list_item_show_menu(struct list_item *item, struct input
*input, uint32_t time)
list_item_menu_func, entries, MENU_ENTRIES);
}
+static int
+rect_contains_point(struct rectangle rect, int x, int y)
+{
+ int x1, y1, x2, y2;
+
+ x1 = rect.x;
+ y1 = rect.y;
+ x2 = rect.x + rect.width;
+ y2 = rect.y + rect.height;
+
+ if (x x1 x x2 y y1 y y2)
+ return 1;
+
+ return 0;
+}
+
+static int
+item_contains_point(struct list_item *item, int x, int y)
+{
+ struct rectangle item_rect;
+
+ widget_get_allocation(item-widget, item_rect);
+
+ return rect_contains_point(item_rect, x, y);
+}
+
+static int
+list_contains_point(struct list_item *item, int x, int y)
+{
+ struct rectangle list_rect;
+
+ list_rect = item-panel-window_list_rect;
+
+ return rect_contains_point(list_rect, x, y);
+}
+
+static void
+panel_item_list_reorder(struct panel *panel,
+ struct list_item *current, struct list_item *item)
+{
+ struct rectangle current_rect, item_rect;
+
+ if (current == item)
+ return;
+
+ widget_get_allocation(current-widget, current_rect);
+ widget_get_allocation(item-widget, item_rect);
+
+ wl_list_remove(current-link);
+
+ if (item_rect.x current_rect.x)
+ wl_list_insert(item-link.prev, current-link);
+ else
+ wl_list_insert(item-link, current-link);
+
+ panel_window_list_schedule_redraw(item-panel);
+}
+
+static void
+list_item_move(struct list_item *current, int x, int y)
+{
+ struct list_item *item;
+
+ wl_list_for_each(item, current-panel-window_list, link) {
+ if (item == current)
+ continue;
+ if (item_contains_point(item, x, y)) {
+ panel_item_list_reorder(item-panel, current, item);
+ return;
+ }
+ }
+}
+
static void
panel_list_item_button_handler(struct widget *widget,
struct input *input, uint32_t time,
@@ -1267,6 +1347,11 @@ panel_list_item_button_handler(struct widget *widget,
return;
surface = item-surface;
+ if (!item_contains_point(item, item-x, item-y)) {
+ if (list_contains_point(item, item-x, item-y))
+ list_item_move(item, item-x, item-y);
+ return;
+ }
if (!surface-focused !surface-minimized) {
surface_data_focus(surface-surface_data);
surface-focused = 1;
--
1.7.10.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 6/9] shell: Install listeners to reflect shell surface protocol changes
---
clients/simple-egl.c | 26 +-
clients/simple-shm.c | 26 +-
clients/simple-touch.c | 26 +-
clients/window.c | 26 +-
src/shell.c|9 -
5 files changed, 108 insertions(+), 5 deletions(-)
diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index 26ebe5c..d90ecf5 100644
--- a/clients/simple-egl.c
+++ b/clients/simple-egl.c
@@ -246,10 +246,34 @@ handle_popup_done(void *data, struct wl_shell_surface
*shell_surface)
{
}
+static void
+handle_maximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unmaximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_minimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unminimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
static const struct wl_shell_surface_listener shell_surface_listener = {
handle_ping,
handle_configure,
- handle_popup_done
+ handle_popup_done,
+ handle_maximize,
+ handle_unmaximize,
+ handle_minimize,
+ handle_unminimize
};
static void
diff --git a/clients/simple-shm.c b/clients/simple-shm.c
index f187b10..ded27c5 100644
--- a/clients/simple-shm.c
+++ b/clients/simple-shm.c
@@ -126,10 +126,34 @@ handle_popup_done(void *data, struct wl_shell_surface
*shell_surface)
{
}
+static void
+handle_maximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unmaximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_minimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unminimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
static const struct wl_shell_surface_listener shell_surface_listener = {
handle_ping,
handle_configure,
- handle_popup_done
+ handle_popup_done,
+ handle_maximize,
+ handle_unmaximize,
+ handle_minimize,
+ handle_unminimize
};
static struct window *
diff --git a/clients/simple-touch.c b/clients/simple-touch.c
index b8473f1..8ebb29b 100644
--- a/clients/simple-touch.c
+++ b/clients/simple-touch.c
@@ -233,10 +233,34 @@ handle_popup_done(void *data, struct wl_shell_surface
*shell_surface)
{
}
+static void
+handle_maximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unmaximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_minimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unminimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
static const struct wl_shell_surface_listener shell_surface_listener = {
handle_ping,
handle_configure,
- handle_popup_done
+ handle_popup_done,
+ handle_maximize,
+ handle_unmaximize,
+ handle_minimize,
+ handle_unminimize
};
static void
diff --git a/clients/window.c b/clients/window.c
index 249ba6f..d13a1ac 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3313,10 +3313,34 @@ handle_popup_done(void *data, struct wl_shell_surface
*shell_surface)
menu_destroy(menu);
}
+static void
+handle_maximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unmaximize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_minimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
+static void
+handle_unminimize(void *data, struct wl_shell_surface *shell_surface)
+{
+}
+
static const struct wl_shell_surface_listener shell_surface_listener = {
handle_ping,
handle_configure,
- handle_popup_done
+ handle_popup_done,
+ handle_maximize,
+ handle_unmaximize,
+ handle_minimize,
+ handle_unminimize
};
void
diff --git a/src/shell.c b/src/shell.c
index 9e19ddb..f3877d2 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1944,6 +1944,12 @@ shell_surface_set_maximized(struct wl_client *client,
}
static void
+shell_surface_set_minimized(struct wl_client *client,
+ struct wl_resource *resource)
+{
+}
+
+static void
black_surface_configure(struct weston_surface *es, int32_t sx, int32_t sy,
int32_t width, int32_t height);
static struct weston_surface *
@@ -2286,7 +2292,8 @@ static const struct wl_shell_surface_interface
shell_surface_implementation = {
shell_surface_set_popup,
shell_surface_set_maximized,
shell_surface_set_title,
- shell_surface_set_class
+ shell_surface_set_class,
+ shell_surface_set_minimized
};
static void
--
1.7.10.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 7/9] toytoolkit: Enable titlebar minimize button functionality
---
clients/window.c | 25 -
clients/window.h |3 +++
src/shell.c |9 -
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index d13a1ac..7093a38 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -220,6 +220,7 @@ struct window {
int resize_needed;
int type;
int focus_count;
+ int minimized;
int resizing;
int fullscreen_method;
@@ -1925,7 +1926,7 @@ frame_button_button_handler(struct widget *widget,
display_exit(window-display);
break;
case FRAME_BUTTON_MINIMIZE:
- fprintf(stderr,Minimize stub\n);
+ window_set_minimized(window, !window-minimized);
break;
case FRAME_BUTTON_MAXIMIZE:
window_set_maximized(window, window-type != TYPE_MAXIMIZED);
@@ -3326,11 +3327,17 @@ handle_unmaximize(void *data, struct wl_shell_surface
*shell_surface)
static void
handle_minimize(void *data, struct wl_shell_surface *shell_surface)
{
+ struct window *window = data;
+
+ window-minimized = 1;
}
static void
handle_unminimize(void *data, struct wl_shell_surface *shell_surface)
{
+ struct window *window = data;
+
+ window-minimized = 0;
}
static const struct wl_shell_surface_listener shell_surface_listener = {
@@ -3472,6 +3479,22 @@ window_set_maximized(struct window *window, int
maximized)
}
void
+window_set_minimized(struct window *window, int minimized)
+{
+ if (!window-display-shell)
+ return;
+
+ if (window-minimized == minimized)
+ return;
+
+ if (minimized) {
+ wl_shell_surface_set_minimized(window-shell_surface);
+ window-minimized = 1;
+ } else
+ window-minimized = 0;
+}
+
+void
window_set_user_data(struct window *window, void *data)
{
window-user_data = data;
diff --git a/clients/window.h b/clients/window.h
index c2946d8..331ce23 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -313,6 +313,9 @@ void
window_set_maximized(struct window *window, int maximized);
void
+window_set_minimized(struct window *window, int maximized);
+
+void
window_set_user_data(struct window *window, void *data);
void *
diff --git a/src/shell.c b/src/shell.c
index f3877d2..fd1411b 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1470,6 +1470,9 @@ shell_surface_minimize(struct shell_surface *shsurf)
shsurf-saved_type = shsurf-type;
shsurf-minimized = 1;
+ send_surface_data_focused_state(surface);
+ wl_shell_surface_send_minimize(shsurf-resource);
+
/* Focus next surface in stack */
wl_list_for_each(seat, compositor-seat_list, link)
if (seat-seat.keyboard
@@ -1486,7 +1489,6 @@ shell_surface_minimize(struct shell_surface *shsurf)
wl_keyboard_set_focus(seat-seat.keyboard,
NULL);
}
- send_surface_data_focused_state(surface);
weston_compositor_damage_all(compositor);
}
@@ -1506,6 +1508,7 @@ surface_unminimize(struct shell_surface *shsurf, struct
workspace *ws)
shell_surface_focus(shsurf);
send_surface_data_focused_state(surface);
shsurf-minimized = false;
+ wl_shell_surface_send_unminimize(shsurf-resource);
weston_compositor_damage_all(compositor);
}
@@ -1947,6 +1950,10 @@ static void
shell_surface_set_minimized(struct wl_client *client,
struct wl_resource *resource)
{
+ struct shell_surface *shsurf = resource-data;
+
+ shell_surface_minimize(shsurf);
+ send_surface_data_minimized_state(shsurf-surface);
}
static void
--
1.7.10.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 8/9] shell: Install protocol for maximize menu button
--- protocol/desktop-shell.xml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml index 51219d2..20e2eb9 100644 --- a/protocol/desktop-shell.xml +++ b/protocol/desktop-shell.xml @@ -87,6 +87,12 @@ The shell can use this interface to receive surface information or make requests for this surface. /description +request name=maximize + description summary=ask the compositor to maximize the surface/ +/request +request name=unmaximize + description summary=ask the compositor to unmaximize the surface/ +/request request name=minimize description summary=ask the compositor to minimize the surface/ /request @@ -113,6 +119,10 @@ description summary=send the surface object title to the shell/ arg name=title type=string/ /event +event name=maximized + description summary=send the surface object maximize state to the shell/ + arg name=maximized type=int/ +/event event name=minimized description summary=send the surface object minimize state to the shell/ arg name=minimized type=int/ -- 1.7.10.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 9/9] shell: Implement maximize menu button functionality
Add maximize button for list item drop down menu.
---
clients/desktop-shell.c | 44 +++-
clients/window.c|6 ++
src/shell.c | 23 +++
3 files changed, 68 insertions(+), 5 deletions(-)
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 1fa7387..4b2f805 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -70,7 +70,7 @@ struct surface {
struct desktop *desktop;
uint32_t output_mask;
char *title;
- int minimized, focused;
+ int maximized, minimized, focused;
/* One window list item per panel of the surface's output_mask */
struct wl_list item_list;
@@ -1159,7 +1159,7 @@ static int
panel_list_item_enter_handler(struct widget *widget, struct input *input,
float x, float y, void *data)
{
- struct list_item *item = data;
+ struct list_item *item = data, *t_item;
item-x = x;
item-y = y;
@@ -1167,6 +1167,13 @@ panel_list_item_enter_handler(struct widget *widget,
struct input *input,
item-focused = 1;
widget_schedule_redraw(widget);
+ wl_list_for_each(t_item, item-panel-window_list, link) {
+ if(item == t_item)
+ continue;
+ t_item-highlight = 0;
+ t_item-focused = 0;
+ }
+
return CURSOR_LEFT_PTR;
}
@@ -1201,7 +1208,17 @@ list_item_menu_handle_button(struct list_item *item, int
index)
surface-minimized = 1;
}
break;
- case 1: /* Close */
+ case 1: /* (Un)Maximize */
+ if (surface-maximized) {
+ surface_data_unmaximize(surface-surface_data);
+ surface-maximized = 0;
+ }
+ else {
+ surface_data_maximize(surface-surface_data);
+ surface-maximized = 1;
+ }
+ break;
+ case 2: /* Close */
surface_data_close(surface-surface_data);
break;
default:
@@ -1231,7 +1248,7 @@ list_item_menu_func(struct window *window, int index,
void *data)
}
}
-#define MENU_ENTRIES 2
+#define MENU_ENTRIES 3
static void
list_item_show_menu(struct list_item *item, struct input *input, uint32_t time)
@@ -1241,7 +1258,8 @@ list_item_show_menu(struct list_item *item, struct input
*input, uint32_t time)
static const char *entries[MENU_ENTRIES];
entries[0] = item-surface-minimized ? Unminimize : Minimize;
- entries[1] = Close;
+ entries[1] = item-surface-maximized ? Unmaximize : Maximize;
+ entries[2] = Close;
panel = item-panel;
input_get_position(input, x, y);
@@ -1503,6 +1521,21 @@ surface_data_set_title(void *data,
}
static void
+surface_data_set_maximized_state(void *data,
+ struct surface_data *surface_data,
+ int maximized)
+{
+ struct desktop *desktop;
+ struct surface *surface = data;
+
+ desktop = surface-desktop;
+
+ surface-maximized = maximized;
+
+ desktop_update_list_items(desktop, surface);
+}
+
+static void
surface_data_set_minimized_state(void *data,
struct surface_data *surface_data,
int minimized)
@@ -1568,6 +1601,7 @@ surface_data_destroy_handler(void *data, struct
surface_data *surface_data)
static const struct surface_data_listener surface_data_listener = {
surface_data_set_output_mask,
surface_data_set_title,
+ surface_data_set_maximized_state,
surface_data_set_minimized_state,
surface_data_set_focused_state,
surface_data_destroy_handler
diff --git a/clients/window.c b/clients/window.c
index 7093a38..d5a1898 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3317,11 +3317,17 @@ handle_popup_done(void *data, struct wl_shell_surface
*shell_surface)
static void
handle_maximize(void *data, struct wl_shell_surface *shell_surface)
{
+ struct window *window = data;
+
+ window_set_maximized(window, 1);
}
static void
handle_unmaximize(void *data, struct wl_shell_surface *shell_surface)
{
+ struct window *window = data;
+
+ window_set_maximized(window, 0);
}
static void
diff --git a/src/shell.c b/src/shell.c
index fd1411b..1e2eb52 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1508,6 +1508,7 @@ surface_unminimize(struct shell_surface *shsurf, struct
workspace *ws)
shell_surface_focus(shsurf);
send_surface_data_focused_state(surface);
shsurf-minimized = false;
+ shsurf-type = shsurf-saved_type;
wl_shell_surface_send_unminimize(shsurf-resource);
weston_compositor_damage_all(compositor);
}
@@ -1526,6 +1527,24 @@ shell_surface_unminimize(struct shell_surface
[PATCH weston] compositor-x11: Consider output position when computing relative motion
This fixes pointer movement for multiple x11 outputs. This was broken when switching to relative events. --- I do not currently have a multi-output setup to test drm but it's possible that evdev needs a similar fix. src/compositor-x11.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/compositor-x11.c b/src/compositor-x11.c index 8e052dd..db51409 100644 --- a/src/compositor-x11.c +++ b/src/compositor-x11.c @@ -1012,8 +1012,8 @@ x11_compositor_deliver_motion_event(struct x11_compositor *c, output = x11_compositor_find_output(c, motion_notify-event); x = wl_fixed_from_int(motion_notify-event_x - c-prev_x); y = wl_fixed_from_int(motion_notify-event_y - c-prev_y); - c-prev_x = motion_notify-event_x; - c-prev_y = motion_notify-event_y; + c-prev_x = motion_notify-event_x + output-base.x; + c-prev_y = motion_notify-event_y + output-base.y; x11_output_transform_coordinate(output, x, y); notify_motion(c-core_seat, weston_compositor_get_time(), x, y); @@ -1033,8 +1033,8 @@ x11_compositor_deliver_enter_event(struct x11_compositor *c, if (!c-has_xkb) update_xkb_state_from_core(c, enter_notify-state); output = x11_compositor_find_output(c, enter_notify-event); - c-prev_x = enter_notify-event_x; - c-prev_y = enter_notify-event_y; + c-prev_x = enter_notify-event_x + output-base.x; + c-prev_y = enter_notify-event_y + output-base.y; x = wl_fixed_from_int(enter_notify-event_x); y = wl_fixed_from_int(enter_notify-event_y); x11_output_transform_coordinate(output, x, y); -- 1.7.10.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
