In previous chapters, we built a simple client which can present its surfaces onthe display. Let's expand this code a bit to build a client which can receiveinput events. For the sake of simplicity, we're just going to be logging inputevents to stderr.

Compared to a year ago not much has changed: NVIDIA still does not support the standard Linux solution gbm, which is supported by all vendors and nowadays even going to enter the mobile space. The purism phone is going to have a standard graphics stack with gbm. So no additional code required. But NVIDIA doesn’t support gbm.
We have servers (still in their early stage) on Linux, Windows, Mac OS X and now Wayland. All of this is available under the Apache license. One common mistake about RDP is to compare only in terms of the core feature set, which is graphics remoting and input.

This is going to require a lot more code than we've worked with so far, so getstrapped in. The first thing we need to do is set up the seat.

A 'Wayland Compositor' is a display server that uses the Wayland protocol. GTK+, Clutter, and QT5 have full support for Wayland. Wayland compositors also function as window managers. Mir is the only display server that uses the Mir protocol, so in this case, the display server and protocol are referred to by the same name. Mir is developed. Wayland is a protocol, while Xorg is a display server (using X11 protocol). Wayland is the 'new' thing and works diffrenetly than x11. Back when x11 was created, it was common to have one poweful (time sharing) server and multiple clients that are connecting to it.

Setting up the seat

The first thing we'll need is a reference to a seat. We'll add it to ourclient_state struct, and add keyboard, pointer, and touch objects for lateruse as well:

We'll also need to update registry_global to register a listener for thatseat.

Note that we bind to the latest version of the seat interface, version 7. Let'salso rig up that listener:

If you compile (cc -o client client.c xdg-shell-protocol.c) and run this now,you should seat the name of the seat printed to stderr.

Rigging up pointer events

Let's get to pointer events. If you recall, pointer events from the Waylandserver are to be accumulated into a single logical event. For this reason, we'llneed to define a struct to store them in.

We'll be using a bitmask here to identify which events we've received for asingle pointer frame, and storing the relevant information from each event intheir respective fields. Let's add this to our state struct as well:

Then we'll need to update our wl_seat_capabilities to set up the pointerobject for seats which are capable of pointer input.

This merits some explanation. Recall that capabilities is a bitmask of thekinds of devices supported by this seat - a bitwise AND (&) with a capabilitywill produce a non-zero value if supported. Then, if we have a pointer and havenot already configured it, we take the first branch, usingwl_seat_get_pointer to obtain a pointer reference and storing it in our state.If the seat does not support pointers, but we already have one configured, weuse wl_pointer_release to get rid of it. Remember that the capabilities of aseat can change at runtime, for example when the user un-plugs and re-plugstheir mouse.

We also configured a listener for the pointer. Let's add the struct for that,too:

Pointers have a lot of events. Let's have a look at them.

The 'enter' and 'leave' events are fairly straightforward, and they set thestage for the rest of the implementation. We update the event mask to includethe appropriate event, then populate it with the data we were provided. The'motion' and 'button' events are rather similar:

Axis events are somewhat more complex, because there are two axes: horizontaland vertical. Thus, our pointer_event struct contains an array with two groupsof axis events. Our code to handle these ends up something like this:

Similarly straightforward, aside from the main change of updating whichever axiswas affected. Note the use of the 'valid' boolean as well: it's possible thatwe'll receive a pointer frame which updates one axis, but not another, so we usethis 'valid' value to determine which axes were updated in the frame event.

Speaking of which, it's time for the main attraction: our 'frame' handler.

It certainly is the longest of the bunch, isn't it? Hopefully it isn't tooconfusing, though. All we're doing here is pretty-printing the accumulated statefor this frame to stderr. If you compile and run this again now, you should beable to wiggle your mouse over the window and see input events printed out!

Rigging up keyboard events

Let's update our client_state struct with some fields to store XKB state.

We need the xkbcommon headers to define these. While we're at it, I'm going topull in assert.h as well:

We'll also need to initialize the xkb_context in our main function:

Next, let's update our seat capabilities function to rig up our keyboardlistener, too.

We'll have to define the wl_keyboard_listener we use here, too.

And now, the meat of the changes. Let's start with the keymap:

Now we can see why we added assert.h — we're using it here to make surethat the keymap format is the one we expect. Then, we use mmap to map the filedescriptor the compositor sent us to a char * pointer we can pass intoxkb_keymap_new_from_string. Don't forget to munmap and close that fdafterwards — then we set up our XKB state. Note as well that we have alsounrefed any previous XKB keymap or state that we had set up in a prior call tothis function, in case the compositor changes the keymap at runtime.¹

When the keyboard 'enters' our surface, we have received keyboard focus. Thecompositor forwards a list of keys which were already pressed at that time, andhere we just enumerate them and log their keysym names and UTF-8 equivalent.We'll do something similar when keys are pressed:

And finally, we add small implementations of the three remaining events:

For modifiers, we could decode these further, but most applications won't needto. We just update the XKB state here. As for handling key repeat — thishas a lot of constraints particular to your application. Do you want to repeattext input? Do you want to repeat keyboard shortcuts? How does the timing ofthese interact with your event loop? The answers to these questions is left foryou to decide.

If you compile this again, you should be able to start typing into the windowand see your input printed into the log. Huzzah!

Rigging up touch events

Finally, we'll add support for touch-capable devices. Like pointers, a 'frame'event exists for touch devices. However, they're further complicated by thepossibility that mulitple touch points may be updated within a single frame.We'll add some more structures and enums to represent the accumulated state:

Note that I've arbitrarily choosen 10 touchpoints here, with the assumption thatmost users will only ever use that many fingers. For larger, multi-user touchscreens, you may need a higher limit. Additionally, some touch hardware supportsfewer than 10 touch points concurrently — 8 is also common, and hardwarewhich supports fewer still is common among older devices.

We'll add this struct to client_state:

And we'll update the seat capabilities handler to rig up a listener when touchsupport is available.

We've repeated again the pattern of handling both the appearance anddisappearance of touch capabilities on the seat, so we're robust to devicesappearing and disappearing at runtim

Does Wayland Server Still Exist