fdo-mirrors/libei
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/libinput/libei.git synced 2026-04-03 15:10:39 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge branch 'wip/typos' into 'main'

Browse source 
Fix a bunch of typos

See merge request libinput/libei!385
This commit is contained in:
Peter Hutterer 2026-03-26 14:17:10 +10:00
commit 2e4b4e7e39
13 changed files with 67 additions and 67 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
README.md
View file

@ -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
to query or modifiy the window focus.
X or Wayland. Having said that, a Wayland client does not usually have access
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

32
proto/protocol.xml
View file

@ -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>

2
src/brei-shared.h
View file

@ -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 *);

34
src/libei.h
View file

@ -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
* devices and but it is the libei client that sends events **to** EIS
* ei_new_sender(). For those clients the EIS implementation creates
* 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 *

32
src/libeis.h
View file

@ -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
* devices and but it is the libei client that sends events **to** EIS
* eis_client_is_sender(). For those clients the EIS implementation creates
* 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()
* to ekeep a reference beyond the immediate scope.
* This does not increase the refcount of the eis_ping. Use eis_ping_ref()
* 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
* EIS implementation may restrict the of capabilities on a device to a
* that it may create devices with the given capabilities, though the
* 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.

4
src/liboeffis.c
View file

@ -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;

2
src/util-io.c
View file

@ -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);

2
src/util-munit.c
View file

@ -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)

6
test/eierpecken.c
View file

@ -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);

2
test/eierpecken.h
View file

@ -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) \

4
test/test-eis.c
View file

@ -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();

2
test/test_protocol.py
View file

@ -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

2
test/test_scanner.py
View file

@ -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 [