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.
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.
Daniel Stone
Kristian Høgsberg
Jan Arne Petersen
Juan Zhao
Martin Minarik