\input texinfo   @c -*-texinfo-*-

@c %**start of header
@setfilename mds.info
@settitle mds
@afourpaper
@documentencoding UTF-8
@documentlanguage en
@finalout
@c %**end of header


@dircategory Graphics environment
@direntry
* mds: (mds).                        The micro-display server
@end direntry


@copying
Copyright @copyright{} 2014 Mattias Andrée

@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
``GNU Free Documentation License''.
@end quotation
@end copying

@ifnottex
@node Top
@top mds -- The micro-display server
@insertcopying
@end ifnottex

@titlepage
@title mds
@subtitle The micro-display server
@author by Mattias Andrée (maandree)

@page
@c @center `'
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@contents



@menu
* Overview::                        Brief overview of @command{mds}.
* Architecture::                    Architectural overview of @command{mds}.
* Protocol::                        The @command{mds} procotol.
* Utilities::                       About @command{mds} utilities.
* Servers::                         About @command{mds} servers.
* libmdsserver::                    Overview of @command{libmdsserver}.
* mds-base::                        Overview of @command{mds-base}.
* GNU Free Documentation License::  Copying and sharing this manual.
@end menu



@node Overview
@chapter Overview

@command{mds}@footnote{mds stands for micro-display server}
is a display server protocol and an implementation of said
protocol. What makes @command{mds} stand out is its core
design choice: it is desigend just like a microkernel.
Rather than one, possibly modular, process --- a monolithic
process --- mds is comprised of many small servers, each
exchangable and responsible for one thing.

@command{mds} goal is neither security, performance nor
a perfect graphical experience. @command{mds} is all
about flexibility and freedom 0@footnote{The freedom to run
the program as you wish, for any purpose}.

The reason for having a display server architectured as a
microkernel is so that components can be added, remove
and replaced online. Additionally, the message passing
between the servers makes it easy to design a system that
lets you make clients that can listen on messages between
the servers and perhaps modify them. This enables you to
do so much more with your display server. Moreover, if
a single part of the system crashes it does not bring down
the whole system, and the crashed server can be respawned
with minor side effects. @command{mds} is architectured
in three layers: a microkernel, a master server and a
collection of servers. And clients are actually located
on the same layer as the servers, because there is no
actual difference, the only thing that separates a server
from a client is for what purpose you run it. @command{mds}'s
kernel is a minimal program that do initialisation of the
display, such as giving it an index and create runtime
files and directories for servers and other programs
to use. Then the kernel creates a domain socket for the
master server and spawns the master server and respawns
it if it crashes. Because of this, if the master server
crashes it will not lose its socket when it is respawned.
The master server than, on its initial spawn, starts
the all servers and other programs that the user have
choosen and then starts accepting connections to it and
coordinates messages between servers and clients. Further,
separating all components into separate processes enables
us to only give the servers the privileges they actually
need, rather than having one program with root privileges
that takes care of everything even things that do not do
require any privileges.

All @command{mds}'s servers, that is all running parts of
@command{mds} except the kernel, are designed so that they
can re-exec themself so that they can be updated online
without any side effects. Servers serialises their state,
saves it to RAM (in a directory created by the kernel),
re-exec themself and loads their serialised state. The
kernel cannot do this because when it has spawned the
master server it has no reason to re-exec, its only mission
is to respawn the master server it if would happen to crash.
It would technically be possible to enable the kernel to
re-exec but it is not worth it as it as no reason to
re-exec, and doing so puts the display server at risk
of crashing.



@node Architecture
@chapter Architecture

@menu
* Layers::                          The layers of the display server.
* Interprocess Communication::      How servers and clients communicate.
@end menu



@node Layers
@section Layers

The @command{mds} display server in architectured in
three layers. The first layer is called the kernel.
The kernel is responsible for acquiring a display
server index@footnote{As with any display server,
the system can have multiple instances of
@command{mds} running at the same time.}, set up
environment variables to indicate which display
server and display server instance is being used,
create a domain socket for the display server and
start the master server and restart it if it crashes,
and then clean up the system when the display server
closes. The kernel only responsible for creating
the domain socket for communication with the display
server, it is not responsible for using it, that
mission falls to the master server.

The second layer is the master server. The master
server has two responsibilities: coordinating
message passing between other servers and clients
@footnote{In @command{mds} their is no functional
distinction between servers and clients, the
distinction is purely semantic.} and starting
other servers.

The third layer is the other servers and clients.
protocolwise there is no specification on how
they are started. But in the reference
implementation of the master server, this is
done by starting a shell script with the
pathname @file{$@{XDG_CONFIG_HOME@}/mdsinitrc}
and the user is responsible for providing the
logic in that shell script.@footnote{Moonstruck
users are allowed to implement this in C
or any other language of their choosing.}
@c Which is better: cray-cray users, lunatic users,
@c moonstruck users, insane users, ballers, madmen,
@c loony tunes?
These servers implements the actual functionality
of the display server.



@node Interprocess Communication
@section Interprocess Communication

Intrinsic to @command{mds} is a powerful
interprocess communication mechanism. Servers
and clients connect to the display server by
connecting to a domain socket served by the
master server. A server or client that has
connected to the display server can do three
things:

@itemize
@item
Request assignment of a unique ID.

@item
Multicast a message.

@item
Join or leave a multicast groups.
@end itemize

Upon assignment of an ID the master server
will automatically place the client in a
multicast group for that specific client.
This automatically multicast group assignment
is done by the master server simply so you
as a debugger do not forget to do so. When
a client is disconnected it will and out a
message to a specific multicast group that
the client, refered to by it's ID, have closed.

A message in the @command{mds} protocol is
comprised of two parts: headers and a payload.
When a client joins a multicast group it is
actually say that it is interested and receiving
broadcasts containing a specific header or a
specific header--value pair, or that it is
interesting in all messages@footnote{This
could be used for logging, possibly spying and
networking.}. Thus a message is automatically
multicasted to groups indicated by its headers.

The multicast groups and receiving of groups
is called interceptions. The interesting
property of interceptions is that they may
be modifying. When a server registers for
message interception it can say that it wants
to be able to modify messages. If this is done
and the server receives a message for which it
has said it want to be able to modify it,
the master server will wait for that server
to respond before it send the message to
the next server in the interception list.
The server can choose to do three things
with a message that it has opted in for
modification of: leave the message as-is,
modify the message, or consume the message.
A message consumption is done by modify
the message to make it empty. A consumed
message will not be send to any further
clients or servers in the interception list.

To make this mechanism sensible, a server or
client can set a priority when it registers
for interception (does not need to be
modifying.) When a message is broadcasted it
will be received by all servers in the
interception except the original sender,
unless it gets consumes. The order in which
the master server sends the message to the
recipients is determined by priority the
servers registed with. The message first sent
to the recipients with highest priority and
last to the recipients with lowestr priority,
and orderd by the priority between those
priorities. Of two or more servers have the
same priority the order in which they will
receive the message, of those recipients,
is arbitrary.

An interesting property of this machanism
is demonstrated in the @command{mds-vt}
server. Unlike most servers @command{mds-vt}
maintains two concurrent connections to
the display. Once @command{mds-vt} receives
a signal from the OS kernel requesting to
switch virtual terminal, @command{mds-vt}
will from one of its connections send
out a message and wait for it to be
received in its other connection and the
let the OS kernel switch virtual terminal.
The secondary connection to the display
has registered interception with lower
priority of the message that the primary
connection broadcasts. This message will
be received by other servers that will
let the message continue to the next
server in the interception list once that
server is ready for the OS kernel to switch
virtual terminal. All of these server has
registered modifying interception of the
message but none will actually modify or
consume the message; it is only used a
mechanism for letting @command{mds-vt} know
when all servers are ready for the switch
without having to know how many they are
and wait for a reply from all of them.



@node Protocol
@chapter Protocol

@menu
* Environment Variables::           Identifying the active display server
* Signals::                         Signalling individual servers
* Filesystem::                      The display server's footprint on the filesystem
* Message Passing::                 Sending messages between servers and clients
* Interception::                    Implementing protocols and writing unanticipated clients
@end menu



@node Environment Variables
@section Environment Variables

A crucial of any display server is letting child
processes know which display server they should
connect to. @command{X.org} does by setting the
environment variable @env{DISPLAY} to
@code{<host>:<display index>}, where @code{<host>}
is empty if the display is one the local machine.
In this tradition @command{mds} does the same thing
with the environment variable @env{MDS_DISPLAY}.

@command{mds} also creates a new process group and
export the new process group ID to the environment
variable @command{MDS_PGROUP}. This process group
can be used to send signals to all @command{mds}
servers collectively.



@node Signals
@section Signals

@command{mds} servers can re-execute into an
updated version of their binary. This can be
used to update display server online after
a new version has been installed. To do this
send the signal @command{SIGUSR1} to the server
you want update. If a server does not support
online updating it will ignore this signal.
If the operating system defines a signal named
@command{SIGUPDATE}, this signal is used
instead of @command{SIGUSR1}.

If you need servers to free up allocated
memory that they do not use, send the signal
@command{SIGDANGER}, or if not defined
@command{SIGRTMAX}. Unimportant servers may
choose to die on @command{SIGDANGER}.



@node Filesystem
@section Filesystem

The @command{mds} kernel creates two directories
for the @command{mds} servers to use: one for
runtime data and one for temporary data.
These directories are named by
@code{MDS_RUNTIME_ROOT_DIRECTORY} and
@code{MDS_STORAGE_ROOT_DIRECTORY}, respectively,
by the header file @file{<libmdsserver/config.h>}.
If the systems runtime data directory is @file{/run}
and transient temporary data directory is @file{/tmp},
and the package name of @command{mds} is @command{mds},
these directories will be @file{/run/mds} and
@file{/tmp/.@{system-directory@}.mds}, respectively.
In @file{/tmp/.@{system-directory@}.mds} the kernel
will create a directory for the display server instance
named @file{.data} prefixed by the display server index.
For example if the display server index is zero,
temporary data may be stored in
@file{/tmp/.@{system-directory@}.mds/0.data}

As defined by @code{SHM_PATH_PATTERN} by
@file{<libmdsserver/config.h>}, when a server
re-executes itself it will marshal its state to
the POSIX shared memory unit named
@file{/.proc-pid-%ji}, where @file{%ji}
@footnote{@code{%ji} is the pattern in @code{*printf}
functions for the data type @code{intmax_t}.} is
replaced with the process ID of the server. This
file will be bound to the pathname
@file{/dev/shm/.proc-pid-%ji} if POSIX shared
memory is stored in @file{/dev/shm} by the
operating system.

In @code{MDS_RUNTIME_ROOT_DIRECTORY} the kernel
will create two files. @file{.pid} and @file{.socket},
both prefixed with the display server index
@footnote{@file{0.pid} and @file{0.socket} if
the display server index is 0.}. The @file{.pid}
file contains the process ID of the display server
and is used by the kernel to figure out whether
an display server index is still in use or just
not properly cleaned up. Of course it can be used
by any program to find the process ID of the
kernel process of a display server instance.
The @file{.socket} is the domain socket used
for communication with the display server and
its servers and clients.



@node Message Passing
@section Message Passing

Message passing over domain sockets is the
underlaying technique for communicating with
the display server. To communicate with the
display server in the local machine a process
must connect to the domain socket created by
the display server kernel as named in
@ref{Filesystem}.

Clients should request a unique ID when it
connects to the display server.@footnote{There
is seldom a reason for servers to do this.}
To do this the client sends

@example
Command: assign-id\n
Message ID: 0\n
\n
@end example

where @code{\n} is an LF-line break.
The value on the @code{Message ID} line
does not need to be 0, but servers and
clients often start with 0 and count
upwards. The value is however bound to
an unsigned 32-bit integer. All message
must contain this @code{Message ID} header,
otherwise the message is considered corrupt
and is ignored.

The empty line signifies the end of the
header list, and in this case the end of
the message. But a message may contain
payload beneath this empty line. To
include a payload, add the header
@code{Length} that says how many bytes
the payload is comprised of.

A header must contain a header name and
header value without any trailing or
leading spaces, and `: ' (colon, one
regular blank space) exactly delimits
the name and the value.

