Merge branch 'wip/typos' into 'main'

Fix a bunch of typos

See merge request libinput/libei!385

README.md

@@ -24,7 +24,7 @@ The protocol documentation is available
 The C library API documentation is available here:
 - [libei](https://libinput.pages.freedesktop.org/libei/api/group__libei.html)
 - [libeis](https://libinput.pages.freedesktop.org/libei/api/group__libeis.html)
-- [liboffis](https://libinput.pages.freedesktop.org/libei/api/group__liboeffis.html)
+- [liboeffis](https://libinput.pages.freedesktop.org/libei/api/group__liboeffis.html)
 
 Overview
 --------
@@ -185,8 +185,8 @@ but instead other X protocol requests").
 One example is `xdotool` which does window focus and modifier mangling (see
 below). Window focus notification is not available to a pure **libei**
 client and would have to be obtained or handled on a separate channel, e.g.
-X or Wayland. Having said that, a Wayland client does not usually have acess
+X or Wayland. Having said that, a Wayland client does not usually have access
-to query or modifiy the window focus.
+to query or modify the window focus.
 
 Modifiers in `xdotool` are handled by obtaining the modifier mask from the X
 server, identifying any difference to the intended mask and emulating key
@@ -242,7 +242,7 @@ The current approach works so that
   has no further influence.
 
 This describes the **current** implementation. Changes to this approach are
-likely, e.g. the portal **may** control pauseing/resuming devices (in addition to the
+likely, e.g. the portal **may** control pausing/resuming devices (in addition to the
 server). The UI for this is not yet sorted.
 
 ### Authentication
@@ -254,7 +254,7 @@ opaque key/value system so the exact auth can be left to the implementation.
 
 ### Capability monitoring
 
-For the use-case of fowarding input (e.g. `synergy`) we need a method of
+For the use-case of forwarding input (e.g. `synergy`) we need a method of
 capturing input as well as forwarding input. An initial idea was for
 **libei** to provide capability monitoring, i.e. a client requests all
 events from a specific capability. As with input emulation same benefits

proto/protocol.xml

@@ -391,7 +391,7 @@
       <description summary="done event">
         Informs the client that the associated request is finished. The EIS
         implementation must destroy the ei_callback object immediately after
-        sending this event this event and as such the client must not attempt to
+        sending this event and as such the client must not attempt to
         use it after that point.
       </description>
       <arg name="callback_data" type="uint64" summary="request-specific data for the callback"/>
@@ -510,7 +510,7 @@
         Informs the client that this seat has been removed, and that it should
         release all associated resources.
 
-        This ei_seat object will be destroyed by the EIS implementation immediately after
+        This ei_seat object will be destroyed by the EIS implementation immediately
         after this event is sent and as such the client must not attempt to use
         it after that point.
       </description>
@@ -639,7 +639,7 @@
     </request>
 
     <request name="stop_emulating" since="1" context-type="sender">
-      <description summary="Device start emulating request">
+      <description summary="Device stop emulating request">
         Notify the EIS implementation that the given device is no longer sending
         events. See ei_device.start_emulating for details.
 
@@ -689,7 +689,7 @@
         by the protocol) is complete and the EIS implementation may
         send ei_device.resumed.
 
-        This allows for future further negotation of the device behavior and
+        This allows for future further negotiation of the device behavior and
         or device properties before the device is finalized by the EIS implementation.
 
         A client supporting version 3 of the ei_device interface must issue
@@ -706,7 +706,7 @@
         This device has been removed and a client should release all
         associated resources.
 
-        This ei_device object will be destroyed by the EIS implementation immediately after
+        This ei_device object will be destroyed by the EIS implementation immediately
         after this event is sent and as such the client must not attempt to use
         it after that point.
       </description>
@@ -786,7 +786,7 @@
 
         Absolute devices may have different regions, it is up to the client to
         send events through the correct device to target the right pixel. For
-        example, a dual-head setup my have two absolute devices, the first with
+        example, a dual-head setup may have two absolute devices, the first with
         a zero offset region spanning the left screen, the second with a nonzero
         offset spanning the right screen.
 
@@ -990,7 +990,7 @@
         This object has been removed and a client should release all
         associated resources.
 
-        This object will be destroyed by the EIS implementation immediately after
+        This object will be destroyed by the EIS implementation immediately
         after this event is sent and as such the client must not attempt to use
         it after that point.
       </description>
@@ -1053,7 +1053,7 @@
         This object has been removed and a client should release all
         associated resources.
 
-        This object will be destroyed by the EIS implementation immediately after
+        This object will be destroyed by the EIS implementation immediately
         after this event is sent and as such the client must not attempt to use
         it after that point.
       </description>
@@ -1094,7 +1094,7 @@
 
     <request name="scroll" since="1" context-type="sender">
       <description summary="Scroll request">
-        Generate a a smooth (pixel-precise) scroll event on this pointer.
+        Generate a smooth (pixel-precise) scroll event on this pointer.
         Clients must not send ei_scroll.scroll_discrete events for the same event,
         the EIS implementation is responsible for emulation of discrete
         scroll events.
@@ -1112,7 +1112,7 @@
 
     <request name="scroll_discrete" since="1" context-type="sender">
       <description summary="Scroll discrete request">
-        Generate a a discrete (e.g. wheel) scroll event on this pointer.
+        Generate a discrete (e.g. wheel) scroll event on this pointer.
         Clients must not send ei_scroll.scroll events for the same event,
         the EIS implementation is responsible for emulation of smooth
         scroll events.
@@ -1134,7 +1134,7 @@
 
     <request name="scroll_stop" since="1" context-type="sender">
       <description summary="Scroll stop request">
-        Generate a a scroll stop or cancel event on this pointer.
+        Generate a scroll stop or cancel event on this pointer.
 
         A scroll stop event notifies the EIS implementation that the interaction causing a
         scroll motion previously triggered with ei_scroll.scroll or
@@ -1152,7 +1152,7 @@
         may ignore either or all such requests and/or disconnect the client.
 
         It is a client bug to send this request for an axis that
-        had a a nonzero value in either ei_scroll.scroll or ei_scroll.scroll_discrete
+        had a nonzero value in either ei_scroll.scroll or ei_scroll.scroll_discrete
         in the current frame and the EIS implementation
         may ignore either or all such requests and/or disconnect the client.
 
@@ -1171,7 +1171,7 @@
         This object has been removed and a client should release all
         associated resources.
 
-        This object will be destroyed by the EIS implementation immediately after
+        This object will be destroyed by the EIS implementation immediately
         after this event is sent and as such the client must not attempt to use
         it after that point.
       </description>
@@ -1269,7 +1269,7 @@
         This pointer has been removed and a client should release all
         associated resources.
 
-        This ei_scroll object will be destroyed by the EIS implementation immediately after
+        This ei_scroll object will be destroyed by the EIS implementation immediately
         after this event is sent and as such the client must not attempt to use
         it after that point.
       </description>
@@ -1349,7 +1349,7 @@
         This keyboard has been removed and a client should release all
         associated resources.
 
-        This ei_keyboard object will be destroyed by the EIS implementation immediately after
+        This ei_keyboard object will be destroyed by the EIS implementation immediately
         after this event is sent and as such the client must not attempt to use
         it after that point.
       </description>
@@ -1565,7 +1565,7 @@
         This touch has been removed and a client should release all
         associated resources.
 
-        This ei_touchscreen object will be destroyed by the EIS implementation immediately after
+        This ei_touchscreen object will be destroyed by the EIS implementation immediately
         after this event is sent and as such the client must not attempt to use
         it after that point.
       </description>

src/brei-shared.h

@@ -56,7 +56,7 @@ struct brei_result *
 brei_result_new_from_neg_errno(int err);
 
 _printf_(2, 3) struct brei_result *
-brei_result_new(int reson, const char *format, ...);
+brei_result_new(int reason, const char *format, ...);
 
 OBJECT_DECLARE_GETTER(brei_result, data, void *);
 OBJECT_DECLARE_SETTER(brei_result, data, void *);

src/libei.h

@@ -77,7 +77,7 @@ extern "C" {
  * @ingroup libei
  *
  * The receiver client API is available only to clients created with
- * ei_new_receiver(). For those clients the EIS implemententation creates
+ * ei_new_receiver(). For those clients the EIS implementation creates
  * devices and sends events **to** the libei client. The primary use-case
  * for this is input capturing, e.g. InputLeap.
  *
@@ -88,8 +88,8 @@ extern "C" {
  * @ingroup libei
  *
  * The sender client API is available only to clients created with
- * ei_new_sender(). For those clients the EIS implemententation creates
+ * ei_new_sender(). For those clients the EIS implementation creates
- * devices and but it is the libei client that sends events **to** EIS
+ * devices but it is the libei client that sends events **to** EIS
  * implementation.
  * The primary use-case is input emulation from a client, akin to xdotool.
  *
@@ -175,7 +175,7 @@ struct ei_event;
 /**
  * @struct ei_keymap
  *
- * An keymap for a device with the @ref EI_DEVICE_CAP_KEYBOARD capability.
+ * A keymap for a device with the @ref EI_DEVICE_CAP_KEYBOARD capability.
  *
  * An @ref ei_keymap is refcounted, see ei_keymap_unref().
  */
@@ -197,7 +197,7 @@ struct ei_keymap;
  *
  * Absolute devices may have different regions, it is up to the libei client
  * to send events through the correct device to target the right pixel. For
- * example, a dual-head setup my have two absolute devices, the first with a
+ * example, a dual-head setup may have two absolute devices, the first with a
  * zero offset region spanning the first screen, the second with a nonzero
  * offset spanning the second screen.
  */
@@ -386,7 +386,7 @@ enum ei_event_type {
 	 * are discarded.
 	 *
 	 * When this event is received, the device is already removed. A
-	 * caller does not need to call ei_device_close() event on this
+	 * caller does not need to call ei_device_close() even on this
 	 * device.
 	 */
 	EI_EVENT_DEVICE_REMOVED,
@@ -428,10 +428,10 @@ enum ei_event_type {
 	 *
 	 * For receiver clients, this will always be properly ordered with
 	 * EI_EVENT_KEYBOARD_KEY events, so each key event should be
-	 * interpreted should using the most recently received  modifier
+	 * interpreted using the most recently received modifier
 	 * state.
 	 *
-	 * For sender clients, the this event is not inherently synchronized
+	 * For sender clients, this event is not inherently synchronized
 	 * with calls to ei_device_keyboard_key(), but the client may call
 	 * ei_ping() when synchronization is required. When the corresponding
 	 * EI_EVENT_PONG event is received, all key events sent prior to the
@@ -492,7 +492,7 @@ enum ei_event_type {
 	 * @note These events are only generated on a receiver ei context.
 	 * See ei_device_start_emulating() for the sender context API.
 	 *
-	 * Note that a server start multiple emulating sequences
+	 * Note that a server may start multiple emulating sequences
 	 * simultaneously, depending on the devices available.
 	 * For example, in a synergy-like situation, the server
 	 * may start sending pointer and keyboard once the remote device
@@ -576,7 +576,7 @@ enum ei_event_type {
 	/**
 	 * Event for a single touch set down on the device's logical surface.
 	 * A touch sequence is always down/up with an optional motion event in
-	 * between. On multitouch capable devices, several touchs eqeuences
+	 * between. On multitouch capable devices, several touch sequences
 	 * may be active at any time.
 	 *
 	 * @note This event is only generated on a receiver ei context.
@@ -836,7 +836,7 @@ ei_setup_backend_fd(struct ei *ei, int fd);
  * with the EIS server listening on that socket.
  *
  * @note This backend requires the socket to be accessible
- * to connect to and forces the EIS implementation to to identification and
+ * to connect to and forces the EIS implementation to do identification and
  * access control for clients. In almost all cases, the EIS implementation
  * should use pre-created fds per client and the client should instead use
  * ei_setup_backend_fd(). This backend is primarily useful for testing and
@@ -1083,7 +1083,7 @@ ei_seat_bind_capabilities(struct ei_seat *seat, ...) __attribute__((sentinel));
  * @ingroup libei-seat
  *
  * Unbind a seat's capabilities, terminated by ``NULL``.
- * This function indicates the the application is
+ * This function indicates that the application is
  * no longer interested in devices with the given capability.
  *
  * If any devices with the given capability are present, libei automatically
@@ -1480,7 +1480,7 @@ ei_region_get_height(struct ei_region *region);
  * Note that in this example use-case, if the stream is resized
  * there may be a transition period where two regions have the same identifier -
  * the old region and the new region with the updated size. A client must be
- * able to handle the case where to mapping ids are identical.
+ * able to handle the case where two mapping ids are identical.
  *
  * libei does not look at or modify the value of the mapping id. Because the ID is
  * assigned by the caller libei makes no guarantee that the ID is unique
@@ -1636,7 +1636,7 @@ ei_device_get_context(struct ei_device *device);
  * ei_device_stop_emulating() after the most recent events.
  *
  * For example, in a synergy-like use-case the client would call
- * ei_device_start_emulating() once the pointer moves into the the screen and
+ * ei_device_start_emulating() once the pointer moves into the screen and
  * ei_device_stop_emulating() once the pointer moves out of the screen.
  *
  * Sending events before ei_device_start_emulating() or after
@@ -1646,7 +1646,7 @@ ei_device_get_context(struct ei_device *device);
  * It must go up by at least 1 on each call to
  * ei_device_start_emulating(). Wraparound must be handled by the EIS
  * implementation but Callers must ensure that detection of wraparound is
- * reasonably.
+ * reasonable.
  *
  * This method is only available on an ei sender context.
  */
@@ -1834,7 +1834,7 @@ ei_device_scroll_stop(struct ei_device *device, bool stop_x, bool stop_y);
  *
  * Calling ei_device_scroll_cancel() after
  * ei_device_scroll_stop() without any of ei_device_scroll_delta()
- * or ei_device_scroll_discrete() in between iis permitted.
+ * or ei_device_scroll_discrete() in between is permitted.
  *
  * libei keeps track of the scroll axis and filters duplicate calls to
  * ei_device_scroll_cancel() for the same axis. A nonzero scroll or
@@ -1999,7 +1999,7 @@ ei_event_get_seat(struct ei_event *event);
  * For events of type other than @ref EI_EVENT_PONG this function
  * returns NULL.
  *
- * This does not increase the refcount of the ei_pong. Use ei_pong_ref()
+ * This does not increase the refcount of the ei_ping. Use ei_ping_ref()
  * to keep a reference beyond the immediate scope.
  */
 struct ei_ping *

src/libeis.h

@@ -71,7 +71,7 @@ extern "C" {
  * @ingroup libeis
  *
  * The receiver API is available only to clients that are not
- * eis_client_is_sender(). For those clients the EIS implemententation creates
+ * eis_client_is_sender(). For those clients the EIS implementation creates
  * devices and sends events **to** the libei client. IOW the EIS implementation
  * acts as the sender. The primary use-case
  * for this is input capturing, e.g. InputLeap.
@@ -83,8 +83,8 @@ extern "C" {
  * @ingroup libeis
  *
  * This API is available only on clients that are
- * eis_client_is_sender(). For those clients the EIS implemententation creates
+ * eis_client_is_sender(). For those clients the EIS implementation creates
- * devices and but it is the libei client that sends events **to** EIS
+ * devices but it is the libei client that sends events **to** EIS
  implementation. IOW the EIS implementation acts as the receiver.
  * The primary use-case is input emulation from a client, akin to xdotool.
  *
@@ -175,7 +175,7 @@ struct eis_ping;
  *
  * Absolute devices may have different regions, it is up to the libei client
  * to send events through the correct device to target the right pixel. For
- * example, a dual-head setup my have two absolute devices, the first with a
+ * example, a dual-head setup may have two absolute devices, the first with a
  * zero offset region spanning the first screen, the second with a nonzero
  * offset spanning the second screen.
  *
@@ -264,7 +264,7 @@ enum eis_event_type {
 
 	/**
 	 * The client no longer listens to events from this device. The caller
-	 * should released resources associated with this device.
+	 * should release resources associated with this device.
 	 */
 	EIS_EVENT_DEVICE_CLOSED,
 
@@ -272,7 +272,7 @@ enum eis_event_type {
 	 * The client has completed configuration of the device (if any) and
 	 * the caller may call eis_device_resume().
 	 *
-	 * libei guarantees that this event even if the client
+	 * libei guarantees that this event is sent even if the client
 	 * does not support the underlying protocol.
 	 *
 	 * This event is only generated if the caller has called
@@ -328,7 +328,7 @@ enum eis_event_type {
 	 *
 	 * These events are only generated on a receiving EIS context.
 	 *
-	 * Note that a client start multiple emulating sequences
+	 * Note that a client may start multiple emulating sequences
 	 * simultaneously, depending on the devices it received from the
 	 * server. For example, in a synergy-like situation, the client
 	 * may start emulating of pointer and keyboard once the remote device
@@ -386,7 +386,7 @@ enum eis_event_type {
 	/**
 	 * Event for a single touch set down on the device's logical surface.
 	 * A touch sequence is always down/up with an optional motion event in
-	 * between. On multitouch capable devices, several touchs eqeuences
+	 * between. On multitouch capable devices, several touch sequences
 	 * may be active at any time.
 	 */
 	EIS_EVENT_TOUCH_DOWN = 800,
@@ -443,7 +443,7 @@ enum eis_flag {
 /**
  * Change the behavior of the context according to the
  * given flag. See @ref eis_flag for documentation on
- * each indidividual flag.
+ * each individual flag.
  *
  * This function must be called before any of eis_setup_backend_fd()
  * or eis_setup_backend_socket().
@@ -774,8 +774,8 @@ eis_event_get_seat(struct eis_event *event);
  * For events of type other than @ref EIS_EVENT_PONG this function
  * returns NULL.
  *
- * This does not increase the refcount of the eis_pong. Use eis_pong_ref()
+ * This does not increase the refcount of the eis_ping. Use eis_ping_ref()
- * to ekeep a reference beyond the immediate scope.
+ * to keep a reference beyond the immediate scope.
  */
 struct eis_ping *
 eis_event_pong_get_ping(struct eis_event *event);
@@ -884,7 +884,7 @@ eis_client_disconnect(struct eis_client *client);
  * that seat.
  *
  * This seat is not immediately active, use eis_seat_add() to bind this
- * seat on the client and notify the client of it's availability.
+ * seat on the client and notify the client of its availability.
  *
  * The returned seat is refcounted, use eis_seat_unref() to drop the
  * reference.
@@ -938,8 +938,8 @@ eis_seat_has_capability(struct eis_seat *seat, enum eis_device_capability cap);
  * @ingroup libeis-seat
  *
  * Allow a capability on the seat. This indicates to the client
- * that it may create devices with with the given capabilities, though the
+ * that it may create devices with the given capabilities, though the
- * EIS implementation may restrict the of capabilities on a device to a
+ * EIS implementation may restrict the set of capabilities on a device to a
  * subset of those in the seat, see eis_device_allow_capability().
  *
  * This function must be called before eis_seat_add().
@@ -1052,7 +1052,7 @@ eis_device_get_height(struct eis_device *device);
  * @ingroup libeis-seat
  *
  * Create a new device on the seat. This device is not immediately active, use
- * eis_device_add() to notify the client of it's availability.
+ * eis_device_add() to notify the client of its availability.
  *
  * The returned device is refcounted, use eis_device_unref() to drop the
  * reference.
@@ -1073,7 +1073,7 @@ eis_seat_new_device(struct eis_seat *seat);
 /**
  * @ingroup libeis-device
  *
- * Set the device type for this device. It is recommended that that the device
+ * Set the device type for this device. It is recommended that the device
  * type is the first call to configure the device as the device type
  * influences which other properties on the device can be set and/or will
  * trigger warnings if invoked with wrong arguments.

src/liboeffis.c

@@ -477,7 +477,7 @@ portal_start_response_received(sd_bus_message *m, void *userdata, sd_bus_error *
 
 	oeffis->state = OEFFIS_STATE_STARTED;
 
-	/* Response includes the the device bitmask but we don't care about this here */
+	/* Response includes the device bitmask but we don't care about this here */
 
 	/* Don't need a separate state here, ConnectToEIS is synchronous */
 	portal_connect_to_eis(oeffis);
@@ -555,7 +555,7 @@ portal_select_devices_response_received(sd_bus_message *m, void *userdata, sd_bu
 		return 0;
 	}
 
-	/* Response includes the the device bitmask but we don't care about this here */
+	/* Response includes the device bitmask but we don't care about this here */
 	portal_start(oeffis);
 
 	return 0;

src/util-io.c

@@ -779,7 +779,7 @@ MUNIT_TEST(test_pass_fd)
 	int sendrc = xsend_with_fd(left, data, sizeof(data), sendfds);
 	munit_assert_int(sendrc, ==, sizeof(data));
 
-	/* Write some data to the file on it's real fd */
+	/* Write some data to the file on its real fd */
 	for (size_t idx = 0; idx < ARRAY_LENGTH(fps); idx++) {
 		_cleanup_free_ char *buf = xaprintf("foo %zu\n", idx);
 		munit_assert_ptr_not_null(buf);

src/util-munit.c

@@ -37,7 +37,7 @@
 DECLARE_TEST_SECTION();
 DECLARE_GLOBAL_SETUP_SECTION();
 
-/* If the tests don't use MUNIT_GLOBAL_SETUP the the above has no linkage, so
+/* If the tests don't use MUNIT_GLOBAL_SETUP the above has no linkage, so
  * let's always define a noop internal one.
  */
 MUNIT_GLOBAL_SETUP(__internal)

test/eierpecken.c

@@ -262,7 +262,7 @@ peck_ei_enable_log_capture(struct peck *peck)
 void
 peck_ei_disable_log_capture(struct peck *peck)
 {
-	peck->ei_log_capture.enabled = true;
+	peck->ei_log_capture.enabled = false;
 }
 
 char **
@@ -291,7 +291,7 @@ peck_eis_enable_log_capture(struct peck *peck)
 void
 peck_eis_disable_log_capture(struct peck *peck)
 {
-	peck->eis_log_capture.enabled = true;
+	peck->eis_log_capture.enabled = false;
 }
 
 struct eis_client *
@@ -453,7 +453,7 @@ peck_capture_log(struct peck_log_capture *capture,
 		capture->error = strv_append_strdup(capture->error, message);
 		break;
 	case EI_LOG_PRIORITY_WARNING:
-		capture->info = strv_append_strdup(capture->info, message);
+		capture->warning = strv_append_strdup(capture->warning, message);
 		break;
 	case EI_LOG_PRIORITY_INFO:
 		capture->info = strv_append_strdup(capture->info, message);

test/eierpecken.h

@@ -301,7 +301,7 @@ _peck_dispatch_eis(struct peck *peck, int lineno);
  * state may mean either there are no events or events pending to be
  * processed by the caller.
  *
- * @return true if at least one behavior was processes according to the
+ * @return true if at least one behavior was processed according to the
  * current behavior
  */
 #define peck_dispatch_ei(_p) \

test/test-eis.c

@@ -80,7 +80,7 @@ MUNIT_TEST(eistest_name)
 	return MUNIT_OK;
 }
 
-MUNIT_TEST(eistest_cliend_bind_all_caps)
+MUNIT_TEST(eistest_client_bind_all_caps)
 {
 	_unref_(peck) *peck = peck_new();
 
@@ -119,7 +119,7 @@ MUNIT_TEST(eistest_cliend_bind_all_caps)
 	return MUNIT_OK;
 }
 
-MUNIT_TEST(eistest_cliend_bind_some_caps)
+MUNIT_TEST(eistest_client_bind_some_caps)
 {
 	_unref_(peck) *peck = peck_new();
 

test/test_protocol.py

@@ -4,7 +4,7 @@
 #
 #
 # EIS protocol test suite. This suite tests an EIS implementation, by default the
-# eis-demo-server to see how whether it handles protocol messages correctly.
+# eis-demo-server to see whether it handles protocol messages correctly.
 #
 # To test another implementation:
 # - set LIBEI_TEST_SOCKET to the path your EIS implementation is listening on

test/test_scanner.py

@@ -68,7 +68,7 @@ class TestScanner:
                     yield interface, event, arg
 
     @pytest.mark.parametrize("component", ("ei",))
-    def test_versione_arg(self, protocol: Protocol):
+    def test_version_arg(self, protocol: Protocol):
         for interface, message, arg in self.iterate_args(protocol):
             if arg.protocol_type == "new_id":
                 if f"{interface.plainname}.{message.name}" not in [