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.
Emacs uses tab and backspace to move the cursor as well as the regular
cursor movement escape codes. When it's less bytes than the escape code,
emacs will use a tab or tab + backspace to move the cursor forward. The
effect is that as you're moving around in the buffer, emacs will
(seemingly) randomly insert spaces and overwrite what's in the terminal.
Making tab just move the cursor as it should fixes this.
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>
If the cursor didn't change since last time we had pointer focus we just
wouldn't change it. But whoever had pointer focus in the mean time could
have changed it, so make sure we always set the cursor after pointer enter.
When the icon provided in weston.ini is not available, it will report a segfault error.
Check the icon at first.
backtrace:
*INT_cairo_surface_status (surface=0x0) at cairo-surface.c:259
259 {
(gdb) bt
#0 *INT_cairo_surface_status (surface=0x0) at cairo-surface.c:259
#1 0x0804baca in tablet_shell_add_launcher (data=0xbfb800ec)
at tablet-shell.c:404
#2 launcher_section_done (data=0xbfb800ec) at tablet-shell.c:434
#3 0x08051121 in parse_config_file (
path=0x8b96c10 "/root/.config/weston.ini", sections=0x8053c80,
num_sections=2, data=0xbfb800ec) at config-parser.c:113
#4 0x0804c0f9 in main (argc=1, argv=0xbfb801d4) at tablet-shell.c:480
Signed-off-by: Juan Zhao <juan.j.zhao@linux.intel.com>
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.
Kristian Høgsberg
Ander Conselvan de Oliveira
Daniel Stone
Jan Arne Petersen
Juan Zhao