When the master server receives this
@code{Command: assign-id} message it
will assign the client a unique ID
and send it to the client.@footnote{The
master server is the only server than
can address the client uniquely before
it has an ID, so this part can only
be implement in the master server.}
If the client already has an ID, it
will send back that ID to the client.
This response consists of two headers
@code{ID assignment} and @code{In
response to}, containing the client's
new (or possibly already assigned) ID
and the value that was in the
@code{Message ID} header, respectively.
For example:

@example
ID assignment: 0:1\n
In response to: 0\n
\n
@end example

Notice that the master server never
includes @code{Message ID} in message
originating from it.

As seen in this example, the client ID
consists of two integers delimited by
a colon (`:'). Both of these integers
are unsigned 32-bit integers. This is
done this way because unsigned 64-bit
integers are forbidden because it is
not supportable natively be some
programming languages.

Before a has gotten a unique client ID
assigned to it, it will be `0:0'.

If a client gets disconnected from the
master server, the master server will
sends out a signal header message.
This header will be @code{Client closed}
and contain ID of the client that closed.
For example:

@example
Client closed: 0:1\n
\n
@end example

Be aware that if a server or client
closes and does not have a unique client
ID, this message will be:

@example
Client closed: 0:0\n
\n
@end example

Once a client has an unique client ID
assigned to it, it should always include
the header @code{Client ID} in its
messages. The value of @code{Client ID}
should be the client's ID. If a server
wants to address this client, it should
include the header @code{To} with the
value set to the recipient's client ID.
Be aware that such message may not be
sent to that recipient uniquely, any
server or client is free to sign up
for receive of such message, any messages
or message contain any other header or
header--value pair that may also be
included in the header.



@node Interception
@section Interception

As discussed in @ref{Interprocess Communication},
interception in the primary feature of
@command{mds}'s message passing system.
Not only does it enable servers to select
which message it wants to receive in order
to provide it's service. It also enables
clients to do anything, things that was
never anticipated. As an exaple of its
power, @command{mds} does not provide any
protocol for taking screenshots or recording
a session. Instead, a screenshot application
signs up for messages pass between the
compositor and presentation servers, and
simply requests that the compositor resends
the screen, a feature intended for the
presentation servers. A screen recoding
application would do the same and just
hang on and record all message passed
between the servers.

If you want your server or client to
receive all messages passed around in
the display server, simply sign up for
all messages:

@example
Command: intercept\n
Message ID: 0\n
\n
@end example

But if you only want messages contain
the header @code{Command}, include
that header in the payload of the message:

@example
Command: intercept\n
Message ID: 0\n
Length: 8\n
\n
Command\n
@end example

It is allowed to include multiple headers.
You can also be more strict, and require
a specific value for a header, for example:

@example
Command: intercept\n
Message ID: 0\n
Length: 16\n
\n
Command: get-vt\n
@end example

You may mix these two types of requirements
freely. Your client will receive any message
that satisfies at least one of the requirements,
these requirements may be split into multiple
message or coalesced into one message; but
you cannot request to include receive a message
if multiple requirements are satisfied.

Alternatively you can choose to stop receiving
message that satisfies requirements. For example:

@example
Command: intercept\n
Stop: yes\n
Message ID: 1\n
Length: 16\n
\n
Command: get-vt\n
@end example

Or stop receiving all messages:

@example
Command: intercept\n
Stop: yes\n
Message ID: 1\n
\n
@end example

Note that this will stop you from receiving
messages contain the @code{To} header addressed
to you until you request to receiving such
messages again.

When you sign up for message you may request
to be able to modify them before that are
send to the next client in the list of client
that should receive them. To do this include
the header--value pair @code{Modifying: yes}:

@example
Command: intercept\n
Modifying: yes\n
Message ID: 0\n
Length: 30\n
\n
Command: keyboard-enumeration\n
@end example

It is up to the client to keep track of
which message that it may modify. When
you receive a message that you can modify
you must respond when you are done with
the message.

For example, if you have signed up
for @code{Command: keyboard-enumeration}
with the ability to modify such messages
and the message

@example
Command: keyboard-enumeration\n
To: 0:1\n
In response to: 2\n
Message ID: 1\n
Length: 7\n
\n
kernel\n
@end example

is send from a server, you may receive
it as

@example
Command: keyboard-enumeration\n
To: 0:1\n
In response to: 2\n
Message ID: 1\n
Length: 7\n
Modify ID: 4\n
\n
kernel\n
@end example

Be aware that the @code{Modify ID} may
be included even if you have not signed
up to be able to modify the message,
it is enough that one client before you
has or it was originally included
@footnote{You may however not include
this header when you send out an
orginal message}.

If you receive the message as such
and want to add the line
@code{on-screen-keyboard-20376} to
the payload should send out:
@footnote{The first line containing
starting with @code{Message ID} is an
example, it should be whatever is
appropriate for your client.}

@example
Modify ID: 4\n
Message ID: 2\n
Modify: yes\n
Length: 127\n
\n
Command: keyboard-enumeration\n
To: 0:1\n
In response to: 2\n
Message ID: 1\n
Length: 32\n
Modify ID: 4\n
\n
kernel\n
on-screen-keyboard-20376\n
@end example

If you however decide not to modify
the message send out

@example
Modify ID: 4\n
Message ID: 2\n
Modify: no\n
\n
@end example

There is also a third option:
to consume to the message. This
stops any further clients from
receiving the message. This is
done by modifying the message
into an empty message:

@example
Modify ID: 4\n
Message ID: 2\n
Modify: yes\n
\n
@end example

You may choose to include the
header--value pair @code{Length: 0},
it is however redundant and
discouraged.

This mechanism of being able to
modify message does not make much
sense unless you can control in
the order the clients receive
messages. This is done with what
is called priority. The higher
priority you have, the earlier
you will receive the message. The
default priority is zero, and the
priority is bound to a signed
64-bit integer. If you want to
be able to list yourself in
@code{Command: keyboard-enumeration}
message, you should sign up
with a positive priority since
the final recipient or requested
the enumeration will receive it
with priority zero. Therefore
you should sign up for such message
with a message like:
@footnote{4611686018427387904 is
halfway to the maximium value.}

@example
Command: intercept\n
Modifying: yes\n
Priority: 4611686018427387904\n
Message ID: 0\n
Length: 30\n
\n
Command: keyboard-enumeration\n
@end example



@node Utilities
@chapter Utilities

@menu
* mds-respawn::                     The server immortality protocol.
* External Utilities::              Suggestion on utilities you can utilise.
@end menu



@node mds-respawn
@section @command{mds-respawn}

@command{mds-respawn} is a utility intended to be used
in @file{$@{XDG_CONFIG_HOME@}/mdsinitrc}. It will spawn
a selected set of servers. If a server it spawns exits
with a bad status, @command{mds-respawn} will respawn it.
@command{mds-respawn} supports two options in the command
line:

@table @option
@item --alarm=SECONDS
Schedule @command{mds-respawn} to die in @var{SECONDS}
seconds. At most 1 minute.

@item --interval=SECONDS
Spawned servers that die twice with @var{SECONDS}
seconds should stop respawning until the signal
@code{SIGUSR2} is send to @command{mds-respawn}.
At most 1 minute.
@end table

Commands for servers to spawn are specified within
curly braces. Each of the braces must be alone its
its own argument. For example:

@example
mds-respawn --interval=5       \
  @{ mds-foo --initial-spawn @}  \
  @{ mds-bar --initial-spawn @}  &
@end example

will spawn and supervise the servers @command{mds-foo}
and @command{mds-bar}. Both spawned with the
argument @option{--initial-spawn}. When a server is
respawed by @command{mds-respawn}, @option{--initial-spawn}
in its argument list will be replaced by
@option{--respawn} to let the server know it is being
respawned.

A server is considered to exit with a failure status
unless it exits with the return value 0 or is terminated
by the signal @code{SIGTERM}.



@node External Utilities
@section External Utilities

Servers let you use the option @command{--on-init-fork}
to put the process in the background when it has been
initialised. This can used to spawn that depend on each
other in linear order. For example, if @command{mds-bar}
requires that @command{mds-foo} is initialised before it
can be initialised, you can in
@file{$@{XDG_CONFIG_HOME@}/mdsinitrc} write:

@example
mds-foo --on-init-fork
mds-bar &
@end example

This will start @command{mds-bar} when @command{mds-foo}
has been initialised. However if one of them crashes,
that server will not respawn; to fix this @command{mds-respawn}
can be used, but use of @command{mds-respawn} hinders
the use of @option{--on-init-fork}. Instead you can use
@option{--on-init-sh} and global semaphores. The packages,
and commands, @command{cmdipc} and @command{ipcmd} can be
used for this purpose. We will use @command{cmdipc} in an
example:

@example
S=$(cmdipc -Scx set 1 | cut -d ' ' -f 2)
# Create a System V semaphore with the value 1.

mds-respawn @{ mds-foo --on-init-sh="cmdipc -Sk $S p" @} &
# Spawn `mds-foo` and decrease the semaphore with 1 when initialised.

cmdipc -Sk $S z            # Wait for the semaphore's value to become 0.
cmdipc -Srk $S             # Remove the semaphore.
mds-respawn @{ mds-bar @} &  # Spawn `mds-bar`.
@end example

Another useful command (and package) is @command{setpgrp}.
@command{mds} puts itself an all its children in a new
process group. However you may want to put processes that
are not @command{mds} servers or @command{mds} utilities
in a separate process group. @command{setpgrp} can be used
to starta process in a new process group.



@node Servers
@chapter Servers

An @command{mds} display server instance is comprised of
multiple small servers that each implements a small part
of the display server's functionallity. This chapter will
include all servers but the master sever and the kernel,
the latter of which is not actually a server.

@menu
* mds-echo::                        The @command{mds-echo} server.
* mds-registry::                    The @command{mds-registry} server.
* mds-vt::                          The @command{mds-vt} server.
* mds-clipboard::                   The @command{mds-clipboard} server.
* mds-iclipboard::                  The @command{mds-iclipboard} server.
* mds-kkbd::                        The @command{mds-kkbd} server.
* mds-kkbdrate::                    The @command{mds-kkbdrate} server.
* mds-kbd::                         The @command{mds-kbd} server.
* mds-keytrans::                    The @command{mds-keytrans} server.
* mds-keystick::                    The @command{mds-keystick} server.
* mds-kbdbind::                     The @command{mds-kbdbind} server.
* mds-multikey::                    The @command{mds-multikey} server.
* mds-rat::                         The @command{mds-rat} server.
* mds-ratbind::                     The @command{mds-ratbind} server.
* mds-gestures::                    The @command{mds-gestures} server.
* mds-kbd2rat::                     The @command{mds-kbd2rat} server.
* mds-hwcursor::                    The @command{mds-hwcursor} server.
* mds-swcursor::                    The @command{mds-swcursor} server.
* mds-cursorshadow::                The @command{mds-cursorshadow} server.
* mds-cursorgamma::                 The @command{mds-cursorgamma} server.
* mds-hwgamma::                     The @command{mds-hwgamma} server.
* mds-swgamma::                     The @command{mds-swgamma} server.
* mds-coopgamma::                   The @command{mds-coopgamma} server.
* mds-dcvs::                        The @command{mds-dcvs} server.
@end menu



@node mds-echo
@section @command{mds-echo}

@command{mds-echo} is a server that echos message that
contain the header--value pair @command{Command: echo}.
This server can be used for debugging and testing as
well as to enable network heartbeats.



@node mds-registry
@section @command{mds-registry}

@command{mds-registry} is a server that keeps a registry
of all protocols that are supported they the sum of all
active servers. It can also be used by other servers to
wait until a protocol has become available.



@node mds-vt
@section @command{mds-vt}

@command{mds-vt} is the server that acquires a virtual
terminal for the display, manages virtual terminal
switches and enables other servers to get access to
the virtual terminal's TTY and informs them of which
virtual terminal the display is located on. It also
enables other servers to switch the virtual terminals
mode to graphical mode or text mode.



@node mds-clipboard
@section @command{mds-clipboard}

@command{mds} has three clipboards, one for copied
text, one for selected text, and one for non-textual
data. Each of these clipboards are stacks, just
like in GNU Emacs. @command{mds-clipboard} implements
these clipboards and automatic removal of outdated
clips. Clips can be configured to expire based on
time or when its originator closes.



@node mds-iclipboard
@section @command{mds-iclipboard}

@command{mds-iclipboard} is an alternative to
@command{mds-clipboard} that can be used to share
clipboard between multiple display servers.



@node mds-kkbd
@section @command{mds-kkbd}

@command{mds-kkbd} implements access to the kernel-based
keyboard. It does not however implement delay and rate
configurations for the kernel-based keyboard as that
requires root privileges. The kernel-based keyboard is
a keyboard that can be accessed by reconfiguring
stdin in a TTY using @code{ioctl} and then read from
stdin. @command{mds-kkbd} does not implement any keyboard
layout, rather it broadcasts scancodes and keycode.
However it can remap keycodes, but not scancodes.



@node mds-kkbdrate
@section @command{mds-kkbdrate}

@command{mds-kkbdrate} is a complemental server to
@command{mds-kkbd}, it implements rate and delay
control for the kernel-based keyboard.



@node mds-kbd
@section @command{mds-kbd}

@command{mds-kbd} is an alternative to
@command{mds-kkbd} and @command{mds-kkbdrate}.
In contrast to @command{mds-kkbd}, @command{mds-kbd}
implements control over individual keybroads rather
than utilising the kernels keyboard drivers to
treats all keyboards a one keyboard. This server
is only useful for multiseat sessions and if you
otherwise actually want to handle the keyboards
individually.



@node mds-keytrans
@section @command{mds-keytrans}

@command{mds-keytrans} is the server than translates
keycodes from @command{mds-kkbd} and @command{mds-kbd},
and third-party alternatives, to characters and other
attributes. It implements the keyboard's layouts including
modifiers, letters, other symbols, dead keys and compose.



@node mds-keystick
@section @command{mds-keystick}

@command{mds-keystick} is a server that can be used
to enable sticky keys.



@node mds-kbdbind
@section @command{mds-kbdbind}

@command{mds-kbdbind} is a server similar to
@command{xbindkeys}. It can be used to run commands
upon selected key combinations, for example starting
@code{dmenu} or change keyboard layout.
@command{mds-kbdbind} can distinguish keyboards
from eachother.



@node mds-multikey
@section @command{mds-multikey}

@command{mds-multikey} is a server that can
bind a key, key combination, or sequence their
of to a sequence of keys or key combinations.
For example, you could bind `<super>x, y' to
simulate that a key `Faux1' is pressed, a key
that does not exist, this key press could be
picked up by @command{mds-kbdbind} to enable
@command{mds-kbdbind} to respond to squences
rather than single keys and single key
combinations. alternatively you could bind
`<super>x' to press `x' a selected number of
times with a short selectable delay between
them; or `<super>x, 5' to press `x' five times.



@node mds-rat
@section @command{mds-rat}

@command{mds-rat} is a server that implements
support of rat (also known as mouse) devices.



@node mds-ratbind
@section @command{mds-ratbind}

@command{mds-ratbind} is a server similar to
@command{mds-kbdbind}. However, @command{mds-ratbind}
respons to rat and rat cursor actions rather
than keyboard actions. It can for example be
used to implement hotcorners.



@node mds-gestures
@section @command{mds-gestures}

@command{mds-gestures} is a server similar to
@command{mds-ratbind}. However it is specialised
to respond to gestures.



@node mds-kbd2rat
@section @command{mds-kbd2rat}

If you do not have a rat or rather use your keyboard,
the server @command{mds-kbd2rat} can be used to
bind keyboard actions to simulate rat actions.
This server is a specialisation of @code{mds-kbdbind},
rather than spawning generic commands it broadcasts
messages without the display server to move the
rat cursor and click on rat buttons. @code{mds-kbdbind}
could be used to do this, but @command{mds-kbd2rat}
will not spawn a new process for each action.



@node mds-hwcursor
@section @command{mds-hwcursor}

@command{mds-hwcursor} is a server that draws
the rat cursor to the monitor on a plane
separate from all other content on the display.
Is less esoteric terms, it implements a hardware
cursor.



@node mds-swcursor
@section @command{mds-swcursor}

@command{mds-swcursor} is a server that draws
the rat cursor to the monitor on the same plane
as all other content on the display. Is less
esoteric terms, it implements a software cursor.



@node mds-cursorshadow
@section @command{mds-cursorshadow}

@command{mds-cursorshadow} is a server that
can be used to decorate the rat cursor with
a configurable shadow.



@node mds-cursorgamma
@section @command{mds-cursorgamma}

@command{mds-cursorgamma} is a server you can
use if you use @command{mds-hwcursor} to, if
not done by the graphics driver, correct the
gamma correction on the hardware cursor using
software gamma ramps. This of courses works
whether you are using hardware or software
gamma ramps for your monitor's gamma correction.
If can even be used if you do not use gamma
correction, in such case, only the cursor
will have its gamma corrected.



@node mds-hwgamma
@section @command{mds-hwgamma}

To enable gamma correction, use the server
@command{mds-hwgamma}. It implements hardware
gamma ramps, that is, gamma ramps assisted
by hardware acceleration.



@node mds-swgamma
@section @command{mds-swgamma}

If your graphics driver does not support
@command{mds-hwgamma}, you can instead use
@command{mds-swgamma}. It implements software
gamma ramps, that is, it will modify each
pixel according to the selected gamma
correction before it is send to the presentation
sever. To accelerate this process,
@command{mds-swgamma} can tell programs how
to modify its colours before sending it; the
programs can then tell @command{mds-swgamma}
not to apply its correction. Programs such
as video players can also use this to tell
the server not to apply gamma correction as
that may cause the video to be played back
to slowly.



@node mds-coopgamma
@section @command{mds-coopgamma}

@command{mds-coopgamma} is a server that
can be used to enable multiple clients to
manipulate the gamma ramps without stepping
on eachothers toes. It does this by letting
clients tell which priority their corrections
has and use this data to chain together there
modifications. For example if one program
wants to apply a red filter to the display
and another program wants to correct the
monitors' gamma, the red filter program will
send lookup tables for the gamma with high
priority and the correction program will
send its lookup tables with low priority.
@command{mds-coopgamma} will then apply the
latter lookup tables on top of the red filter.
The clients can tell @command{mds-coopgamma}
whether it should remove their changes when
they close, or even keep them and wait for
the client to restart.



@node mds-dcvs
@section mds-dcvs

@command{mds-dcvs} is a server than can be
used to simulate defective colour vision.
That is, it can for example turn the display
greyscale (colour blindness) or add a filter
the simulates deuteranopia or deuteranomaly.



@node libmdsserver
@chapter libmdsserver

libmdsserver is library written for the reference
implementation of the @command{mds} servers.
libmdsserver does not contain support or any
protocols, rather it contains auxiliary functions,
macros, data structures such as linked lists and
hash tables, and support the basics of the message
passing protocol: receiving message and decode it
into headers and payloads.

@menu
* Macros::                          Writing macroscopic systems.
* Auxiliary Functions::             Auxiliary functions for servers.
* Data Structures::                 Data structures available in libmdsserver.
@end menu



@node Macros
@section Macros

The header file @file{<libmdsserver/macros.h>}
contains macros for readability and code reduction,
it also contains macros and definitions for portability;
they may either provide portability by nature, or
provide one place to do modifications to port the
system.

@table @asis
@item @code{xsnprintf} [(@code{char buffer[], char* format, ...}) @arrow{} @code{int}]
This is a wrapper for @code{snprintf} that allows you
to forget about the buffer size. When you know how long
a string can be, you should use @code{sprintf}. But when
you cannot know for sure you should use @code{xsnprintf}.
@code{xsnprintf} works exactly as @code{sprintf}, but
it will require that the first argument is defined
using @code{[]} rather than @code{*} because it will use
this to find out how large the buffer is so it can call
@code{snprintf} with that size.

@item @code{eprint} [(@code{const char* format}) @arrow{} @code{int}]
A wrapper for @code{fprintf} that prints a string prefixed
with the value value of @code{*argv} to @code{stderr}.
Because @code{eprintf} naïvely wraps @code{fprintf}, all
`%':s in the string must be duplicated.

@item @code{eprintf} [(@code{const char* format, ...}) @arrow{} @code{int}]
@code{eprint} extends @code{eprint} with variadic arguments
that can be used to insert values into the format string
just like you can do in @code{fprintf}.

@item @code{with_mutex} [(@code{pthread_mutex_t mutex, instructions})]
Wraps @code{instructions} with @code{errno = pthread_mutex_lock(mutex);}
and @code{errno = pthread_mutex_unlock(mutex);}, so a set of
instructions can be invoked inside mutex protection.

@item @code{with_mutex_if} [(@code{pthread_mutex_t mutex, condition, instructions})]
An alternative to @code{with_mutex} where @code{instructions}
is wrapped around @code{if (condition)} which in turn is
wrapped inside the mutex protection.

@item @code{max} [(@code{a, b})]
Returns the higher value of @code{a} and @code{b}.

@item @code{min} [(@code{a, b})]
Returns the lower value of @code{a} and @code{b}.

@item @code{buf_cast} [(@code{char* buffer, type, size_t index})]
Casts @code{buffer} to a @code{type} buffer and
subscripts to the @code{index}:th element. You
can either use this function as a getter or a
setter.

@item @code{buf_set} [(@code{char* buffer, type, size_t index, type variable}) @arrow{} @code{type}]
Wrapper for @code{buf_cast} that sets the addressed
element to the value of @code{variable}.

@item @code{buf_get} [(@code{const char* buffer, type, size_t index, type variable}) @arrow{} @code{type}]
Wrapper for @code{buf_cast} that sets the value of
@code{variable} to the value of the addressed element.

@item @code{buf_next} [(@code{char* buffer, type, size_t count}) @arrow{} @code{char*}]
Increases the pointer @code{buffer} by the size of
@code{type} @code{count} types.

@item @code{buf_prev} [(@code{char* buffer, type, size_t count}) @arrow{} @code{char*}]
Decreases the pointer @code{buffer} by the size of
@code{type} @code{count} types.

@item @code{buf_set_next} [(@code{char* buffer, type, type variable}) @arrow{} @code{type}]
@example
buf_set(buffer, type, 0, variable),
buf_next(buffer, type, 1);
@end example

@item @code{buf_get_next} [(@code{char* buffer, type, type variable}) @arrow{} @code{type}]
@example
buf_get(buffer, type, 0, variable),
buf_next(buffer, type, 1);
@end example

@item @code{strequals} [(@code{const char* a, const char* b}) @arrow{} @code{int}]
Evaluates whether the strings @code{a} and @code{b}
are equals, neither may be @code{NULL}.

@item @code{startswith} [(@code{const char* haystack, const char* needle}) @arrow{} @code{int}]
Evaluates whether the string @code{haystack}
starts with the string @code{needle}, neither
may be @code{NULL}.

@item @code{drop_privileges} [(void) @arrow{} @code{int}]
Sets the effective user to the real user and the
effective group to the real group. This is used
by most servers and ensure that they are not
running with unnecessary privileges. Returns zero
on and only on success.

@item @code{monotone} [(@code{struct timespec* time_slot}) @arrow{} @code{int}]
Stores the time of an unspecified monotonic clock
into @code{time_slot}. Returns zero on and only on
success.

@item @code{close_files} [(@code{condition}) @arrow{} @code{void}]
Closes all file descriptors named by a variable
@code{fd} for which @code{condition} evalutes
to non-zero.

@item @code{xfree} [(@code{void** array, size_t elements}) @arrow{} @code{void}]
Calls @code{free} on the first @code{elements}
elements in @code{array}, and than calls
@code{free} on @code{array}. This macro
requires @code{size_t i} is declared.

@item @code{xmalloc} [(@code{type* var, size_t elements, type}) @arrow{} @code{int}]
Allocates a @code{type*} with @code{elements}
elements and store the allocated pointer to
@code{var}. Returns zero on and only on success.

@item @code{xcalloc} [(@code{type* var, size_t elements, type}) @arrow{} @code{int}]
Allocates a zero-initialised @code{type*} with
@code{elements} elements and store the allocated
pointer to @code{var}. Returns zero on and only
on success.

@item @code{xrealloc} [(@code{type* var, size_t elements, type}) @arrow{} @code{int}]
Reallocates @code{var} and updates the variable
@code{var} accordingly. @code{var} will be
allocated to have @code{elements} elements
of the type @code{type}. If @code{var} is
@code{NULL} a new allocation is created. If
@code{elements} is zero, @code{var} will
be deallocated. Returns zero on and only
on success. On failure, @code{var} will be
@code{NULL}, so you must store the @code{var}
into another variable in case this macro
fails.

@item @code{growalloc} [(@code{type* old, type* var, size_t elements, type}) @arrow{} @code{int}]
When using this macro @code{var} should
be a @code{type*} pointer allocated for
@code{elements} elements of the type
@code{type}. This macro will reallocate
@code{var} to contain twice as many elements
and update @code{elements} accordingly.
On failure nothing changes. You must specify
an auxiliary @code{type*} variable and
specify it in as the @code{old} parameter.
Returns zero on and only on success.

@item @code{xperror} [(@code{const char* str}) @arrow{} @code{void}]
Invokes @code{perror(str)} if and only if
@code{errno} is non-zero and then sets
@code{errno} to zero. @code{str} should
unless you have a specific reason be
@code{*argv}.

@item @code{fail_if} [(@code{condition}) @arrow{} @code{void}]
If @code{condition} is satisfied, a jump
is made to the label @code{pfail}.
@code{pfail:} should be used for calling
@code{xperror} and return @code{-1}.

@item @code{exit_if} [(@code{condition, instructions}) @arrow{} @code{void}]
If @code{condition} is satisfied,
@code{instructions} is invoked and
@code{1} is @code{return}:ed.
@end table

Additionally, @file{<libmdsserver/macros.h>}
defines any missing signal name:
currenly @code{SIGDANGER} and
@code{SIGUPDATE}, and by inclusion of
@file{<libmdsserver/macro-bits.h>}, variants
of @code{atoi} for portability and
convenience:

@table @code
@item atoz
Parse a human readable @code{const char*}
10-radix integer to a @code{size_t}.

@item atosz
Parse a human readable @code{const char*}
10-radix integer to a @code{ssize_t}.

@item atoh
Parse a human readable @code{const char*}
10-radix integer to a @code{short int}.

@item atouh
Parse a human readable @code{const char*}
10-radix integer to an @code{unsigned short int}.

@item atou
Parse a human readable @code{const char*}
10-radix integer to an @code{unsigned int}.

@item atoul
Parse a human readable @code{const char*}
10-radix integer to an @code{unsigned long int}.

@item atoull
Parse a human readable @code{const char*}
10-radix integer to an @code{unsigned long long int}.

@item ato8
Parse a human readable @code{const char*}
10-radix integer to an @code{int8_t}.

@item atou8
Parse a human readable @code{const char*}
10-radix integer to an @code{uint8_t}.

@item ato16
Parse a human readable @code{const char*}
10-radix integer to an @code{int16_t}.

@item atou16
Parse a human readable @code{const char*}
10-radix integer to an @code{uint16_t}.

@item ato32
Parse a human readable @code{const char*}
10-radix integer to an @code{int32_t}.

@item atou32
Parse a human readable @code{const char*}
10-radix integer to an @code{uint32_t}.

@item ato64
Parse a human readable @code{const char*}
10-radix integer to an @code{int64_t}.

@item atou64
Parse a human readable @code{const char*}
10-radix integer to an @code{uint64_t}.

@item atoj
Parse a human readable @code{const char*}
10-radix integer to an @code{intmax_t}.

@item atouj
Parse a human readable @code{const char*}
10-radix integer to an @code{uintmax_t}.
@end table



@node Auxiliary Functions
@section Auxiliary Functions

In the header file @file{<libmdsserver/util.h>},
libmdsserver defines common functions to help
write servers more concisely.

@table @asis
@item @code{parse_client_id} [(@code{const char* str}) @arrow{} @code{uint64_t}]
Convert a client ID string into a client ID integer.

@item @code{getenv_nonempty} [(@code{const char* var}) @arrow{} @code{char*}]
Read an environment variable, return @code{NULL} if
the variable's value is an empty string.

@item @code{prepare_reexec} [(@code{void}) @arrow{} @code{int}]
Prepare the server so that it can re-execute into
a newer version of the executed file.

This is required for two reasons:

@enumerate 1
@item
We cannot use @code{argv[0]} as @env{PATH}-resolution
may cause it to reexec into another pathname, and
maybe to wrong program. Additionally @code{argv[0]}
may not even refer to the program, and @code{chdir}
could also hinter its use.

@item
The kernel appends ` (deleted)' to
@file{/proc/self/exe} once it has been removed,
so it cannot be replaced.
@end enumerate

The function will should be called immediately, it
will store the content of @file{/proc/self/exe}.
Return zero on success and @code{-1} on error.

@item @code{reexec_server} [(@code{int argc, char** argv, int reexeced}) @arrow{} @code{void}]
Re-exec the server.
This function only returns on failure.

If `prepare_reexec` failed or has not been called,
`argv[0]` will be used as a fallback.

param  argc      The number of elements in `argv`
param  argv      The command line arguments
param  reexeced  Whether the server has previously been re-exec:ed

@item @code{xsigaction} [(@code{int signo, void (*function)(int signo)}) @arrow{} @code{int}]
@code{sigaction} with the same parameters as @code{signal}.
This function should only be used for common @command{mds}
signals and signals that does not require any special settings.
This function may choose to add additional behaviour depending
on the signal, such as blocking other signals. Returns zero
on success and @code{-1} on error.

@item @code{send_message} [(@code{int socket, const char* message, size_t length}) @arrow{} @code{size_t}]
Send the message @code{messsage}, of length @code{length}
over the socket that is access with the file descriptor
@code{socket}. Returns the number of bytes that have been
sent, even on error.

@item @code{strict_atoi} [(@code{const char* str, int* value, int min, int max}) @arrow{} @code{int}]
A version of @code{atoi} that is strict about the syntax
and bounds. Parses the string @code{str} into an @code{int}
and stores it in @code{*value}. If the string is not a
10-radix integer or has a value outside [@code{min},
@code{max}], @code{-1} is returned, otherwise zero is
returned.

@item @code{full_write} [(@code{int fd, const char* buffer, size_t length}) @arrow{} @code{int}]
Send the buffer @code{buffer}, with the length @code{length},
into the file whose file descriptor is @code{fd} and ignores
interruptions. Returns zero on success and @code{-1} on error.

@item @code{full_read} [(@code{int fd, size_t* length}) @arrow{} @code{char*}]
Read the file whose file descriptor is @code{fd} completely
and ignore interruptions. If @code{length} if not @code{NULL},
the length of the read file is stored in @code{*length}.
On success, the read content is retured, on error @code{NULL}
is returned.

@item @code{startswith_n} [(@code{const char*, const char*, size_t, size_t}) @arrow{} @code{int}]
Check whether a string begins with a specific string,
where neither of the strings are necessarily NUL-terminated.
The parameters are:

@table @code
@item const char* haystack
The string that should start with the other string.
@item const char* needle
The string the first string should start with.
@item size_t haystack_n
The length of @code{haystack}.
@item size_t needle_n
The length of @code{needle}.
@end table

Returns 1 if @code{haystack} beings with @code{needle},
otherwise zero is returned.

@item @code{uninterruptable_waitpid} [(@code{pid_t pid, int* restrict status, int options}) @arrow{} @code{pid_t}]
Wrapper around @code{waitpid} that never returns on an
interruption unless it is interrupted one hundred times
within the same clock second. The parameters and return
value are exactly those of @code{waitpid}.
@end table



@node Data Structures
@section Data Structures

libmdsserver provides a small set of datastructures
that are used by the @command{mds} servers. All of
these are written with marshal-functionallity.

@table @asis
@item @code{client_list_t} @{also known as @code{struct client_list}@}
In the header file @file{<libmdsserver/client-list.h>},
libmdsserver defines a dynamic list for storing
client ID:s.

@item @code{linked_list_t} @{also known as @code{struct linked_list}@}
In the header file @file{<libmdsserver/linked-list.h>},
libmdsserver defines a linear array sentinel doubly
linked list.

@item @code{hash_table_t} @{also known as @code{struct hash_table}@}
In the header file @file{<libmdsserver/hash-table.h>},
libmdsserver defines a hash table.

@item @code{fd_table_t} @{also known as @code{struct fd_table}@}
In the header file @file{<libmdsserver/fd-table.h>},
libmdsserver defines a lookup table for small
positive integer keys, intended as an alternative
to hash tables for file descriptors as keys.

@item @code{mds_message_t} @{also known as @code{struct mds_message}@}
In the header file @file{<libmdsserver/mds-message.h>},
libmdsserver defines a data structure for message
between the server or client and the master server,
with the capability of reading for a socket.
@end table

These data structures share a common set of associated
function. However, they do not use the same functions;
they are identical except they are are named with the
associated data structure. We will use @code{X_t}
as an example.

@table @asis
@item @code{X_destroy} [(@code{X_t* restrict this}) @arrow{} @code{void}]
Releases all resouces in @code{*this},
@code{this} itself is however not @code{free}:d.

However, @code{hash_table_destory} and
@code{fd_table_destory} have another signature.

@item @code{X_clone} [(@code{const X_t* restrict this, X_t* restrict out}) @arrow{} @code{int}]
Create a deep duplicate of @code{*this} and store
it in @code{*out}.

@item @code{X_marshal_size} [(@code{const X_t* restrict this}) @arrow{} @code{size_t}]
Calculates the exact allocate size needed for
the parameter @code{data} in the function
@code{X_marshal} if called with the same
@code{this} parameter.

@item @code{X_marshal} [(@code{const X_t* restrict this, char* restrict data}) @arrow{} @code{void}]
Marshal the state of @code{*this} into
@code{data}. The number of bytes that
will be stored (contiguously) in @code{data}
can be calculated with @code{X_marshal_size}.

@item @code{X_unmarshal} [(@code{X_t* restrict this, char* restrict data)}) @arrow{} @code{int}]
Unmarshal a @code{X_t} from
@code{data} into @code{*this}. Returns
zero on success and @code{-1} on error.
The number of bytes read from @code{data}
should, if required, have been precalculated
with @code{X_marshal_size} and stored in an
earlier location of @code{data}.

