<h1>IPC interface (interprocess communication)</h1>\r
<span id="author">Michael Stapelberg</span><br />\r
<span id="email"><tt><<a href="mailto:michael@i3wm.org">michael@i3wm.org</a>></tt></span><br />\r
-<span id="revdate">October 2014</span>\r
+<span id="revdate">September 2017</span>\r
<div id="toc">
<div id="toctitle">Table of Contents</div>
<noscript><p><b>JavaScript must be enabled in your browser to display the table of contents.</b></p></noscript>
<div class="paragraph"><p>The magic string currently is "i3-ipc" and will only be changed when a change\r
in the IPC API is done which breaks compatibility (we hope that we don’t need\r
to do that).</p></div>\r
-<div class="paragraph"><p>Currently implemented message types are the following:</p></div>\r
-<div class="dlist"><dl>\r
-<dt class="hdlist1">\r
-COMMAND (0)\r
-</dt>\r
-<dd>\r
-<p>\r
- The payload of the message is a command for i3 (like the commands you\r
- can bind to keys in the configuration file) and will be executed\r
- directly after receiving it.\r
-</p>\r
-</dd>\r
-<dt class="hdlist1">\r
-GET_WORKSPACES (1)\r
-</dt>\r
-<dd>\r
-<p>\r
- Gets the current workspaces. The reply will be a JSON-encoded list of\r
- workspaces (see the reply section).\r
-</p>\r
-</dd>\r
-<dt class="hdlist1">\r
-SUBSCRIBE (2)\r
-</dt>\r
-<dd>\r
-<p>\r
- Subscribes your connection to certain events. See <a href="#events">[events]</a> for a\r
- description of this message and the concept of events.\r
-</p>\r
-</dd>\r
-<dt class="hdlist1">\r
-GET_OUTPUTS (3)\r
-</dt>\r
-<dd>\r
-<p>\r
- Gets the current outputs. The reply will be a JSON-encoded list of outputs\r
- (see the reply section).\r
-</p>\r
-</dd>\r
-<dt class="hdlist1">\r
-GET_TREE (4)\r
-</dt>\r
-<dd>\r
-<p>\r
- Gets the layout tree. i3 uses a tree as data structure which includes\r
- every container. The reply will be the JSON-encoded tree (see the reply\r
- section).\r
-</p>\r
-</dd>\r
-<dt class="hdlist1">\r
-GET_MARKS (5)\r
-</dt>\r
-<dd>\r
-<p>\r
- Gets a list of marks (identifiers for containers to easily jump to them\r
- later). The reply will be a JSON-encoded list of window marks (see\r
- reply section).\r
-</p>\r
-</dd>\r
-<dt class="hdlist1">\r
-GET_BAR_CONFIG (6)\r
-</dt>\r
-<dd>\r
-<p>\r
- Gets the configuration (as JSON map) of the workspace bar with the\r
- given ID. If no ID is provided, an array with all configured bar IDs is\r
- returned instead.\r
-</p>\r
-</dd>\r
-<dt class="hdlist1">\r
-GET_VERSION (7)\r
-</dt>\r
-<dd>\r
-<p>\r
- Gets the version of i3. The reply will be a JSON-encoded dictionary\r
- with the major, minor, patch and human-readable version.\r
-</p>\r
-</dd>\r
-<dt class="hdlist1">\r
-GET_BINDING_MODES (8)\r
-</dt>\r
-<dd>\r
-<p>\r
- Gets a list of currently configured binding modes.\r
-</p>\r
-</dd>\r
-</dl></div>\r
+<div class="tableblock">\r
+<table rules="all"\r
+width="100%"\r
+frame="border"\r
+cellspacing="0" cellpadding="4">\r
+<caption class="title">Table 1. Currently implemented message types</caption>\r
+<col width="10%" />\r
+<col width="20%" />\r
+<col width="20%" />\r
+<col width="50%" />\r
+<thead>\r
+<tr>\r
+<th align="center" valign="top"> Type (numeric) </th>\r
+<th align="center" valign="top"> Type (name) </th>\r
+<th align="center" valign="top"> Reply type </th>\r
+<th align="center" valign="top"> Purpose</th>\r
+</tr>\r
+</thead>\r
+<tbody>\r
+<tr>\r
+<td align="center" valign="top"><p class="table">0</p></td>\r
+<td align="center" valign="top"><p class="table"><tt>RUN_COMMAND</tt></p></td>\r
+<td align="center" valign="top"><p class="table"><a href="#_command_reply">COMMAND</a></p></td>\r
+<td align="center" valign="top"><p class="table">Run the payload as an i3 command (like the commands you can bind to keys).</p></td>\r
+</tr>\r
+<tr>\r
+<td align="center" valign="top"><p class="table">1</p></td>\r
+<td align="center" valign="top"><p class="table"><tt>GET_WORKSPACES</tt></p></td>\r
+<td align="center" valign="top"><p class="table"><a href="#_workspaces_reply">WORKSPACES</a></p></td>\r
+<td align="center" valign="top"><p class="table">Get the list of current workspaces.</p></td>\r
+</tr>\r
+<tr>\r
+<td align="center" valign="top"><p class="table">2</p></td>\r
+<td align="center" valign="top"><p class="table"><tt>SUBSCRIBE</tt></p></td>\r
+<td align="center" valign="top"><p class="table"><a href="#_subscribe_reply">SUBSCRIBE</a></p></td>\r
+<td align="center" valign="top"><p class="table">Subscribe this IPC connection to the event types specified in the message payload. See <a href="#events">[events]</a>.</p></td>\r
+</tr>\r
+<tr>\r
+<td align="center" valign="top"><p class="table">3</p></td>\r
+<td align="center" valign="top"><p class="table"><tt>GET_OUTPUTS</tt></p></td>\r
+<td align="center" valign="top"><p class="table"><a href="#_outputs_reply">OUTPUTS</a></p></td>\r
+<td align="center" valign="top"><p class="table">Get the list of current outputs.</p></td>\r
+</tr>\r
+<tr>\r
+<td align="center" valign="top"><p class="table">4</p></td>\r
+<td align="center" valign="top"><p class="table"><tt>GET_TREE</tt></p></td>\r
+<td align="center" valign="top"><p class="table"><a href="#_tree_reply">TREE</a></p></td>\r
+<td align="center" valign="top"><p class="table">Get the i3 layout tree.</p></td>\r
+</tr>\r
+<tr>\r
+<td align="center" valign="top"><p class="table">5</p></td>\r
+<td align="center" valign="top"><p class="table"><tt>GET_MARKS</tt></p></td>\r
+<td align="center" valign="top"><p class="table"><a href="#_marks_reply">MARKS</a></p></td>\r
+<td align="center" valign="top"><p class="table">Gets the names of all currently set marks.</p></td>\r
+</tr>\r
+<tr>\r
+<td align="center" valign="top"><p class="table">6</p></td>\r
+<td align="center" valign="top"><p class="table"><tt>GET_BAR_CONFIG</tt></p></td>\r
+<td align="center" valign="top"><p class="table"><a href="#_bar_config_reply">BAR_CONFIG</a></p></td>\r
+<td align="center" valign="top"><p class="table">Gets the specified bar configuration or the names of all bar configurations if payload is empty.</p></td>\r
+</tr>\r
+<tr>\r
+<td align="center" valign="top"><p class="table">7</p></td>\r
+<td align="center" valign="top"><p class="table"><tt>GET_VERSION</tt></p></td>\r
+<td align="center" valign="top"><p class="table"><a href="#_version_reply">VERSION</a></p></td>\r
+<td align="center" valign="top"><p class="table">Gets the i3 version.</p></td>\r
+</tr>\r
+<tr>\r
+<td align="center" valign="top"><p class="table">8</p></td>\r
+<td align="center" valign="top"><p class="table"><tt>GET_BINDING_MODES</tt></p></td>\r
+<td align="center" valign="top"><p class="table"><a href="#_binding_modes_reply">BINDING_MODES</a></p></td>\r
+<td align="center" valign="top"><p class="table">Gets the names of all currently configured binding modes.</p></td>\r
+</tr>\r
+<tr>\r
+<td align="center" valign="top"><p class="table">9</p></td>\r
+<td align="center" valign="top"><p class="table"><tt>GET_CONFIG</tt></p></td>\r
+<td align="center" valign="top"><p class="table"><a href="#_config_reply">CONFIG</a></p></td>\r
+<td align="center" valign="top"><p class="table">Returns the last loaded i3 config.</p></td>\r
+</tr>\r
+</tbody>\r
+</table>\r
+</div>\r
<div class="paragraph"><p>So, a typical message could look like this:</p></div>\r
<div class="listingblock">\r
<div class="content">\r
</dt>\r
<dd>\r
<p>\r
- Confirmation/Error code for the COMMAND message.\r
+ Confirmation/Error code for the RUN_COMMAND message.\r
</p>\r
</dd>\r
<dt class="hdlist1">\r
Reply to the GET_BINDING_MODES message.\r
</p>\r
</dd>\r
+<dt class="hdlist1">\r
+GET_CONFIG (9)\r
+</dt>\r
+<dd>\r
+<p>\r
+ Reply to the GET_CONFIG message.\r
+</p>\r
+</dd>\r
</dl></div>\r
</div>\r
<div class="sect2">\r
</dt>\r
<dd>\r
<p>\r
- Whether this container (window or workspace) has the urgency hint set.\r
+ Whether this container (window, split container, floating container or\r
+ workspace) has the urgency hint set, directly or indirectly. All parent\r
+ containers up until the workspace container will be marked urgent if they\r
+ have at least one urgent child.\r
</p>\r
</dd>\r
<dt class="hdlist1">\r
Whether this container is currently focused.\r
</p>\r
</dd>\r
+<dt class="hdlist1">\r
+focus (array of integer)\r
+</dt>\r
+<dd>\r
+<p>\r
+ List of child node IDs (see <tt>nodes</tt>, <tt>floating_nodes</tt> and <tt>id</tt>) in focus\r
+ order. Traversing the tree by following the first entry in this array\r
+ will result in eventually reaching the one node with <tt>focused</tt> set to\r
+ true.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+nodes (array of node)\r
+</dt>\r
+<dd>\r
+<p>\r
+ The tiling (i.e. non-floating) child containers of this node.\r
+</p>\r
+</dd>\r
+<dt class="hdlist1">\r
+floating_nodes (array of node)\r
+</dt>\r
+<dd>\r
+<p>\r
+ The floating child containers of this node. Only non-empty on nodes with\r
+ type <tt>workspace</tt>.\r
+</p>\r
+</dd>\r
</dl></div>\r
<div class="paragraph"><p>Please note that in the following example, I have left out some keys/values\r
which are not relevant for the type of the node. Otherwise, the example would\r
<pre><tt>["default", "resize"]</tt></pre>\r
</div></div>\r
</div>\r
+<div class="sect2">\r
+<h3 id="_config_reply">3.11. CONFIG reply</h3>\r
+<div class="paragraph"><p>The config reply is a map which currently only contains the "config" member,\r
+which is a string containing the config file as loaded by i3 most recently.</p></div>\r
+<div class="paragraph"><p><strong>Example:</strong></p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>{ "config": "font pango:monospace 8\nbindsym Mod4+q exit\n" }</tt></pre>\r
+</div></div>\r
+</div>\r
</div>\r
</div>\r
<div class="sect1">\r
</li>\r
<li>\r
<p>\r
+<a href="https://github.com/Ceryn/i3msg-python">https://github.com/Ceryn/i3msg-python</a>\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
<a href="https://github.com/whitelynx/i3ipc">https://github.com/whitelynx/i3ipc</a> (not maintained)\r
</p>\r
</li>\r
</dl></div>\r
</div>\r
</div>\r
+<div class="sect1">\r
+<h2 id="_appendix_a_detecting_byte_order_in_memory_safe_languages">6. Appendix A: Detecting byte order in memory-safe languages</h2>\r
+<div class="sectionbody">\r
+<div class="paragraph"><p>Some programming languages such as Go don’t offer a way to serialize data in the\r
+native byte order of the machine they’re running on without resorting to tricks\r
+involving the <tt>unsafe</tt> package.</p></div>\r
+<div class="paragraph"><p>The following technique can be used (and will not be broken by changes to i3) to\r
+detect the byte order i3 is using:</p></div>\r
+<div class="olist arabic"><ol class="arabic">\r
+<li>\r
+<p>\r
+The byte order dependent fields of an IPC message are message type and\r
+ payload length.\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+The message type <tt>RUN_COMMAND</tt> (0) is the same in big and little endian, so\r
+ we can use it in either byte order to elicit a reply from i3.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+The payload length 65536 + 256 (<tt>0x00 01 01 00</tt>) is the same in big and\r
+ little endian, and also small enough to not worry about memory allocations\r
+ of that size. We must use payloads of length 65536 + 256 in every message\r
+ we send, so that i3 will be able to read the entire message regardless of\r
+ the byte order it uses.\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+<li>\r
+<p>\r
+Send a big endian encoded message of type <tt>SUBSCRIBE</tt> (2) with payload <tt>[]</tt>\r
+ followed by 65536 + 256 - 2 <tt>SPACE</tt> (ASCII 0x20) bytes.\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+If i3 is running in big endian, this message is treated as a noop,\r
+ resulting in a <tt>SUBSCRIBE</tt> reply with payload <tt>{"success":true}</tt>\r
+ <span class="footnote"><br />[A small payload is important: that way, we circumvent dealing\r
+ with UNIX domain socket buffer sizes, whose size depends on the\r
+ implementation/operating system. Exhausting such a buffer results in an i3\r
+ deadlock unless you concurrently read and write, which — depending on the\r
+ programming language — makes the technique much more complicated.]<br /></span>.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+If i3 is running in little endian, this message is read in its entirety due\r
+ to the byte order independent payload length, then\r
+ <a href="https://github.com/i3/i3/blob/d726d09d496577d1c337a4b97486f2c9fbc914f1/src/ipc.c#L1188">silently\r
+ discarded</a> due to the unknown message type.\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+<li>\r
+<p>\r
+Send a byte order independent message, i.e. type <tt>RUN_COMMAND</tt> (0) with\r
+ payload <tt>nop byte order detection. padding:</tt>, padded to 65536 + 256 bytes\r
+ with <tt>a</tt> (ASCII 0x61) bytes. i3 will reply to this message with a reply of\r
+ type <tt>COMMAND</tt> (0).\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+The human-readable prefix is in there to not confuse readers of the i3 log.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+This messages serves as a synchronization primitive so that we know whether\r
+ i3 discarded the <tt>SUBSCRIBE</tt> message or didn’t answer it yet.\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+<li>\r
+<p>\r
+Receive a message header from i3, decoding the message type as big endian.\r
+</p>\r
+<div class="ulist"><ul>\r
+<li>\r
+<p>\r
+If the message’s reply type is <tt>COMMAND</tt> (0), i3 is running in little\r
+ endian (because the <tt>SUBSCRIBE</tt> message was discarded). Decode the message\r
+ payload length as little endian, receive the message payload.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+If the message’s reply type is anything else, i3 is running in big endian\r
+ (because our big endian encoded <tt>SUBSCRIBE</tt> message was answered). Decode\r
+ the message payload length in big endian, receive the message\r
+ payload. Then, receive the pending <tt>COMMAND</tt> message reply in big endian.\r
+</p>\r
+</li>\r
+</ul></div>\r
+</li>\r
+<li>\r
+<p>\r
+From here on out, send/receive all messages using the detected byte order.\r
+</p>\r
+</li>\r
+</ol></div>\r
+</div>\r
+</div>\r
</div>\r
<div id="footnotes"><hr /></div>\r
<div id="footer" lang="de">\r
projects / i3 / i3.github.io / blobdiff