fdo-mirrors/libei
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/libinput/libei.git synced 2025-12-20 09:10:04 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs: Make the description of context types more generic

Browse source 
The protocol should be separate from any specific implementation's own
terms.

Part-of: <https://gitlab.freedesktop.org/libinput/libei/-/merge_requests/344>
This commit is contained in:
Axel Karjalainen 2025-07-10 19:49:36 +03:00 • committed by Marge Bot
parent f3f69e3a96
commit 4d999849ee
1 changed files with 15 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
proto/protocol.xml
View file

@ -79,22 +79,19 @@
</request> </request>
<enum name="context_type" since="1"> <enum name="context_type" since="1">
<description summary="context type"> <description summary="context types for connections">
This enum denotes context types for the libei context. Context types for connections. The context type for a connection is set
once in the ei_handshake.context_type request.
A context type of receiver is a libei context receiving events
from the EIS implementation. A context type of sender is a libei context
sending events to the EIS implementation.
</description> </description>
<entry name="receiver" value="1" summary="this client receives events from the EIS implementation"/> <entry name="receiver" value="1" summary="the client receives input events from the server"/>
<entry name="sender" value="2" summary="this client sends events to the EIS implementation"/> <entry name="sender" value="2" summary="the client sends input events to the server"/>
</enum> </enum>
<request name="context_type" since="1"> <request name="context_type" since="1">
<description summary="context type request"> <description summary="context type notification">
Notify the EIS implementation of the type of this context. The context types Notify the EIS implementation of the type of this context. The context
defines whether the client will send events to or receive events from the type defines whether the client will send input events to the server or
EIS implementation. receive input events from it.
Depending on the context type, certain requests must not be used and some Depending on the context type, certain requests must not be used and some
events must not be sent by the EIS implementation. events must not be sent by the EIS implementation.
@ -103,11 +100,11 @@
This request must not be sent more than once and must be sent before This request must not be sent more than once and must be sent before
ei_handshake.finish. ei_handshake.finish.
</description> </description>
<arg name="context_type" type="uint32" enum="context_type" summary="the client context type"/> <arg name="context_type" type="uint32" enum="context_type" summary="the connection's context type"/>
</request> </request>
<request name="name" since="1"> <request name="name" since="1">
<description summary="context name request"> <description summary="client name notification">
Notify the EIS implementation of the client name. The name is a Notify the EIS implementation of the client name. The name is a
human-presentable UTF-8 string and should represent the client name human-presentable UTF-8 string and should represent the client name
as accurately as possible. This name may be presented to the user as accurately as possible. This name may be presented to the user
@ -731,10 +728,10 @@
1920x1080 region to represent a 4K monitor and transparently map input 1920x1080 region to represent a 4K monitor and transparently map input
events into the respective true pixels. events into the respective true pixels.
Absolute devices may have different regions, it is up to the libei client Absolute devices may have different regions, it is up to the client to
to send events through the correct device to target the right pixel. For 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 my have two absolute devices, the first with
zero offset region spanning the left screen, the second with a nonzero a zero offset region spanning the left screen, the second with a nonzero
offset spanning the right screen. offset spanning the right screen.
The physical scale denotes a constant multiplication factor that needs to be applied to The physical scale denotes a constant multiplication factor that needs to be applied to