However, @code{hash_table_unmarshal} and
@code{fd_table_unmarshal} have another signature.
@end table

@menu
* Client List::                     The @code{client_list_t} data structure.
* Linked List::                     The @code{linked_list_t} data structure.
* Tables::                          The @code{fd_table_t} and @code{hash_table_t} data structures.
* Message Structure::               The @code{mds_message_t} data structure.
@end menu



@page
@node Client List
@subsection Client List

To create a client list, allocate a
@code{client_list_t*} or otherwise obtain
a @code{client_list_t*}, and call
@code{client_list_create} with that
pointer as the first argument, and
the @code{0} as the second argument,
unless you want to tune the initialisation.
@code{client_list_create} will return
zero on and only on successful initialisation.
@code{client_list_create}'s second parameter
--- @code{size_t capacity} --- can be used
to specify how many element the list should
initially fit. It will grow when needed, but
it is a good idea to tell it how many elements
you are planning to populate it with.

@code{client_list_t} has two associated
functions for manipulating its content:

@table @asis
@item @code{client_list_add} [(@code{client_list_t* restrict this, uint64_t client}) @arrow{} @code{int}]
This function will add the element @code{client}
to the list @code{*this}, and return zero on
and only on success.

@item @code{client_list_remove} [(@code{client_list_t* restrict this, uint64_t client}) @arrow{} @code{void}]
This function will remove exactly one occurrence,
provided that there is at least on occurrence,
of the element @code{client} for the list @code{*this}.
@end table

