~sircmpwn/public-inbox

minor fixes and clarification in ch. 5.2 v1 PROPOSED

John Ferguson
John Ferguson: 1
 minor fixes and clarification in ch. 5.2

 8 files changed, 18 insertions(+), 11 deletions(-)
Export patchset (mbox)
How do I use this?

Copy & paste the following snippet into your terminal to import this patchset into git:

curl -s https://lists.sr.ht/~sircmpwn/public-inbox/patches/11494/mbox | git am -3
Learn more about email & git
View this thread in the archives

[PATCH] minor fixes and clarification in ch. 5.2 Export this patch

John Ferguson
---
 src/protocol-design/interfaces-reqs-events.md |  2 +-
 src/registry/binding.md                       |  2 +-
 src/registry/server-side.md                   | 11 +++++++++--
 src/seat.md                                   |  4 ++--
 src/seat/keyboard.md                          |  2 +-
 src/surfaces-in-depth/frame-callbacks.md      |  4 ++--
 src/surfaces/shared-memory.md                 |  2 +-
 src/xdg-shell-basics/xdg-surface.md           |  2 +-
 8 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/src/protocol-design/interfaces-reqs-events.md b/src/protocol-design/interfaces-reqs-events.md
index bea351a..53eae14 100644
--- a/src/protocol-design/interfaces-reqs-events.md
+++ b/src/protocol-design/interfaces-reqs-events.md
@@ -36,7 +36,7 @@ a specific output (the client might respond to this, for example, by adjusting
its scale factor for a HiDPI display). Here's an example of such a message:

    0000000A    Object ID (10)
    000B0000    Message length (12) and event opcode (0)
    000C0000    Message length (12) and event opcode (0)
    00000005    Output (object ID): 5

