Use our new "surface_mapped" field to delay the showing of XWayland clients
until we have associated together the window's XID and the Wayland surface ID.
This ensures that when we show this window to the compositor, it will properly
use the Wayland surface for rendering, rather than trying to use COMPOSITE and
crash.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
The goal here is to make MetaWindow represent a toplevel, managed window,
regardless of if it's X11 or Wayland, and build an abstraction layer up.
Right now, most of the X11 code is in core/ and the wayland code in wayland/,
but in the future, I want to move a lot of the X11 code to a new toplevel, x11/.
Moving the mouse over weston-terminal, we can see several issues:
* it often updates late, or not at all
* the attachment of the pointer sprite is wrong
These are because we willy-nilly call seat_update_sprite all over the
place, and often in wrong areas. Set up a set_pointer_surface helper
method that will do the right thing for us in all cases, and call it
on transitions.
Currently, set_cursor isn't properly working. Often, the requests look
like this:
cursor_surface = wl_compositor.create_surface()
cursor_buffer = create_cursor_buffer()
cursor_surface.attach(cursor_buffer, 0, 0)
cursor_surface.commit()
wl_pointer.set_cursor(cursor_surface, 7, 14)
But since the surface doesn't "have a role" when the commit comes in,
we ignore it, and don't do anything with the pending buffer. When
set_cursor is called, however, we don't immediately update anything
since it doesn't have a buffer.
This effectively means that set_cursor has unpredictable side effects.
Weston's toy toolkit reuses the same surface for every buffer, so it
only fails the first time. In clients that use a new surface for every
cursor sprite, the cursor is effectively invisible.
To solve this, change the code to always set the buffer for a surface,
even if it doesn't have any real role.
Refactor our commit() implementation out of wl_surface_commit(),
and pass the double-buffered state around to all our implementation
methods. This allows us to drop a few lines destroying and
reinitializing list of frame callbacks. This is a big cleanup for
the next commit, though.
X11 window frames use special UI grab ops, like META_GRAB_OP_CLICKING_MAXIMIZE,
in order to work properly. As the frames in this case are X11 clients, we need
to pass through X events in this case. So, similar to how handle_xevent works,
use two variables, bypass_clutter, and bypass_wayland, and set them when we
handle specific events.
To prevent corruption, our focus listener needs to be removed even when
the surface is destroyed. So, bailing out when pointer->focus->resource
is NULL just isn't good enough.
Ever since the change to create the output window synchronously at startup,
there hasn't been any time where somebody could set a stage region the
output window was ready, so this was effectively dead code.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
I know it's confusing with the triple negative, but unredirected is how
we track it elsewhere: we have an 'unredirected' flag, and 'should_unredirect'.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
Ever since the change to create the output window synchronously at startup,
there hasn't been any time where somebody could set a stage region the
output window was ready, so this was effectively dead code.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
I know it's confusing with the triple negative, but unredirected is how
we track it elsewhere: we have an 'unredirected' flag, and 'should_unredirect'.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
Using a full InputOutput window causes us to make a full Wayland surface
for it, and go through the X server. As the goal of the guard window is
a window for us to stack minimized windows under so we can prevent them
from getting input, it makes sense to use an InputOnly window here.
Using a full InputOutput window causes us to make a full Wayland surface
for it, and go through the X server. As the goal of the guard window is
a window for us to stack minimized windows under so we can prevent them
from getting input, it makes sense to use an InputOnly window here.
We currently ignore the unobscured region when we have mapped clones in
meta_window_actor_process_damage and meta_window_actor_damage_all but
use it unconditionally when computing the paint volume.
This is wrong. We should ignore it there as well or we will end up with
empty clones if the cloned window is completly obscured
(like the tray icons in gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=721596
We currently ignore the unobscured region when we have mapped clones in
meta_window_actor_process_damage and meta_window_actor_damage_all but
use it unconditionally when computing the paint volume.
This is wrong. We should ignore it there as well or we will end up with
empty clones if the cloned window is completly obscured
(like the tray icons in gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=721596
Implement support for synchronous subsurfaces commits. This means that
the client can, by calling wl_subsurface.set_sync, cause its surface
state to be commited not until its parent commits.
This will mean there will be will potentially be one more surface state
(regions, buffer) at the same time: the active surface state, the mutable
pending surface state, and the immutable surface state that was pending
on last surface commit.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=705502
The placement set by either wl_subsurface.place_above or
wl_subsurface.place_below should be applied when the parent surface
invokes wl_surface.commit.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=705502