The retrieve the number elements stored in
a list, reads its variable @code{size_t size}.
The variable @code{uint64_t* clients} is
used to retrieve stored elements.

@example
void print_elements(client_list_t* this)
@{
  size_t i;
  for (i = 0; i < this->size; i++)
    printf("Element #%zu: %" PRIu64 "\n", i, this->elements[i]);
@}
@end example



@node Linked List
@subsection Linked List

@code{linked_list_t} is a linear array sentinel
doubly linked list. This means that is implemented
using arrays rather than node references. More
specifically, since it is doubly linked@footnote{And
not using XOR-linking.}, it is implemented using
three arrays:

@table @asis
@item @code{values} [@code{size_t*}]
The value stored in each node.

@item @code{next} [@code{ssize_t*}]
The next node for each node, @code{edge} if the current
node is the last node, and @code{LINKED_LIST_UNUSED} if
there is no node on this position.

@item @code{previous} [@code{ssize_t*}]
The previous node for each node, @code{edge} if the current
node is the first node, and @code{LINKED_LIST_UNUSED} if
there is no node on this position.
@end table

The linked list has a sentinel node that joins
boths ends of the list. The index of this node
is stored in the variable @code{edge}.

Because the list is implemented using arrays, if the
number of elements in it shinks considerably, it will
not be able to automatically free unused space. Instead
you must call @code{linked_list_pack}:

