We don't gain anything from taking a wl_shell_surface in
desktop_surface.set_background, except making wl_shell_surface
gratuitously dependent on wl_shell. In shell.c we can also handle
backgrounds in their own background_configure function which simplifies
the mapping and placement logic.
When an unused plane is disabled, the destroy listener for a previously
used buffer needs to be removed. This fixes a crash when an overlay
would be reenabled using the same buffer as before, causing the destroy
listener to be inserted twice.
Besides the fact of the frame not being done, assigning planes before
the vblank handler is called will make the state inconsistent, leading
to a crash.
Check if the output passed to drm_output_prepare_overlay_surface() does
actually contain the surface and fail if it doesn't. Also fail if a
surface spans multiple outputs since clearing the damage will cause the
portion that is not in an overlay to not be updated at all.
This way, if initialisation fails (say, udev or Mesa are broken, or we
couldn't find any devices), we'll at least take you back to where you
were, rather than leave you at a totally broken VT you can't escape
from.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
weston_compositor_init is always called late because most
implementations can't initialise GL until fairly late in the game.
Split it into a base version with the same name, followed by
weston_compositor_init_gl which can be called later on.
This simplifies compositor-wayland, which no longer needs a separate
global handler just for wl_seat.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Use the wl_keyboard::modifiers events our parent helpfully sends us to
make sure our views of the keyboard state are always identical, rather
than relying on key press events to do the right thing.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This isn't very pleasant, but it's pretty much the best we can do in the
absence of either XCB XKB support, or XCB XI2 bindings (argh!).
We get a state mask with most significant X11 events (which inexplicably
includes EnterNotify but not FocusIn), but unfortunately it's only a
single flat set of effective modifiers rather than the more granular
sets we want, so we still update the state with every key, but then also
use the core X11 state as a mask to make sure we don't get any stuck
modifiers.
Ugh.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Make sure that we always have the exact same view of the keyboard state
as the host server by using XKB StateNotify events to update our state
exactly rather than relying on key events. In particular, this fixes
key state during grabs, where we either miss modifiers completely or get
them stuck permanently, depending on the nature of the grab and the
implementation of the X window manager/compositor.
The downside, however, is that Weston wakes up on every modifier change,
regardless of whether or not it has focus.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
notify_modifiers will now synchronise Weston's internal state with the
XKB state, and send a modifier event if necessary. This eliminates the
need for update_modifier_state to have a return value at all.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If update_state is true, then notify_key will continue to call
xkb_key_update_state to update the local state mask, as before this
commit. Otherwise, it will rely on the compositor to manually update
the state itself, for nested compositors.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If we have XCB XKB support, use XKB's detectable autorepeat, which
generates repeat sequences as a series of
press-press-press-[...]-release events, rather than
press-release-press-release-[...].
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
X11 has a set of eight modifiers which we want to represent. Cache
their indices when we create a weston_xkb_info, so we can use this from
compositor-x11 to keep the state synchronised exactly between the host X
server and a nested Weston instance.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This is mainly for X11's benefit; the common case is using Logo+S to
take a screenshot, where GNOME Shell has grabbed Logo, and replays the
event down to the nested compositor after S is pressed. This means we
get an enter event with both Logo and S down, and even if Shell delivers
the key press event for S (which isn't mandatory, and not all window
managers do), then we never run the binding since notify_key realises
that S is already down and exits early.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
When the focus changes, wl_keyboard_set_focus (and, as an added bonus,
wl_pointer_set_focus) will now send wl_keyboard::modifier events for us
if we store the modifier state in the right place, so we don't have to
worry about that anymore.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
It seems we used to rely on the repaint scheduled by the cursor motion.
But if there's no cursor, there's no cursor motion, so we need to schedule
our own repaint.
Print an user friendly error mesage when
the variable is not a valid directory.
krh: Edited to make message a litle more precise and added a check to
verify XDG_RUNTIME_DIR ownership and access mode.
Since we now batch up damage and only handle it at repaint time, we need
to apply it in case a buffer is destroyed so we don't lose it.
Ander found the problem, but we need to fix it in the compositor so we
don't change the behavior of the compositor.
weston_surface_update_transform() is typically called as part of the
repaint cycle so don't schedule a repaint here. There are still a couple
of places where we call weston_surface_update_transform() manually, but
they don't rely on the repaint being scheduled.
We need to initialize prev when we handle the initial pixel in a
rectangle, or we may detect the following pixel as identical or different
when it's not. This causes the top-left pixel in a rectangle to
occasionally be wrong leaving a trail of "dirty pixels" in the capture.
This is the point where we have just finished rendering the new scene
but before we swap it to the front buffer. At this point, the
output->previous_damage region exactly corresponds to what was just
renders, as compared to previous frame.
We start tracking which hardware plane a surface is displayed on, which
lets us avoid generating damage when a hardware overlay/cursor is moved
around.
Kristian Høgsberg
Ander Conselvan de Oliveira
Daniel Stone
Jan Arne Petersen
Martin Minarik