window.c: Always set cursor after pointer enter

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.
.gitignore: Ignore ctags and cscope output

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Split notify_keyboard_focus into in/out variants

Since the two functions had nothing in common but the local variables.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Let wayland-server send modifier events for focus

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>
Ignore repeat keys in notify_key

Let compositors just blithely post through every event they get,
including repeating keys.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Run key bindings on keyboard focus in

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>
weston_xkb_info: Cache all modifier indices for X11

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>
compositor-x11: Move input creation before output

So we can set up XKB masks and be sure to get the right events before
we set up our window.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
compositor-x11: Add base XCB/XKB support

Try to find the XKB extension, to be used in later commits.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
compositor-x11: Use XKB detectable autorepeat if possible

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>
notify_key: Add update_state argument

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>
Rename modifier_state_changed to notify_modifiers

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>
compositor-x11: Use XKB StateNotify to synchronise state

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>
compositor-x11: Attempt to track state without XKB

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>
compositor-wayland: Synchronise keyboard state with parent

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>
Split weston_compositor_init into base and _gl

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>
compositor-drm: Add proper error handling to init

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>
terminal: Only hide cursor for keypresses that generate data for the process
terminal: Ignore more modifier keys

Don't want these to leak into the terminal.