@table @asis
@item @code{linked_list_pack} [(@code{linked_list_t* restrict this}) @arrow{} @code{int}]
Pack the list so that there are no reusable positions,
and reduce the capacity to the smallest capacity that
can be used. Note that values (nodes) returned by the
list's methods will become invalid. Additionally (to
reduce the complexity) the list will be defragment so
that the nodes' indices are continuous. This method has
linear time complexity and linear memory complexity.
@end table

To create a linked list list, allocate a
@code{linked_list_t*} or otherwise obtain
a @code{linked_list_t*}, and call
@code{linked_list_create} with that
pointer as the first argument, and
the @code{0} as the second argument,
unless you want to tune the initialisation.
@code{linked_list_create} will return
zero on and only on successful initialisation.
@code{linked_list_create}'s second parameter
--- @code{size_t capacity} --- can be used
to specify how many element the list should
initially fit. It will grow when needed, but
it is a good idea to tell it how many elements
you are planning to populate it with.

There are five functions adding and removing
items to and from a linked list:

@table @asis
@item @code{linked_list_insert_after} [(@code{this, size_t value, ssize_t predecessor}) @arrow{} @code{ssize_t}]
Create a new node with the value @code{value} and add it
to the list @code{*this} after the node @code{predecessor}.
On success, the new node is returned, on failure
@code{LINKED_LIST_UNUSED} is returned.

