Here's my summary/overview/review of the first 3 chapters.

The book starts with a very high-level view of what computer interaction
is about: input and output devices as shared resources, the kernel taking
care of abstracting interacting with them via drivers and libraries that
have a common interface.
We're presented with a run down from hardware, kernel, to userspace.
This takes the form of evdev for mapping devices in /dev, and DRM to
abstract graphics and map them into userspace unto /dev/dri for each card.
KMS, a subset of DRM, is used to enumerate displays and configure their
settings.

Wayland is explained as a protocol to do compositing, drawing windows
on output devices, and providing a common access to input and output
devices. Wayland is the protocol allowing interaction between different
clients containing objects implementing interfaces (requests and events)
related these graphics, input and output devices.

In the Wayland world different libraries are used, the author lists a
couple of them:

• libdrm is the user-space interaction for the kernel DRM.
  
• Mesa is a vendor optimized OpenGL (and Vulkan) and GBM (Generic Buffer Management). From what I know OpenGL is a graphic standard, so is abstract, while DRM is a specific Linux implementation.
  
• libinput: abstract handling input devices
  
• xkbcommon: used for keyboard mapping, from scan codes to symbols. It reminds me of keysymdef header.
  
• pixman: pixel manipulation library (image compositing)
  
• libwayland: most commonly used implementation of the Wayland protocol, tools to generate high-level code from Wayland protocol definition (XML files). This is sort of like what XCB does for X.
  

That's as far as the introductory chapter goes, the next two chapters
(2 and 3), in my opinion, go over the wayland basic wire protocol and
library implementation.
The main message I took from them was that Wayland is built on the
concept of separation of concerns. The clients and servers implement
well-known interfaces, they agree on a shared abstract language and
promise to respect them.
Practically, this takes the form of auto-generated functions, built from
agreed primitive types, that will take care of marshalling two things
for each implemented interface: events and requests.

When installing the basic Wayland package you're given some
basic definition of the protocol via XML files, the main one being
wayland.xml, which on my machine are found in /usr/share/wayland and
/usr/share/wayland-protocols.
In these directories you can also find a distinction between stable
and unstable branches, which is explained to be the way Wayland decides
whether something should be supported by everyone or kept on the side
as testing.

A script called wayland-scanner can be used to convert these xml files
into code, for either the server, or client, or other.
libwayland, if I understood properly, is some pregenerated library from
the basic protocol.
wayland-scanner generates for interfaces requests and listeners functions.
Listening for events using `wl_listener` and can send requests.
listening to events such as "enter", "leave".
The namespace, the start of the function name is the interface.


As far as the protocol is concerned, the messages are exchanged over
Unix sockets. The Wayland compositor, the server, being the routing.
The clients find the address of the server by running checks on different
environment variables:
WAYLAND_SOCKET, WAYLAND_DISPLAY along with XDG_RUNTIME_DIR, or assume
the name is XDG_RUNTIME_DIR/wayland-0


Objects can live either on the client side or server side.
Objects implements some of these interfaces, knowing which interfaces
an object implements let you know what actions you can do with them. These
are either requests or events.
Objects are known to both client and server, it has states.
On the client side the object are interacted with using wl_proxy
interface, which is used to marshall requests of a specific interface
to be ready to go on the wire.
On the server side they are accessed using wl_resource, to find a
reference to the wl_client owning the resource.
The manpages say wl_proxy "Represents a protocol object on the client
side."

For example, we've seen the wl_surface interface, which represents a
drawable, sort of like in X.
There's a lot of other interfaces in the wayland-protocols directory
other than wayland.xml I find on my machine for different things. These
are probably the protocol extensions mentioned.

The basic protocol also implements atomicity. When issuing multiple
requests they don't take effect until the "commit" request is sent. I
think the summary in the xml is better than in the book "commit pending
surface state".

Chapter 3 ends by asking the question of how clients and server know
about all the objects, and their ids, that are currently available.