Input to Wayland clients is by seat devices (no, I have no idea what this means). This includes
Information about which devices are available is given
from the registry handler: the server sends the interface
"wl_seat" through the registry listener
to the client. The client should add a
seat listener, and this is called with a
wl_seat_capability structure.
This can be and-ed with different flags to test
for each input device.
A program to list the input devices is seat.c
There are five principal functions related to the pointer.
They are defined by a structure of type
wl_pointer_listener:
static const struct wl_pointer_listener pointer_listener = {
pointer_handle_enter,
pointer_handle_leave,
pointer_handle_motion,
pointer_handle_button,
pointer_handle_axis,
};
Enter, leave, motion and button are self-explanatory. Axis is for motion vertically or horizontally as in sweep gestures.
The listeners are added by wl_pointer_add_listener.
However, just doing that isn't good enough: the surface is actually
overlaid by a shell surface, and that intercepts
pointer events. Now I don't understand why, but Wayland seems
to require that there should be a shell surface listener
that responds to ping events from the server
and replies with pong messages. Then the underlying
surface gets the pointer events correctly.
The surface shell listener is added by a call to
wl_shell_surface_add_listener with a structure
static const struct wl_shell_surface_listener shell_surface_listener = {
handle_ping,
handle_configure,
handle_popup_done
};
The program to print enter, leave, motion and click events is pointer.c. It adds pointer tracking to the simple EGL drawing window of Chapter X:
There is a call that a client can make to the server of
wl_shell_surface_move. This can be added
to, say, pointer_handle_button on a left
button drag. While Wayland knows about button state
as in WL_POINTER_BUTTON_STATE_PRESSED it
doesn't know which button is which. These are defined in
linux/input.h as BTN_LEFT, etc.
The changes to allow a button drag to move the window are given in move.c:
static void
pointer_handle_button(void *data, struct wl_pointer *wl_pointer,
uint32_t serial, uint32_t time, uint32_t button,
uint32_t state)
{
printf("Pointer button\n");
if (button == BTN_LEFT && state == WL_POINTER_BUTTON_STATE_PRESSED)
wl_shell_surface_move(shell_surface,
seat, serial);
}
A cursor is an image.
Such images are stored in shared memory,
so before getting one, you have to ask the registry
for a shared memory proxy.
Then there are functions in Wayland to
find suitable images, by loading a theme
(wl_cursor_theme_load) and then
getting a cursor for that theme by
wl_cursor_theme_get_cursor.
Using NULL for the cursor theme
will load the default theme, which is usually the
standard X Window cursor theme.
if (strcmp(interface, "wl_shm") == 0) {
shm = wl_registry_bind(registry, id,
&wl_shm_interface, 1);
cursor_theme = wl_cursor_theme_load(NULL, 32, shm);
default_cursor =
wl_cursor_theme_get_cursor(cursor_theme, "left_ptr");
}
Wayland has windows, images and pixel buffers. So far we have dealt only with windows. To handle a cursor, we now have to build a Wayland image surface. This can be done once a compositor has been found, by
cursor_surface =
wl_compositor_create_surface(compositor);
Finally, in pointer_handle_enter
we get a Wayland buffer for the image, install
that into the cursor's image surface
and send that to the server.
The resultant code is cursor.c:
Wayland uses the Linux evdev system as in
There are many ways of encoding characters, such as ASCII, EBCDIC
etc. Evdev uses keycodes which are basically the enumerated
positions of keys on a QWERTY keyboard. So for example 'q' is 16,
'w' is 17, 'e' is 18 and so on. The codes are defined in
include/linux/input.h as KEY_Q,
KEY_W and so on. A readable table is at
Linux Keycode Table
.
If you just want keycodes, you can get them from the Wayland keyboard listener. If you want characters such as 'a' versus 'A' you have to do more work. For example, pressing 'a' generates
keycode = 30, state = down
keycode = 30, state = up
while 'A' generates
keycode = 42, state = down
keycode = 30, state = down
keycode = 30, state = up
keycode = 42, state = up
A finite state machine or similar is needed to track this.
This is only scratching the surface though: to input languages
such as Chinese or Arabic requires a full-blown input method
such as SCIM for X, and there only seems to be experimental
work in Weston so far.
A program to list keycodes is keyboard.c :