@item @code{linked_list_insert_before} [(@code{this, size_t value, ssize_t successor}) @arrow{} @code{ssize_t}]
Create a new node with the value @code{value} and add it
to the list @code{*this} before the node @code{successor}.
On success, the new node is returned, on failure
@code{LINKED_LIST_UNUSED} is returned.

@item @code{linked_list_remove_after} [(@code{this, ssize_t predecessor}) @arrow{} @code{ssize_t}]
Remove and return the node in the list @code{*this}
directly after the node @code{predecessor}.

@item @code{linked_list_remove_before} [(@code{this, ssize_t successor}) @arrow{} @code{ssize_t}]
Remove and return the node in the list @code{*this}
directly before the node @code{predecessor}.

@item @code{linked_list_remove} [(@code{this, ssize_t node}) @arrow{} @code{void}]
Remove the node @code{node} from the list @code{*this}.
@end table

The data type for @code{this} is @code{linked_list_t*}
with the @code{restrict} modifier for these and all
other @code{linked_list_t} functions.

Note that if the node @code{this->edge} is removed,
the list become circularly linked and the sentinel
will become missing which renders invokation of all
macros undefined in behaviour. Further note that
removing the sentinel while it is the only node in
the list invokes undefined behaviour. Also note that
addressing non-existing nodes invokes undefined
behaviour.

@file{<libmdsserver/linked_list.h>} defines two
macros for inserting nodes at the edges of a linked
list and two macros for removing nodes from the
edges of a linked list:

@table @asis
@item @code{linked_list_insert_beginning} [(@code{linked_list_t* this, size_t value}) @arrow{} @code{ssize_t}]
Create a new node with the value @code{value} in
insert it to the beginning of the list @code{*this}.
On success, the new node is returned, on failure
@code{LINKED_LIST_UNUSED} is returned.

@item @code{linked_list_insert_end} [(@code{linked_list_t* this, size_t value}) @arrow{} @code{ssize_t}]
Create a new node with the value @code{value} in
insert it to the end of the list @code{*this}.
On success, the new node is returned, on failure
@code{LINKED_LIST_UNUSED} is returned.

@item @code{linked_list_remove_beginning} [(@code{linked_list_t* this}) @arrow{} @code{ssize_t}]
Remove and return the first node in the
list @code{*this}.

@item @code{linked_list_remove_end} [(@code{linked_list_t* this}) @arrow{} @code{ssize_t}]
Remove and return the node node in the
list @code{*this}.
@end table

Additionally the library defines a macro that
wrappes the @code{for} keyword to iterate over
all nodes (except the sentinel node) the a
linked list:

@table @asis
@item @code{foreach_linked_list_node} [(@code{linked_list_t this, ssize_t node})]
Wrapper for `for` keyword that iterates over each
element in the list @code{this}, and store the
current node to the variable named by the parameter
@code{node} for each iterations.

@example
void print_linked_list_values(linked_list_t* list)
@{
  ssize_t node;
  foreach_linked_list_node (*list, node)
    printf("%zi\n", list->values[node]);
@}
@end example

Note that the data type for @code{this} in the
macro is not a pointer.
@end table

There is also a function intended for debugging:

@table @asis
@item @code{linked_list_dump} [(@code{linked_list_t* restrict this, FILE* restrict output}) @arrow{} @code{void}]
The all internal data of the list @code{*this}
into the stream @code{output}.
@end table



@node Tables
@subsection Tables

