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 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>
wl_input_device has been both renamed and split. wl_seat is now a
virtual object representing a group of logically related input devices
with related focus.
It now only generates one event: to let clients know that it has new
capabilities. It takes requests which hand back objects for the
wl_pointer, wl_keyboard and wl_touch interfaces it exposes which all
provide the old input interface, just under different names.
This commit tracks these changes in weston and the clients, as well as
similar renames (e.g. weston_input_device -> weston_seat). Some other
changes were necessary, e.g. renaming the name for the visible mouse
sprite from 'pointer' to 'cursor' so as to not conflict.
For simplicity, every seat is always exposed with all three interfaces,
although this will change as time goes on.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
To add greater precision when working with transformed surfaces and/or
high-resolution input devices.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We check that we get surface.enter_output and move the pointer into
the window and make sure we get input_device.pointer_enter with
the right coordinates.
There's a lot of code for a very simple test here, so we need to
figure out how to reuse most of the event handling and such. It's also
not clear that a custom, text based protocol is practical here, we might
just use a wayland extension after all.
