Fix a few unconditional dereferences of seat->keyboard and seat->pointer
in paths that could be hit outside of input event processing.
Reported-by: Pekka Paalanen <ppaalanen@gmail.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We'll get a rash of seats added when we run our first wl_display_iterate
across the parent display, but won't actually be ready to create them.
Create a new global listener on our parent display for wl_seats only,
and run that from wayland_input_create.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We use the selection signal to get a callback when somebody sets a
selection (including the X server proxy) and then copy the contents
of the first mime type. If the selection is cleared (when the client
dies), we set a new selection with that contents.
These keymap events communicate the keymap from the compositor to the
clients via fd passing, rather than having the clients separately
compile a map.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of mangling the names we've stored in the compositor, generate
our own keymap and pass that to weston_seat_init_keyboard.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We were accidentally trying to initialise the wl_seat we just got from
our host server as a weston_seat, rather than the weston_seat we set up
earlier ...
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The O_RDWR change got lost in a rebase, and as Peter suggested as well,
make sure to set EVDEV_KEYBOARD if the device has EV_LED.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The patch "compositor-android: fix build flags" started using GCC_CFLAGS
for C++ files, too. That lead to the following warnings when building a
C++ file:
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wmissing-prototypes" is valid
for Ada/C/ObjC but not for C++
Introduce GCC_CXXFLAGS, similar to GCC_CFLAGS, but for C++, avoiding the
problematic compiler flags.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
When adding a C++ file to the build, I forgot to set CXXFLAGS for it,
triggering the error:
android-framebuffer.h:26:21: fatal error: EGL/egl.h: No such file or
directory
I never hit this, because I have EGL headers installed also in my
system, rather than only in $prefix.
Fix this by setting the CXXFLAGS for the android backend.
Reported-by: Scott Moreau <oreaus@gmail.com>
Reported-by: Tiago Vignatti <tiago.vignatti@intel.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This allows backends to generate their own keymaps and pass them in for
use rather than always forcing a single global keymap, which is
particularly useful for nested compositors.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
In practice this doesn't mean much right now, since they all just take
an extra reference on the global keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Rather than using a single hardcoded seat to activate new windows within
a compositor, reset the focus for all seats.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of using a uint32_t for state everywhere (except on the wire,
where that's still the call signature), use the new
wl_keyboard_key_state enum, and explicit comparisons.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of using a uint32_t for state everywhere (except on the wire,
where that's still the call signature), use the new
wl_pointer_button_state enum, and explicit comparisons.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Took me a second to work out that the 272 was actually BTN_LEFT, as keys
and buttons share a namespace in evdev.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Does what it says on the box: lists whether or not the device supports
key, absolute, relative or touch classes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Similar to how we deal with modifiers, also add LED handling to the core
input code, with a callout into the backends to update them when they
change.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
When we update the modifier_state used for Weston bindings, derive this
from the XKB modifier state, rather than a hardcoded mapping of physical
keys to modifier state.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
As we need to keep a separate state for every seat (i.e. keyboard
interface) rather than a compositor-global state.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This event lets the compositor inform clients of the canonical keyboard
modifier/group state. Make sure we send it at appropriate moments from
the compositor, and listen for it in clients as well.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
As well as just updating Weston's internal modifier_state, also update
our xkb_state object, in preparation for serialising modifier values to
clients. This also makes update_modifier_state return 1 if the
modifier/group state has changed, or 0 if not.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Scott Moreau