libmdsserver defines two similar data structures:
@code{fd_table_t} and @code{hash_table_t}. Whenever
a function exists for both data structures we will
write @code{X_table} instead of @code{fd_table} and
@code{hash_table}. Additionally, unless otherwise
stated, a function's parameter named @code{this}
will be of the type @code{hash_table_t*} if the
function's name start with @code{hash_table} and
@code{fd_table_t*} if the function's name start
with @code{fd_table}, with the @code{restrict}
modifier.

@table @asis
@item @code{X_table_create} [(@code{this}) @arrow{} @code{int}]
Initialises @code{*this} so it can be used as a
table. Returns zero on and only on success.

These functions are defined as macros.

@item @code{X_table_create_tuned} [(@code{this, size_t initial_capacity}) @arrow{} @code{int}]
Initialises @code{*this} so it can be used as a
table, and makes its initial capacity at least
@code{initial_capacity}. Returns zero on and only
on success.

@code{hash_table_create_tuned} is defined as a macro.

@item @code{hash_table_create_tuned} [(@code{this, size_t initial_capacity, float load_factor}) @arrow{} @code{int}]
Initialises @code{*this} so it can be used as a
table, and makes its initial capacity at least
@code{initial_capacity} and its load factor
@code{load_factor}. Returns zero on and only
on success.

@item @code{X_table_destroy} [(@code{this, free_func* key_freer, free_func* value_freer}) @arrow{} @code{void}]
Release all resources in the table @code{*this},
but do not @code{free} @code{this} itself.
Should be called even if construction fails.
If @code{keys_freer} is not @code{NULL}, this
function will be called for each key.
If @code{values_freer} is not @code{NULL}, this
function will be called for each value.

@item @code{X_table_contains_value} [(@code{const this, size_t value}) @arrow{} @code{int}]
Check whether the value @code{value} is stored
in the table @code{*this}.

@item @code{X_table_contains_key} [(@code{const this, key}) @arrow{} @code{int}]
Check whether the key @code{code} is used in the
table @code{*this}.

The data type for the parameter @code{key} is
@code{size_t} for @code{hash_table} and @code{int}
for @code{fd_table}.

@item @code{X_table_get} [(@code{const this, key}) @arrow{} @code{size_t}]
Look up a value by its key @code{key} in the
table @code{*this}. Zero will be returned if
the key was not used.

@item @code{hash_table_get_entry} [(@code{const this, size_t key}) @arrow{} @code{hash_entry_t*}]
Look up an entry by its key @code{key} in the
table @code{*this}. @code{NULL} will be returned
if the key was not used.

@item @code{X_table_put} [(@code{this, key, size_t value}) @arrow{} @code{size_t}]
Map the value @code{value} to the key @code{key}
in the talbe @code{*this}. If a value was already
mapped to the key, that value will be returned,
otherwise zero will be returned. Zero will also
be returned on error. @code{errno} will be set to
zero on and only on success.

The data type for the parameter @code{key} is
@code{size_t} for @code{hash_table} and @code{int}
for @code{fd_table}.

@item @code{X_table_remove} [(@code{this, key}) @arrow{} @code{size_t}]
Unmaps the key @code{key} for the table @code{*this}.
If a value was mapped to the key, that value will
be returned, otherwise zero will be returned.

The data type for the parameter @code{key} is
@code{size_t} for @code{hash_table} and @code{int}
for @code{fd_table}.

@item @code{X_table_clear} [(@code{this}) @arrow{} @code{void}]
Unmaps all keys in the table @code{*this}.

@item @code{X_table_unmarshal} [(@code{this, char* restrict data, remap_func* remapper}) @arrow{} @code{int}]
As described in @ref{Data Structures} but with one
additional parameter: @code{remapper}. If this
parameter is not @code{NULL} this function is used
to edit values. It will be called once for each
value and the output of the function will be used
inplace of the input value.
@end table

@file{<libmdsserver/hash-table.h>} also defines
as wrapper macro for the @code{for} keyword:

@table @asis
@item @code{foreach_hash_table_entry} [(@code{hash_table_t this, size_t i, hash_entry_t* entry})]
Iterates over entry element in the hash table
@code{*this}. On each iteration, the entry will
be stored to the variable @code{entry} and the
bucket index will be stored to the variable
@code{i}.

@example
void print_hash_table(hash_table_t* table)
@{
  hash_entry_t* entry;
  size_t i;
  foreach_hash_table_entry (*table, i, entry)
    printf("%zu --> %zu\n", entry->key, entry->value);
@}
@end example

Note the the data type for the parameter @code{this}
is not a popinter.
@end table

The structures @code{hash_table_t} and @code{fd_table_t}
contain the variable @code{value_comparator} which by
default is @code{NULL}. If this variable is set to @code{NULL},
two values will be considered equal if and only if they are
numerically identical; otherwise two values will be considered
equal if and only if @code{value_comparator} returned a
non-zero value if those two values are used for the function's
arguments. The data type for @code{value_comparator} is
@code{compare_func*}.

@code{hash_table_t} also contains two other variables:

@table @asis
@item @code{key_comparator} [@code{compare_func*}]
Identical to @code{value_comparator}, except it is used for
keys rather the values.

@item @code{hasher} [@code{hash_func*}]
By default, the hash value for key is identical to the key
itself. However, if this variable is not @code{NULL}, it
will be used to calculate the hash value for keys.
@end table

There is a secondary data structure defined for hash tables:
@code{hash_entry_t} @{also known as @code{struct hash_entry}@}.
It is the data structure used for entries in a hash table.
@code{hash_entry_t} contain three variables you may be interested in:

@table @asis
@item @code{key} [@code{size_t}]
The key.

@item @code{value} [@code{size_t}]
The value associated with the key.

@item @code{hash} [@code{size_t}]
The hash value of the key.
@end table

By inclusion of @file{<libmdsserver/table-common.h>},
@file{<libmdsserver/hash-table.h>} and @file{<libmdsserver/fd-table.h>}
defines four @code{typedef}:s for function signatures:

@table @asis
@item @code{compare_func} [(@code{size_t a, size_t b}) @arrow{} @code{int}]
A function that performs a comparison of two objects.
Should return non-zero if and only if @code{a} and
@code{b} are to be considered equal in the given
context.

@item @code{hash_func} [(@code{size_t value}) @arrow{} @code{size_t}]
A function that hashes an object or a value.
Should return the hash value for @code{value}.

@item @code{free_func} [(@code{size_t obj}) @arrow{} @code{void}]
A function that, to the extent that is appropriate,
releases the object @code{obj}'s resources and
@code{free}:s it.

@item @code{remap_func} [(@code{size_t obj}) @arrow{} @code{size_t}]
A function that translates a object into a new object.
The function should return new object that should replace
the object @code{obj}.
@end table

If you are working with strings, you may consider
including the header file @file{<libmdsserver/hash-help.h>}.
It defines to useful functions:

@table @asis
@item @code{string_hash} [(@code{const char* str}) @arrow{} @code{size_t}]
Calculate and returns the hash value of the string @code{str}.

@item @code{string_comparator} [(@code{char* str_a, char* str_b}) @arrow{} @code{int}]
Returns non-zero if either both @code{str_a} and @code{str_b}
are @code{NULL} or neither are @code{NULL} but are identical
strings by content upto their first NUL characters (or by address).
@end table

These functions are defined as pure and @code{static inline}.



@node Message Structure
@subsection Message Structure

Apart from internal data @code{mds_message_t} contains four
variables:

@table @asis
@item @code{headers} [@code{char**}]
The headers in the message, each element in this list
as an unparsed header, it consists of both the header
name and its associated value, joined by `: '. A header
cannot be @code{NULL} (unless its memory allocation failed,)
but @code{headers} itself is @code{NULL} if there are
no headers. The `Length' header should be included in
this list.

@item @code{header_count} [@code{size_t}]
The number of headers in the message.

@item @code{payload} [@code{char*}]
The payload of the message, @code{NULL} if
none (of zero-length).

