306 lines
9.1 KiB
Plaintext
306 lines
9.1 KiB
Plaintext
IPC interface (interprocess communication)
|
||
==========================================
|
||
Michael Stapelberg <michael+i3@stapelberg.de>
|
||
March 2010
|
||
|
||
This document describes how to interface with i3 from a separate process. This
|
||
is useful for example to remote-control i3 (to write test cases for example) or
|
||
to get various information like the current workspaces to implement an external
|
||
workspace bar.
|
||
|
||
The method of choice for IPC in our case is a unix socket because it has very
|
||
little overhead on both sides and is usually available without headaches in
|
||
most languages. In the default configuration file, no ipc-socket path is
|
||
specified and thus no socket is created. Alternatively you can set the
|
||
environment-variable +I3SOCK+. Setting a path in the configfile will override
|
||
+I3SOCK+.
|
||
|
||
+i3-msg+ and +i3-input+ will use +I3SOCK+ to connect to i3, unless -s is passed.
|
||
If neither is given, they will default to +/tmp/i3-ipc.sock+.
|
||
|
||
== Establishing a connection
|
||
|
||
To establish a connection, simply open the IPC socket. The following code
|
||
snippet illustrates this in Perl:
|
||
|
||
-------------------------------------------------------------
|
||
use IO::Socket::UNIX;
|
||
my $sock = IO::Socket::UNIX->new(Peer => '/tmp/i3-ipc.sock');
|
||
-------------------------------------------------------------
|
||
|
||
== Sending messages to i3
|
||
|
||
To send a message to i3, you have to format in the binary message format which
|
||
i3 expects. This format specifies a magic string in the beginning to ensure
|
||
the integrity of messages (to prevent follow-up errors). Following the magic
|
||
string comes the length of the payload of the message as 32-bit integer, and
|
||
the type of the message as 32-bit integer (the integers are not converted, so
|
||
they are in native byte order).
|
||
|
||
The magic string currently is "i3-ipc" and will only be changed when a change
|
||
in the IPC API is done which breaks compatibility (we hope that we don’t need
|
||
to do that).
|
||
|
||
Currently implemented message types are the following:
|
||
|
||
COMMAND (0)::
|
||
The payload of the message is a command for i3 (like the commands you
|
||
can bind to keys in the configuration file) and will be executed
|
||
directly after receiving it. There is no reply to this message.
|
||
GET_WORKSPACES (1)::
|
||
Gets the current workspaces. The reply will be a JSON-encoded list of
|
||
workspaces (see the reply section).
|
||
SUBSCRIBE (2)::
|
||
Subscribes your connection to certain events. See <<events>> for a
|
||
description of this message and the concept of events.
|
||
GET_OUTPUTS (3)::
|
||
Gets the current outputs. The reply will be a JSON-encoded list of outputs
|
||
(see the reply section).
|
||
|
||
So, a typical message could look like this:
|
||
--------------------------------------------------
|
||
"i3-ipc" <message length> <message type> <payload>
|
||
--------------------------------------------------
|
||
|
||
Or, as a hexdump:
|
||
------------------------------------------------------------------------------
|
||
00000000 69 33 2d 69 70 63 04 00 00 00 00 00 00 00 65 78 |i3-ipc........ex|
|
||
00000010 69 74 0a |it.|
|
||
------------------------------------------------------------------------------
|
||
|
||
To generate and send such a message, you could use the following code in Perl:
|
||
------------------------------------------------------------
|
||
sub format_ipc_command {
|
||
my ($msg) = @_;
|
||
my $len;
|
||
# Get the real byte count (vs. amount of characters)
|
||
{ use bytes; $len = length($msg); }
|
||
return "i3-ipc" . pack("LL", $len, 0) . $msg;
|
||
}
|
||
|
||
$sock->write(format_ipc_command("exit"));
|
||
------------------------------------------------------------------------------
|
||
|
||
== Receiving replies from i3
|
||
|
||
Replies from i3 usually consist of a simple string (the length of the string
|
||
is the message_length, so you can consider them length-prefixed) which in turn
|
||
contain the JSON serialization of a data structure. For example, the
|
||
GET_WORKSPACES message returns an array of workspaces (each workspace is a map
|
||
with certain attributes).
|
||
|
||
=== Reply format
|
||
|
||
The reply format is identical to the normal message format. There also is
|
||
the magic string, then the message length, then the message type and the
|
||
payload.
|
||
|
||
The following reply types are implemented:
|
||
|
||
COMMAND (0)::
|
||
Confirmation/Error code for the COMMAND message.
|
||
GET_WORKSPACES (1)::
|
||
Reply to the GET_WORKSPACES message.
|
||
SUBSCRIBE (2)::
|
||
Confirmation/Error code for the SUBSCRIBE message.
|
||
GET_OUTPUTS (3)::
|
||
Reply to the GET_OUTPUTS message.
|
||
|
||
=== COMMAND reply
|
||
|
||
The reply consists of a single serialized map. At the moment, the only
|
||
property is +success (bool)+, but this will be expanded in future versions.
|
||
|
||
*Example:*
|
||
-------------------
|
||
{ "success": true }
|
||
-------------------
|
||
|
||
=== GET_WORKSPACES reply
|
||
|
||
The reply consists of a serialized list of workspaces. Each workspace has the
|
||
following properties:
|
||
|
||
num (integer)::
|
||
The logical number of the workspace. Corresponds to the command
|
||
to switch to this workspace.
|
||
name (string)::
|
||
The name of this workspace (by default num+1), as changed by the
|
||
user. Encoded in UTF-8.
|
||
visible (boolean)::
|
||
Whether this workspace is currently visible on an output (multiple
|
||
workspaces can be visible at the same time).
|
||
focused (boolean)::
|
||
Whether this workspace currently has the focus (only one workspace
|
||
can have the focus at the same time).
|
||
urgent (boolean)::
|
||
Whether a window on this workspace has the "urgent" flag set.
|
||
rect (map)::
|
||
The rectangle of this workspace (equals the rect of the output it
|
||
is on), consists of x, y, width, height.
|
||
output (string)::
|
||
The video output this workspace is on (LVDS1, VGA1, …).
|
||
|
||
*Example:*
|
||
-------------------
|
||
[
|
||
{
|
||
"num": 0,
|
||
"name": "1",
|
||
"visible": true,
|
||
"focused": true,
|
||
"urgent": false,
|
||
"rect": {
|
||
"x": 0,
|
||
"y": 0,
|
||
"width": 1280,
|
||
"height": 800
|
||
},
|
||
"output": "LVDS1"
|
||
},
|
||
{
|
||
"num": 1,
|
||
"name": "2",
|
||
"visible": false,
|
||
"focused": false,
|
||
"urgent": false,
|
||
"rect": {
|
||
"x": 0,
|
||
"y": 0,
|
||
"width": 1280,
|
||
"height": 800
|
||
},
|
||
"output": "LVDS1"
|
||
}
|
||
]
|
||
-------------------
|
||
|
||
=== SUBSCRIBE reply
|
||
|
||
The reply consists of a single serialized map. The only property is
|
||
+success (bool)+, indicating whether the subscription was successful (the
|
||
default) or whether a JSON parse error occurred.
|
||
|
||
*Example:*
|
||
-------------------
|
||
{ "success": true }
|
||
-------------------
|
||
|
||
=== GET_OUTPUTS reply
|
||
|
||
The reply consists of a serialized list of outputs. Each output has the
|
||
following properties:
|
||
|
||
name (string)::
|
||
The name of this output (as seen in +xrandr(1)+). Encoded in UTF-8.
|
||
active (boolean)::
|
||
Whether this output is currently active (has a valid mode).
|
||
current_workspace (integer)::
|
||
The current workspace which is visible on this output. +null+ if the
|
||
output is not active.
|
||
rect (map)::
|
||
The rectangle of this output (equals the rect of the output it
|
||
is on), consists of x, y, width, height.
|
||
|
||
*Example:*
|
||
-------------------
|
||
[
|
||
{
|
||
"name": "LVDS1",
|
||
"active": true,
|
||
"current_workspace": 4,
|
||
"rect": {
|
||
"x": 0,
|
||
"y": 0,
|
||
"width": 1280,
|
||
"height": 800
|
||
}
|
||
},
|
||
{
|
||
"name": "VGA1",
|
||
"active": true,
|
||
"current_workspace": 1,
|
||
"rect": {
|
||
"x": 1280,
|
||
"y": 0,
|
||
"width": 1280,
|
||
"height": 1024
|
||
},
|
||
}
|
||
]
|
||
-------------------
|
||
|
||
== Events
|
||
|
||
[[events]]
|
||
|
||
To get informed when certain things happen in i3, clients can subscribe to
|
||
events. Events consist of a name (like "workspace") and an event reply type
|
||
(like I3_IPC_EVENT_WORKSPACE). The events sent by i3 are in the same format
|
||
as replies to specific commands.
|
||
|
||
Caveat: As soon as you subscribe to an event, it is not guaranteed any longer
|
||
that the requests to i3 are processed in order. This means, the following
|
||
situation can happen: You send a GET_WORKSPACES request but you receive a
|
||
"workspace" event before receiving the reply to GET_WORKSPACES. If your
|
||
program does not want to cope which such kinds of race conditions (an
|
||
event based library may not have a problem here), I suggest you create a
|
||
separate connection to receive events.
|
||
|
||
=== Subscribing to events
|
||
|
||
By sending a message of type SUBSCRIBE with a JSON-encoded array as payload
|
||
you can register to an event.
|
||
|
||
*Example:*
|
||
---------------------------------
|
||
type: SUBSCRIBE
|
||
payload: [ "workspace", "focus" ]
|
||
---------------------------------
|
||
|
||
=== Available events
|
||
|
||
workspace::
|
||
Sent when the user switches to a different workspace, when a new
|
||
workspace is initialized or when a workspace is removed (because the
|
||
last client vanished).
|
||
output::
|
||
Sent when RandR issues a change notification (of either screens,
|
||
outputs, CRTCs or output properties).
|
||
|
||
=== workspace event
|
||
|
||
This event consists of a single serialized map containing a property
|
||
+change (string)+ which indicates the type of the change ("focus", "init",
|
||
"empty", "urgent").
|
||
|
||
*Example:*
|
||
---------------------
|
||
{ "change": "focus" }
|
||
---------------------
|
||
|
||
=== output event
|
||
|
||
This event consists of a single serialized map containing a property
|
||
+change (string)+ which indicates the type of the change (currently only
|
||
"unspecified").
|
||
|
||
*Example:*
|
||
---------------------------
|
||
{ "change": "unspecified" }
|
||
---------------------------
|
||
|
||
== See also
|
||
|
||
For some languages, libraries are available (so you don’t have to implement
|
||
all this on your own). This list names some (if you wrote one, please let me
|
||
know):
|
||
|
||
C::
|
||
i3 includes a headerfile +i3/ipc.h+ which provides you all constants.
|
||
However, there is no library yet.
|
||
Ruby::
|
||
http://github.com/badboy/i3-ipc
|
||
Perl::
|
||
http://search.cpan.org/search?query=AnyEvent::I3
|