This message references another object, by its ID: the `wl_output` object which
diff --git a/src/registry/binding.md b/src/registry/binding.md
index 9c7390c..69c6f54 100644
--- a/src/registry/binding.md
+++ b/src/registry/binding.md
@@ -20,7 +20,7 @@ example, consider this wire protocol exchange:
```
C->S    00000001 000C0001 00000002            .... .... ....

S->C    00000002 001C0001 00000001 00000007   .... .... .... ....
S->C    00000002 001C0000 00000001 00000007   .... .... .... ....
        776C5f73 686d0000 00000001            wl_s hm.. ....
        [...]

diff --git a/src/registry/server-side.md b/src/registry/server-side.md
index f739676..b8e7c4b 100644
--- a/src/registry/server-side.md
+++ b/src/registry/server-side.md
@@ -22,7 +22,7 @@ main(int argc, char *argv[])
    struct my_state state = { ... };
    // ...
    wl_global_create(wl_display, &wl_output_interface,
        1, &my_state, wl_output_handle_bind);
        1, &state, wl_output_handle_bind);
    // ...
}
```
@@ -66,7 +66,7 @@ wl_output_handle_bind(struct wl_client *client, void *data,
    struct wl_resource *resource = wl_resource_create(
        client, &wl_output_implementation, wl_output_interface.version, id);

    wl_resource_set_implementation(resource, wl_output_implementation,
    wl_resource_set_implementation(resource, &wl_output_implementation,
        client_output, wl_output_handle_resource_destroy);

    client_output->resource = resource;
@@ -89,6 +89,13 @@ We also take the opportunity to allocate a small container for storing any
additional state we need that libwayland doesn't handle for us, the specific
nature of which varies from protocol to protocol.

**Note:** there are two distinct things here which share the same name:
`struct wl_output_interface` is an instance of an interface, where
`wl_output_interface` is a global constant variable generated by
`wayland-scanner` which contains metadata related to the implementation (such as
version, used in the example above). The code can be confusing to read if you
don't notice that these are separate things.

Our `wl_output_handle_release` function is called when the client sends the
`release` request, indicating that they no longer need this resource - so we
destroy it. This in turn triggers the `wl_output_handle_resource_destroy`
diff --git a/src/seat.md b/src/seat.md
index 10ca7f4..1c9f286 100644
--- a/src/seat.md
+++ b/src/seat.md
@@ -71,7 +71,7 @@ Before we get to those, let's cover some common semantics.

Some actions that a Wayland client may perform require a trivial form of
authentication in the form of input event serials. For example, a client which
opens a popup (a context menu summoned with a rick click is one kind of popup)
opens a popup (a context menu summoned with a right click is one kind of popup)
may want to "grab" all input events server-side from the affected seat until the
popup is dismissed.  To prevent abuse of this feature, the server can assign
serials to each input event it sends, and require the client to include one of
@@ -116,7 +116,7 @@ event handling that you'll want to concern yourself with this.

## Releasing devices

When you're done using a device, each interface has a `release` event you can
When you're done using a device, each interface has a `release` request you can
use to clean it up. It'll look something like this:

```xml
diff --git a/src/seat/keyboard.md b/src/seat/keyboard.md
index 1819d71..83df82b 100644
--- a/src/seat/keyboard.md
+++ b/src/seat/keyboard.md
@@ -165,7 +165,7 @@ The last event to consider is the "repeat_info" event:

In Wayland, the client is responsible for implementing "key repeat" — the
feature which continues to type characters as long as you've got the key held
doooooown. This request is sent to inform the client of the user's preferences
doooooown. This event is sent to inform the client of the user's preferences
for key repeat settings. The "delay" is the number of milliseconds a key should
be held down for before key repeat kicks in, and the "rate" is the number of
characters per second to repeat until the key is released.
diff --git a/src/surfaces-in-depth/frame-callbacks.md b/src/surfaces-in-depth/frame-callbacks.md
index ea246c2..b22f4d0 100644
--- a/src/surfaces-in-depth/frame-callbacks.md
+++ b/src/surfaces-in-depth/frame-callbacks.md
@@ -53,7 +53,7 @@ with your last frame to calculate the progress of an animation or to scale input
events.[^1]

With frame callbacks in our toolbelt, why don't we update our application from
chapter 7.2 so it scrolls a bit each frame? Let's start by adding a little bit
chapter 7.3 so it scrolls a bit each frame? Let's start by adding a little bit
of state to our `client_state` struct:

```diff
@@ -62,7 +62,7 @@ of state to our `client_state` struct:
@@ -71,6 +71,8 @@ struct client_state {
 	struct xdg_surface *xdg_surface;
 	struct xdg_toplevel *xdg_toplevel;
 	/* State */
+	/* State */
+	float offset;
+	uint32_t last_frame;
 };
diff --git a/src/surfaces/shared-memory.md b/src/surfaces/shared-memory.md
index 931bb15..e821e61 100644
--- a/src/surfaces/shared-memory.md
+++ b/src/surfaces/shared-memory.md
@@ -124,7 +124,7 @@ const int stride = width * 4;
const int shm_pool_size = height * stride * 2;

int fd = allocate_shm_file(shm_pool_size);
uint8_t *pool_data = mmap(NULL, size,
uint8_t *pool_data = mmap(NULL, shm_pool_size,
    PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

struct wl_shm *shm = ...; // Bound from registry
diff --git a/src/xdg-shell-basics/xdg-surface.md b/src/xdg-shell-basics/xdg-surface.md
index 6912fd5..6f6f68e 100644
--- a/src/xdg-shell-basics/xdg-surface.md
+++ b/src/xdg-shell-basics/xdg-surface.md
@@ -37,7 +37,7 @@ The most important API of xdg-surface is this pair: `configure` and
`ack_configure`. You may recall that a goal of Wayland is to make every frame
perfect. That means no frames are shown with a half-applied state change, and to
accomplish this we have to synchronize these changes between the client and
server. For XDG surfaces, this pair of requests is the mechanism which supports
server. For XDG surfaces, this pair of messages is the mechanism which supports
this.

We're only covering the basics for now, so we'll summarize the importance of
-- 
2.27.0
Thanks!

To git@git.sr.ht:~sircmpwn/wayland-book
   f2fc2a4..d169b68  master -> master