@item @code{payload_size} [@code{size_t}]
The length of the message's payload.
This value will be the same as the value
of the `Length' header.
@end table

There are six functions specific to @code{mds_message_t}.
The @code{this}-parameter's data type for this functions
are @code{mds_message_t*} with the @code{restrict} modifier.

@table @asis
@item @code{mds_message_initialise} [(@code{this}) @arrow{} @code{int}]
Initialises @code{*this} so that it can be used by
@code{mds_message_read}. Returns zero on and only on
success. On failure you should destroy @code{*this}
using @code{mds_message_destroy}.

@item @code{mds_message_zero_initialise} [(@code{this}) @arrow{} @code{void}]
This function is similar to @code{mds_message_initialise},
however it cannot fail and thus have no return value.
The difference it is action is that it will not allocate
an internal buffer.

@item @code{mds_message_extend_headers} [(@code{this, size_t extent}) @arrow{} @code{int}]
Ensures that @code{extent} additional headers can
be stored in the @code{*this}. Returns zero on
and only on success.

@item @code{mds_message_read} [(@code{this, int fd}) @arrow{} @code{int}]
Reads the next message from the socket file descriptor
@code{fd} and stores it in @code{*this}. Returns zero
on success and non-zero on error or interruption. @code{*this}
should be destroyed using @code{mds_message_destroy} on
error but not on interruption. If @code{-2} is returned
@code{errno} will not have been set; @code{-2} indicates
that the message is malformated, which is a state that
cannot be recovered from.

@item @code{mds_message_compose_size} [(@code{const this}) @arrow{} @code{size_t}]
This function is to @code{mds_message_compose} as
@code{mds_message_marshal_size} is to
@code{mds_message_marshal}.

@item @code{mds_message_compose} [(@code{const this, char* restrict data}) @arrow{} @code{void}]
This function is similar to @code{mds_message_marshal}.
The only difference is that it will not store internal
data and instead create a message that can be broadcasted
in the display server message passing system.
@end table



@node mds-base
@chapter @file{mds-base}

@file{mds-base.c} and @file{mds-base.h} as an object
filepair whose purpose is similar to libmdsserver.
@file{mds-base} is compiled into all @command{mds}
servers and implements common procedures including
@code{main}. It also complements procedures that are
weakly defined, that is, if the server implementation
also defines them, the server implementations procedure
replaces @file{mds-base}'s implementation at
compile-time.

@file{mds-base} defines one function that you can
call from threads you create and functions that should
be implement depending on specified conditions:

@table @asis
@item @code{trap_signals} [(@code{void}) @arrow{} @code{int}]
Set up signal traps for all especially handled signals.
Returns zero on and only on success.
@end table

@file{mds-base} weakly defines functions that you can
replace if they do not suit your needs:

@table @asis
@item @code{parse_cmdline} [(@code{void}) @arrow{} @code{int}]
Parses command line arguments.
Returns zero on and only on success.

This function will parse the following options:

@table @option
@item --initial-spawn
It is the first time the server is spawn by its
spawner process.

@item --respawn
The server was respawned.

@item --re-exec
The server is re-executing.

@item --alarm=SECONDS
Kill the process after @var{SECONDS} seconds.
At most one minute.

@item --on-init-fork
Fork the process to detach it from its parent when
the server has been initialised.

@item --on-init-sh=COMMAND
When the server has been initialised, run the
command @var{COMMAND}.

@item --immortal
The server should to its best not to die. For example
do not die if @code{SIGDANGER} is received even if that
is the server's default action.
@end table

@item @code{connect_to_display} [(@code{void}) @arrow{} @code{int}]
Connects to the display.
Returns zero on and only on success.

@item @code{server_initialised} [(@code{void}) @arrow{} @code{int}]
This function should be called when the server has
been properly initialised but before initialisation
of anything that is removed at forking is initialised.
Returns zero on and only on success.

@item @code{signal_all} [(@code{int signo}) @arrow{} @code{void}]
This function should be implemented by the actual server
implementation if the server is multi-threaded. It sends
the singal @code{signo} to all threads except the current
thread.

@item @code{received_reexec} [(@code{int signo}) @arrow{} @code{void}]
This function is called when a signal that signals the
server to re-execute has been received. The exact
received signal is specified by the parameter @code{signo}.
When this function is invoked, it should set the variables
@code{reexecing} and @code{terminating} to a non-zero value.

@item @code{received_terminate} [(@code{int signo}) @arrow{} @code{void}]
This function is called when a signal that signals the
server to terminate has been received. The exact received
signal is specified by the parameter @code{signo}. When
this function is invoked, it should set the variable
@code{terminating} to a non-zero value.

@item @code{fork_cleanup} [(@code{int status}) @arrow{} @code{void}]
This function should be implemented by the actual server
implementation if the server has set
@code{server_characteristics.fork_for_safety} to be a
non-zero value. This function is called by the parent server
process when the child server process exits, if the server
has completed its initialisation. The parameter @code{status}
specifies the child process exit status as returned by
@code{waitpid}.
@end table

Additionally, @file{mds-base} expects the server implementation
to define and implement a set of functions:

@table @asis
@item @code{preinitialise_server} [(@code{void}) @arrow{} @code{int}]
This function will be invoked before @code{initialise_server}
(if not re-executing) or before @code{unmarshal_server}
(if not re-executing). Returns zero on and only on success.

@item @code{initialise_server} [(@code{void}) @arrow{} @code{int}]
This function should initialise the server. It not invoked
after a re-execution. Returns zero on and only on success.

@item @code{postinitialise_server} [(@code{void}) @arrow{} @code{int}]
This function will be invoked after @code{initialise_server}
(if not re-executing) or after @code{unmarshal_server} (if
re-executing). Returns zero on and only on success.

@item @code{marshal_server_size} [(@code{void}) @arrow{} @code{size_t}, pure]
Calculate and returns the number of bytes that will be stored
by @code{marshal_server}. On failure the server should call
@code{abort} or exit with failure status by other means.
However it should not be possible for this function to fail.
@code{marshal_server_size} must be pure.@footnote{That is,
define with and conforming to @code{__attribute__((pure))}.}.

@item @code{marshal_server} [(@code{char* state_buf}) @arrow{} @code{int}]
Marshal server implementation specific data into the buffer
@code{state_buf}. Returns zero on and only on success.

@item @code{unmarshal_server} [(@code{char* state_buf}) @arrow{} @code{int}]
Unmarshal server implementation specific data from the
buffer @code{state_buf} and update the servers state
accordingly. Returns zero on and only on success.

On critical failure the program should call @code{abort}
or exit with failure status by other means. That is, do not
let @code{reexec_failure_recover} run successfully, if it
unrecoverable error has occurred or one severe enough that
it is better to simply respawn.

@item @code{reexec_failure_recover} [(@code{void}) @arrow{} @code{int}]
Attempt to recover from a re-execution failure that has been
detected after the server successfully updated it execution
image. Returns zero on and only on success.

@item @code{master_loop} [(@code{void}) @arrow{} @code{int}]
Perform the server's mission. Returns zero on and only on success.
@end table

@file{mds-base} also defines a number of global variables.

@table @asis
@item @code{argc} [@code{int}]
Number of elements in @code{argv}.

@item @code{argv} [@code{char**}]
Command line arguments.

@item @code{is_respawn} [@code{int}]
Whether the server has been respawn rather than this
being the initial spawn. This will be at least as true
as @code{is_reexec}.

@item @code{is_reexec} [@code{int}]
Whether the server is continuing from a self-reexecution.

@item @code{is_immortal} [@code{int}]
Whether the server should do its best to resist event
triggered death.

@item @code{on_init_fork} [@code{int}]
Whether to fork the process when the server has been
properly initialised.

@item @code{on_init_sh} [@code{char*}]
Command the run (@code{NULL} for none) when the server
has been properly initialised.

@item @code{master_thread} [@code{pthread_t}]
The thread that runs the master loop.

@item @code{terminating} [@code{volatile sig_atomic_t}]
Whether the server has been signaled to terminate.

@item @code{reexecing} [@code{volatile sig_atomic_t}]
Whether the server has been signaled to re-execute.

@item @code{socket_fd} [@code{int}]
The file descriptor of the socket that is connected
to the server.
@end table

@file{mds-base} expects the server implementation to define
a variable that specifies how @file{mds-base} should behave:

@table @asis
@item @code{server_characteristics} [@code{server_characteristics_t}]
This variable should declared by the actual server
implementation. It must be configured before @code{main}
is invoked. That is, it should be configured by a
constructor. If it is configured at its definition,
it is configured by a constructor; that is normally
how you want to configured it.
@end table

@code{server_characteristics_t} @{also known as
@code{struct server_characteristics}@} is a packed
@footnote{That is, define with @code{__attribute__((packed))}.}
with the following fields:

@table @asis
@item @code{require_privileges} [@code{unsigned : 1}]
Setting this to zero will cause the server to drop
privileges as a security precaution.

@item @code{require_display} [@code{unsigned : 1}]
Setting this to non-zero will cause the server to connect
to the display.

@item @code{require_respawn_info} [@code{unsigned : 1}]
Setting this to non-zero will cause the server to refuse
to start unless either @option{--initial-spawn} or
@option{--respawn} is used.

@item @code{sanity_check_argc} [@code{unsigned : 1}]
Setting this to non-zero will cause the server to refuse to
start if there are too many command line arguments.

@item @code{fork_for_safety} [@code{unsigned : 1}]
Setting this to non-zero will cause the server to place
itself in a fork of itself when initialised. This can be
used to let the server clean up fatal stuff after itself
if it crashes. When the child exits, no matter how it
exits, the parent will call @code{fork_cleanup} and then
die it the same manner as the child.

@item @code{danger_is_deadly} [@code{unsigned : 1}]
Setting this to non-zero without setting a signal action
for @code{SIGDANGER} will cause the server to die if
@code{SIGDANGER} is received. It is safe to set both
@code{danger_is_deadly} and @code{fork_for_safety} to
non-zero, during the call of @code{server_initialised}
the signal handler for @code{SIGDANGER} in the parent
process will be set to @code{SIG_IGN} independently of
the value of @code{danger_is_deadly} if
@code{fork_for_safety} is set to non-zero.

This setting will be treated as set to zero if
@option{--immortal} is used.
@end table



@node GNU Free Documentation License
@appendix GNU Free Documentation License
@include fdl.texinfo

@bye