fdo-mirrors/libei
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/libinput/libei.git synced 2025-12-20 06:50:06 +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>
<enum name="context_type" since="1">
<description summary="context type">
This enum denotes context types for the libei context.
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 summary="context types for connections">
Context types for connections. The context type for a connection is set
once in the ei_handshake.context_type request.
</description>
<entry name="receiver" value="1" summary="this client receives events from the EIS implementation"/>
<entry name="sender" value="2" summary="this client sends events to the EIS implementation"/>
<entry name="receiver" value="1" summary="the client receives input events from the server"/>
<entry name="sender" value="2" summary="the client sends input events to the server"/>
</enum>
<request name="context_type" since="1">
<description summary="context type request">
Notify the EIS implementation of the type of this context. The context types
defines whether the client will send events to or receive events from the
EIS implementation.
<description summary="context type notification">
Notify the EIS implementation of the type of this context. The context
type defines whether the client will send input events to the server or
receive input events from it.
Depending on the context type, certain requests must not be used and some
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
ei_handshake.finish.
</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 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
human-presentable UTF-8 string and should represent the client name
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
events into the respective true pixels.
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
zero offset region spanning the left screen, the second with a nonzero
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
a zero offset region spanning the left screen, the second with a nonzero
offset spanning the right screen.
The physical scale denotes a constant multiplication factor that needs to be applied to