\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 @center `To me, writing a monolithic system in 1991 is a truly poor idea.' @c Well, here we are 23 years later and we are still @c doing, but where it is even easier not to. @vskip 0pt plus 1filll @insertcopying @end titlepage @contents @menu * Overview:: Brief overview of @command{mds}. * Architecture:: Architectural overview of @command{mds}. * Application Design:: Guildlines for your applications. * Protocol:: The @command{mds} procotol. * Utilities:: About @command{mds} utilities. * Servers:: About @command{mds} servers. * Protocols:: @command{mds} procotols. * libmdsserver:: Overview of @command{libmdsserver}. * mds-base.o:: Overview of @file{mds-base.o}. * Keyboard Codes:: Scancodes and keycodes. * Keyboard Layouts:: Writing and compiling keyboard layouts. * Discussion:: Discussion on display server-architecture. * 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 --- @code{mds} is comprised of many small servers, each exchangable and responsible for one thing. @command{mds}'s 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, removed, updated 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-execute 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-execute 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-execute, 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-execute but it is not worth it as it as no reason to re-execute, 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 Application Design @chapter Application Design When creating graphical @command{mds} applications, there are some guildlines you should follow. @itemize @bullet @item @b{Do not create client side decoration}. Some users do not want decorations or wants minimal decorations. Windows should look similar, server side decoration helps ensure this. Your client side decorations may not meet the requirements the users have. For example, your client side decoration may only support minimise, maximise and close, whilst the user may also want, as provided by her decoration server, stick, shade and always on top. And it should be sufficient to configure your decorations once rather once for every toolkit. Additionally, because of oversight from developers, client side decoration tends to work poorly with tiling window managers. @item @b{Do not remember size and position}. Some users do not want their programs to remember their size and position. There is also a risk that your mechanism for implementing this does not account for the possibility that outputs may have been removed, resized or relocated. The @command{mds-posmem} be used if the user wants programs to start where they were closed the last time they were closed. @end itemize @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. * Portability:: Restrictions for portability on protocols. @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{:}, where @code{} 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{SIGRTMIN + 1}. 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{}. 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{}, 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 Portability @section Portability For optimal portability, there are some restrictions on protocols. @itemize @bullet{} @item Because C allows unsigned integers to be encoded as either sign and magnitude, one's complement or two's complement@footnote{GCC only allows two's complement}, the minimum value of any signed value with a fixed bit-size is the negative of its maximum value, that is, the minimum value @code{int16_t} is to be assumed to be @code{-INT16_MAX} (@math{-32767}) rather than @code{INT16_MIN} (@math{-32768} with two's complement.) @item Integer that are not especially encoded must not be larger than 64-bits if they use fixed bit-size. If, for example, @code{size_t} is 128-bits on your platform but you are using a language that only have native integers up to 64-bits you must use arbitrary size integers or otherwise make sure that the value can be properly stored and used. @item Integer 64-bits that are not especially encoded must not be unsigned if the bit-size is fixed. @item Native endianness when a endianness is choosen. Do not assume big endianness, but the same endianness that appear on the same machine when using C. @item All strings musts be encoded in UTF-8 without any NUL-character unless expressive permission is given. NUL-character may be encoded either using a zero byte or using Modified UTF-8, where it is encoded using two bytes. Which is used is selected in the protocol, however headers and their values must not include NUL-characters. No character may be encoded with more bytes than necessary. @item The new line-character is always LF (@code{'\n'}, 10, line feed) and never a combination of LF and any other character, or multiple LF:s. @end itemize @node Utilities @chapter Utilities @menu * mds-respawn:: The server immortality protocol. * mds-reg:: The registry control command. * mds-clip:: The clipboard control command. * mds-screenshot:: The screenshot utility. * mds-slay:: The process killing utility. * mds-chvt:: Utility for switching virtual terminal. * mds-kbdc:: The keyboard layout compiler. * 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 mds-reg @section @command{mds-reg} @command{mds-reg} is a utility that can be used to list, available protocols provided by running servers. It can also wait for a set of protocols to become available. To list all available protocols run @command{mds-reg --list}. And to wait for the protocol @code{foo} run @command{mds-reg --wait=foo}. To also wait for the protocol @code{bar} run @command{mds-reg --wait=foo,bar} or @command{mds-reg --wait=foo --wait=bar}. Both of these styles can be mixed if you want to wait for even more protocols. @node mds-clip @section @command{mds-clip} @command{mds-clip} is a utility that can be used to review the clipboards on the display and manipulate them. @command{mds-clip} recognises the following options: @table @option @item --push Push non-option arguments from the command line into the clipboard. @item --expire=SECONDS Can be used with @option{--push}. The clip will not removed after @var{SECONDS} seconds. @item --pop Pop items from the clipboard whose indices are listed in the command line as non-option arguments. The first index is 1. @item --clear Pop all items in the clipboard. @item --list List items in the clipboard whose indices are listed in the command line as non-option arguments. The first index is 1. If no indicies are specified, all clips will be listed. @item --size Print the size of the clipboard, the number of clips in the clipboard. @item --capacity Print the capacity of the clipboard, the number of clips the clipboard can hold. If both @option{--size} and @option{--capacity} is used, the size will be printed on the first line and the capacity will be printed on the second line. @item --resize=CAPACITY Change the capaciy of the clipboard to @var{CAPACITY} clips. @item --stdin Can be used with @option{--push}. If used, the clip that should be placed on the top of the clipboard stack should be read from stdin. @item --delimiter=DELIMITER Can be used with @option{--stdin} or @option{--list}. If used with @option{--stdin}, an line containing only @var{DELIMITER} will delimit two values that should be placed in the clipboard. If used with @option{--list}, a line containing only @var{DELIMITER} will delimit two values in the output. The default delimiter for @option{--list} is an empty line. @item -1 Use the primary clipboard, that is, the text copy clipboard. This is the default clipboard. @item -2 Use the secondary clipboard, that is, the text selection clipboard. @item -3 Use the tertiary clipboard, that is, the non-text copy clipboard. @end table @node mds-screenshot @section @command{mds-screenshot} @command{mds-screenshot} is a simple utility, and reference implementation thereof, that can take a screeenshot of either the display, a monitor, or a window with or without its decorating window. It can also include or exclude the rat cursor or gamma ramps. @command{mds-screenshot} recognises the following options: @table @option @item --monitor Take screenshot of the monitor. The rat will be used to select monitor. @item --monitor=WINDOW_ID Take screenshot of the monitor whose root window's window ID is @var{WINDOW_ID} or has another window in it whose window ID is @var{WINDOW_ID}. @item --embed Take a screenshot of an embedded window. The rat will be used to select window. @item --embed=WINDOW_ID Take a screenshot of an embedded window whose window ID is @var{WINDOW_ID}. @item --window Take a screenshot a window. The rat will be used to select window. @item --window=WINDOW_ID Take a screenshot of a window whose window ID is @var{WINDOW_ID}. @item --decoration Include the window's decoration, if used together with @option{--window}. Ignored if used without @option{--window}. @item --cursor Include the rat cursor in the screenshot. @item --gamma Include the effects of gamma ramps in the screenshot. @item --low-gamma=LOW_PRIORITY Include the effects of gamma ramps with a priority above @var{LOW_PRIORITY} in the screenshot. @item --high-gamma=HIGH_PRIORITY Include the effects of gamma ramps with a priority below @var{HIGH_PRIORITY} in the screenshot. If used together with @option{--low-gamma=LOW_PRIORITY}, the range [@var{LOW_PRIORITY}, @var{HIGH_PRIORITY}] will be used. @end table Optionally, you can add a non-option argument that specifies the pathname of the saved file. If neither @option{--monitor}, @option{--embed} or @option{--window} is used, a screenshot will be taked of the display. That is, all monitors. In case of mirrored outputs, one of the potential outputs will be selected arbitrarily if @option{--gamma}, @option{--low-gamma} or @option{--high-gamma} is used. If neither is used, the screenshot will be identical for all mirrored outputs. @node mds-slay @section @command{mds-slay} @command{mds-slay} a utility that can be used to kill a process by it window or identify the window ID of a window. @command{mds-slay} recognises the following options: @table @option @item --embed Kill an embedded window. The rat will be used to select window. @item --embed=WINDOW_ID Kill an embedded window whose window ID is @var{WINDOW_ID}. @item --window Kill a window. The rat will be used to select window. @item --window=WINDOW_ID Kill a window whose window ID is @var{WINDOW_ID}. @item --signal=SIGNAL Send the signal @var{SIGNAL} to the process owning the selected window. @item --no-signal Do not send a signal; only identify the window. @item --keep-cursor Do not change the cursor to a kill cursor. @item --print The the ID of the selected window. @end table @node mds-chvt @section @command{mds-chvt} @command{mds-chvt} is a utility similar to the command @command{chvt} from the @command{kbd} project. However, @command{mds-chvt} has setuid and therefore does not require root permissions, but it will only request a virtual terminal switch if the display server's virtual terminal is in the foreground. @command{mds-chvt} recognises the following options: @table @option @item --switch=VT Switch to the virtual terminal with the index @var{VT}. @end table @node mds-kbdc @section @command{mds-kbdc} @command{mds-kbdc} is the program used to compile keyboard layouts and compose tables. TODO how to use mds-kbdc @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 This is however seldom necessary as @command{mds-reg} can often be used instead, with more abstraction as you would only need to specify what servers need to wait for, not what they provide. 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, @command{mds-server} and the kernel, @command{mds}, 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-drag:: The @command{mds-drag} 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. * mds-colour:: The @command{mds-colour} server. * mds-retro-crt:: The @command{mds-retro-crt} server. * mds-state:: The @command{mds-state} server. * mds-focus:: The @command{mds-focus} server. * mds-kill:: The @command{mds-kill} server. * mds-screensaver:: The @command{mds-screensaver} server. * mds-compositor:: The @command{mds-compositor} server. * mds-crtc:: The @command{mds-crtc} server. * mds-dri:: The @command{mds-dri} server. * mds-fb:: The @command{mds-fb} server. * mds-mds:: The @command{mds-mds} server. * mds-meta:: The @command{mds-meta} server. * mds-seat:: The @command{mds-seat} server. * mds-nest:: The @command{mds-nest} server. * mds-host:: The @command{mds-host} server. * mds-remote:: The @command{mds-remote} server. * mds-xmds:: The @command{mds-xmds} server. * mds-wmds:: The @command{mds-wmds} server. * mds-mmds:: The @command{mds-mmds} server. * mds-mdsx:: The @command{mds-mdsx} server. * mds-mdsw:: The @command{mds-mdsw} server. * mds-mdsm:: The @command{mds-mdsm} server. * mds-posmem:: The @command{mds-posmem} server. * mds-decorator:: The @command{mds-decorator} server. * mds-tile:: The @command{mds-tile} server. * mds-stack:: The @command{mds-stack} server. * mds-workspace:: The @command{mds-workspace} server. * mds-tray:: The @command{mds-tray} 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. By default @command{mds-vt} will select the next available virtual terminal for the display server. You can override this behaviour by exporting a value to the environment variable @env{XDG_VTNR}. The value must be a decimal integer of a valid virtual terminal index@footnote{Which is the same thing as a valid TTY index.}. To select the virtual terminal the display was started from you can use the following code in your @file{~/.mdsinitrc}: @example export XDG_VTNR="$(fgconsole)" @end example @command{fgconsole} is a part of the @command{kbd} package. @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-drag @section @command{mds-drag} @command{mds-drag} is the server that implements drag-and-drop support. @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 `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 `x' to press `x' a selected number of times with a short selectable delay between them; or `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. In 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. In 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 @command{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. This server is intended for testing that interfaces are suitable for people with defective colour vision. @node mds-colour @section @command{mds-colour} @command{mds-colour} is a server that implements colour names, such as system colours and generic names, for example `red', whose exact colour can be configured by the user. A terminal written for @command{mds} whould look up colours such as `red' and `light red' and get the colours the terminal should use by default. Nothing is to be assumed for such colours, not even that `light red' is in fact lighter than `dark red', or that `red' is in fact `red', only that it is the colour the user wants to see when a colour is supposed to be `red'. @command{mds-colour} will notify clients when a colour has been reconfigured, added or removed. @command{mds-colour} is also responsible for informing clients on which two colours clients should use and how to dither them (by percent, not by pattern). This is useful if only 16-bit colours can be used, or if only 24-colour can used but gradients between for example sRGB(255, 255, 255) and sRGB(254, 254, 254) is to be drawn. @command{mds-colour} is gamma ramp-aware. For example, if for the red channel, 0 is mapped to 0, 1 is mapped to 3, 2 is mapped 2 and 3 is mapped to 1, but 1 and 3 requires dithering, then if 3 is requested, @command{mds-colour} will tell the client to dither 0 and 2 with 50 %, which should generate 1, but 1 and 3 has been swapped. @node mds-retro-crt @section @command{mds-retro-crt} @command{mds-retro-crt} is a server that applies filters used in the terminal emulator @command{cool-retro-term} to the whole display. @node mds-state @section @command{mds-state} @command{mds-state} is the server that keeps tracks of the windows' state. @node mds-focus @section @command{mds-focus} @command{mds-focus} is the server focuses windows and windows' components. @node mds-kill @section @command{mds-kill} @command{mds-kill} is a server that can be used to send signals to processes by identifying them by their windows. This server can also be used to simply identify the process that owns a window. @node mds-screensaver @section @command{mds-screensaver} @command{mds-screensaver} is a server that can be used to start a screensaver or deactive monitors when the input devices has not be used for a period of time provided that no client has disabled this. It is capable of deactiving single monitors or start a screensaver on single monitors rather than all monitors. @node mds-compositor @section @command{mds-compositor} @command{mds-compositor} is the server that composes the output. It takes output of all windows and arranges it to one image per monitor and sends it to the presentation servers, such as @command{mds-dri} and @command{mds-fb}. @node mds-crtc @section @command{mds-crtc} @command{mds-crtc} is the server that identifies CRTC:s and provide access to them. @node mds-dri @section @command{mds-dri} @command{mds-dri} is a server that displays content using the Direct Rendering Infrastructure. @node mds-fb @section @command{mds-fb} @command{mds-fd} is a server that displays content using framebuffers. @node mds-mds @section @command{mds-mds} @command{mds-mds} is a server that displays content using another @command{mds} window. It creates a window that emulates a monitor. @node mds-meta @section @command{mds-meta} @command{mds-meta} is a meta-display server. It creates or joins a named meta-display server, and creates and alternative values for @env{MDS_DISPLAY}. Any server connecting to this alternative @env{MDS_DISPLAY} connects to this meta-display server. This can be used to make servers shared between display server instances. @command{mds-meta} uses the environment variable @env{MDS_METADISPLAY} to acquire the name of the meta-display server instance it should join or create. If @env{MDS_METADISPLAY} has not been set it is treated as having an empty string for its value which is a valid meta-display server instance name. @command{mds-meta} works by connecting to the running display server instance, the display, and create a new display server instance, the metadisplay. Messages passed via the metadisplay's socket is forward to the display, and messages passed to via the display to @command{mds-meta} is send to the appropriate server. @command{mds-meta} manages interception in the same way as @command{mds-server} and @command{mds-remote}. If @command{mds-meta} creates a new metadisplay, rather than joining an existing metadisplay, it will spawn @file{~/.mdsmetainitrc} to let you start the shared servers. An interesting property of @command{mds-meta} is that it can be used to share servers across display servers on multiple computers. For example, if you start @command{mds-host} and @command{mds-clipboard} inside the metadisplay on your central computer, displays started on other servers can run @command{mds-remote} to connect to the metadisplay so that all computers share the same clipboard. However, this network will be centralised and not distributed, so it is not perfect. @node mds-seat @section @command{mds-seat} @command{mds-seat} is a server that enables seat-sandboxing. It can be used to place two users on the same machine without them interfering with each others monitors and input devices. Servers started below @command{mds-seat} become shared and servers started above @command{mds-seat} become seat-private. @command{mds-seat} can filter messages from shared servers so only the appropriate seat receives them. @node mds-nest @section @command{mds-nest} @command{mds-nest} is a server that creates a new @command{mds} instance inside another @command{mds} instance. A display server inside another display server. @node mds-host @section @command{mds-host} @command{mds-host} is a server that enables servers like @command{mds-remote} running on remote machines to connect to the local machine and its display server. @node mds-remote @section @command{mds-remote} @command{mds-remote} is a server that enables you to connect extend a remote @command{mds} with your local machine. This can be used to make a display server instance span multiple computers including its monitors and input devices. @node mds-xmds @section @command{mds-xmds} @command{mds-xmds} is a server that translates X.org calls to @command{mds} calls. It can be used to run X.org-only programs inside @command{mds}. @node mds-wmds @section @command{mds-wmds} @command{mds-wmds} is a server that translates Wayland calls to @command{mds} calls. It can be used to run Wayland-only programs inside @command{mds}. @node mds-mmds @section @command{mds-mmds} @command{mds-mmds} is a server that translates Mir calls to @command{mds} calls. It can be used to run Mir-only programs inside @command{mds}. @node mds-mdsx @section @command{mds-mdsx} @command{mds-mdsx} is a server that translates @command{mds} calls to X.org calls. It can be used to enable @command{mds} specific programs to run inside the X.org display servers. @node mds-mdsw @section @command{mds-mdsw} @command{mds-mdsw} is a server that translates @command{mds} calls to Wayland calls. It can be used to enable @command{mds} specific programs to run inside the Wayland display servers. @node mds-mdsm @section @command{mds-mdsm} @command{mds-mdsm} is a server that translates @command{mds} calls to Mir calls. It can be used to enable @command{mds} specific programs to run inside the display server Mir. @node mds-posmem @section @command{mds-posmem} @command{mds-posmem} is a server that remembers where window's were positioned and their size, and moves and resizes them accordingly when they are created. @node mds-decorator @section @command{mds-decorator} @command{mds-decorator} is a server that provides a simple, reference implementation of a, window decorator. @node mds-tile @section @command{mds-tile} @command{mds-tile} is a server that provides a simple, reference implementation of a, tiling window manager. @node mds-stack @section @command{mds-stack} @command{mds-stack} is a server that provides a simple, reference implementation of a, stack window manager. @node mds-workspace @section @command{mds-workspace} @command{mds-workspace} is a server that provides simple, reference implementation of, workspaces. @node mds-tray @section @command{mds-tray} @command{mds-tray} is a server that provides a simple, reference implementation of a, status icon tray. @node Protocols @chapter Protocols @menu * Infrastructure Protocols:: Infrastructure protocols. * Virtual Terminal Protocols:: Virtual terminal protocols. * Keyboard Protocols:: Keyboard protocols. * Clipboard Protocols:: Clipboard protocols. * Status Icon Protocols:: Status icon protocols. * Colour Protocols:: Colour protocols. * Miscellaneous Protocols:: Miscellaneous protocols. @end menu @node Infrastructure Protocols @section Infrastructure Protocols @menu * assign-id:: Assign new ID to client, or fetch current ID. * intercept:: Sign up for reception of message. * register:: Register availability of a command for which you implement a service. * reregister:: Request for reregistration for available commands. * error:: Notify a client about a request failure. @end menu @node assign-id @subsection assign-id @table @asis @item Identifying header: @code{Command: assign-id} @item Action: Assign new ID to client, or fetch current ID. @item Purpose: Assigning ID to clients so server can respond to that client. @item Compulsivity: Manditory, part of the core infrastructure. @item Reference implementation: @command{mds-server} @end table @node intercept @subsection intercept @table @asis @item Identifying header: @code{Command: intercept} @item Action: Sign up for reception of message. @item Optional header: @code{Stop} Stop reception of messages if the value for the header @code{Stop} is @code{yes}. @item Optional header: @code{Priority} Signed 64-bit integer of reception priority (reversed of order). @item Optional header: @code{Modifying} Send message asynchronously and await modification if the value for the header @code{Modifying} is @code{yes}. @item Optional header: @code{Length} Length of the message. @item Message: List of headers and header--value-pairs that qualifies a message for reception, all messages qualifies if this list is empty. @item Purpose: Filter received message for clients and servers. @item Purpose: Assigned interception order for modification of messages. @item Compulsivity: Manditory, part of the core infrastructure. @item Reference implementation: @command{mds-server} @end table @node register @subsection register @table @asis @item Identifying header: @code{Command: register} @item Action: Register availability of a command for which you implement a service. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Conditionally required header: @code{Length} Length of the message. Required if @code{Action: list} is included in the headers. @item Optional header: @code{Action} @table @code @item remove Remove availability from registry if the value of the header @code{Action} is @code{remove}. @item wait Wait until listed commands are available if the value of the header @code{Action} is @code{wait}. However if a protocol becomes unavailable during this wait period it will still be counted as available for this wait action. @item list Send a list of availability commands if the value of the header @code{Action} is @code{list}. @end table @item Conditionally optional header: @code{Time to live} The maximum number of seconds to wait. Available and optional if @code{Action: wait} is included in the headers. @item Message: List of values for the header @code{Command} that you implement. @item Purpose: Identify supported display server operations. @item Purpose: Initialisation process synchronisation. @item Compulsivity: Highly recommended, programs may stall a bit from time to time without it, or at initialisation depending on the program's implementation. @item Reference implementation: @command{mds-registry} @end table @node reregister @subsection reregister @table @asis @item Identifying header: @code{Command: reregister} @item Action: Request that all servers resends @code{Command: register} with either @code{Action: add} or without the @code{Action} header (does the same thing.) @item Purpose: Rebuild registry created with @code{Command: register} if the registry server crashes. @item Compulsivity: Highly recommended, programs may think a protocol is not supported of the registry server crashes if you do not implement this in your server. @item Reference implementation: @command{mds-registry}. @end table @node error @subsection error @table @asis @item Identifying header: @code{Command: error} @item Action: Notify a client about a request failure. @item Required header: @code{To} The ID of the client that send a request that failed. @item Required header: @code{In response to} The ID of the message whose request failed. @item Required header: @code{Error} The errno number of the error, 0 on success if the message was not an information query. The string ``custom'' can be used if there is not errno number, optionally followed by a blank space and a number that identifies the error, this number must be positive (not zero). @item Conditionally optional header: @code{Length} The length of the message. Available and optional if ``custom'' is used in the header @code{Error}. @item Message: Description of the error, single line, mid-sentence case, no punctuation in the end, must not be question but rather it must be a statement. @item Purpose: Enable keyboard layout servers to automatically set active locks when the server starts based on currently active LED:s. @item Compulsivity: Optional. @end table @node Virtual Terminal Protocols @section Virtual Terminal Protocols @menu * get-vt:: Get the index of the virtual terminal the server is display on. * configure-vt:: Reconfigure the virtual terminal the server is display on. * switching-vt:: Notify servers about an ongoing virtual terminal switch. @end menu @node get-vt @subsection get-vt @table @asis @item Identifying header: @code{Command: get-vt} @item Action: Get the index of the virtual terminal the server is display on. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Response: The server will response with the header @code{VT index} and the index of the virtual terminal the server is display on in decimal format. Additionally the server will respond with the header @code{Active} with the value @code{yes} if the VT is in the foreground or the value @code{no} if the VT is in the background. @item Purpose: Allow programs to be aware of whether the display is in the foreground or the background. @item Purpose: Allow programs to be aware of which VT the server is running on. @item Purpose: Allow programs to gain access of the TTY associated with the VT such that they can use ioctl and similar calls on that TTY. @item Compulsivity: Required. @item Reference implementation: @code{mds-vt} @end table @node configure-vt @subsection configure-vt @table @asis @item Identifying header: @code{configure-vt} @item Action: Reconfigure the virtual terminal the server is display on. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Optional header: @code{Graphical} @table @code @item yes Set the TTY graphical mode if the value of the header @code{Graphical} is @code{yes}. @item no Set the TTY text mode if the value of the header @code{Graphical} is @code{no}. @end table The server implementing this protocol should not set the TTY to text mode temporarily when switching TTY. It is up to the server that set the request for graphical mode to temporarily switch to text mode when switching TTY. @item Optional header: @code{Exclusive} @table @code @item yes The server may block other process from opening the TTY if the value of the header @code{Exclusive} is @code{yes}. @item no The server may not block other process from opening the TTY if the value of the header @code{Exclusive} is @code{no}. @end table The server implementing this protocol should keep a counter for how many servers have requested non-exclusive mode and only switch back to exclusive mode when that counter reaches zero @item Response: The server will response with a @code{Command: error}. @item Purpose: Allow presentation servers to enter and leave graphical mode. @item Purpose: Allow programs to gain access of the TTY associated with the VT such that they can use ioctl and similar calls on that TTY. @item Compulsivity: Required. @item Reference implementation: @code{mds-vt} @end table @node switching-vt @subsection switching-vt @table @asis @item Identifying header: @code{Command: switching-vt} @item Action: Notify servers about an ongoing virtual terminal switch. @item Required header: @code{Status} @table @code @item deactivating The kernel wants to place the display in the background if the value of the header @code{Status} is @code{deactivating}. @item activating The kernel wants to place the display in the foreground if the value of the header @code{Status} is @code{activating}. @end table @item Instructions: When a virtual terminal switch is requested the server implementing control VT switching involving the display's virtual terminal will get signaled by the kernel. Upon this signal the server should broadcast this command. All servers that need to release or acquire resouces should intercept this message with the possibility of modifying it. Once a server is ready for the VT to switch it should let the message pass to the next server by telling the master server that it is no modification to do. Once all servers are read for the switch the server that emitted this message should signal the kernel that it may switch VT. The server should detect this by setting up secondary contection to the display that intercepts this message. This connection should intercept this message with priority @math{-2^{62}}, all servers that need to perform actions before the switch takes place must have a priority higher than @math{-2^{62}}, preferably 0. @item Purpose: Allow servers to release resources when the user switch virtual terminal before the terminal actually changes and to reacquire resources when the virtual terminal become active again. @item Compulsivity: Required. @item Reference implementation: @code{mds-vt} @end table @node Keyboard Protocols @section Keyboard Protocols @menu * key-sent:: Announce a keyboard input event. * enumerate-keyboards:: List available keyboards. * keyboard-enumeration:: Response to @code{Command: enumerate-keyboards}. * set-keyboard-leds:: Activate and deactivate LED:s on a keyboard. * get-keyboard-leds:: List exisiting LED:s on a keyboard and their state. * keycode-map:: Remap keyboard keycodes and query current mapping. * new-keyboard:: Announce the existance of a new keyboard. * old-keyboard:: Announce the removal of an old keyboard. @end menu @node key-sent @subsection key-sent @table @asis @item Identifying header: @command{Command: key-sent} @item Action: Announce a keyboard input event. @item Required header: @code{Keyboard} Any string that uniquely identifies the keyboard. @table @asis @item Purpose: Enable multi-keyboard aware programs and give at least on keyboard per seat in a multi-seat environment. @item Note: mds-kkbd uses @code{kernel} to indicate that it uses the kernel and thus lumps together all keyboards. @end table @item Required header: @code{Released} @table @code @item yes The value of the header @code{Released} will be @code{yes} if the key was released. @item no The value of the header @code{Released} will be @code{no} otherwise, that is, held down or pressed. @end table Note: pause/break is automatically released directly after it has been pressed. This is feature built into keyboards and servers should not try to circumvent this. @item Required header: @code{Keycode} An unsigned 14-bit integer identifying the key, may be remapped. @item Optional header: @code{Scancode} Either an unsigned 7-bit integer or a single blank space separated trio of unsigned 7-bit integers, identifying the key. This is the scancode sent from the keyboard and optionally unified by the keyboard driver, however with the typed/released bit zeroed out. This may not be remapped. @item Optional header: @code{Modifiers} Single blank space separated list of active modifiers: @table @code @item shift Shift (level 2) @item ctrl Control @item alt Alternative/Option @item altgr Alternative Graphic (level 3) @item lvl* @code{*} may be any @math{2^n + 1} integer with @math{1 < n < 20}. @item super Super @item hyper Hyper @item ultra Ultra @item caps Caps (usually a lock key) @item num Num (usually a lock key) @item scrl Scroll (usually a lock key) @item top Top (historical) @item front Front (historical) @item greek Greek (historical) @item compose Compose (rare, it is usually a dead key) @end table Any key that has been locked should be prefix with @code{+}, if the key has been locked by nullified with non-lock modifier it should be prefixed with a @code{-}. If no modifier is active or has been nullified, @code{none} should be used. @item Optional header: @code{Key} A textual representation of the key that has been typed or released, as mapped by the keyboard layout. @table @code @item esc Escape @item f* F@code{*} where @code{*} is any integer. @item sysrq System Request/Print Screen @item scrl Scroll (lock) @item break Break/Pause @item backspace Backspace @item tab Tab @item return Return/Enter @item space Blank Space @item menu Application Menu @item ins Insert @item home Home @item pgup Page Up @item del Delete @item end End @item pgdown Page Down @item up Up Arrow @item left Left Arrow @item down Down Arrow @item right Right Arrow @item shift Shift (level 2) @item begin Begin (keypad 5 in nagivation mode) @item ctrl Control @item alt Alternative/Option @item altgr Alternative Graphic (level 3) @item lvl* @code{*} may be any @math{2^n + 1} integer with @math{1 < n < 20}. @item super Super @item hyper Hyper @item ultra Ultra @item caps Caps (usually a lock key) @item num Num (usually a lock key) @item scrl Scroll (usually a lock key) @item top Top (historical) @item front Front (historical) @item greek Greek (historical) @item compose Compose (usually a dead key) @item hexcompose Hex-Compose (usually a dead key) (Used to create aribitrary characters.) @item longhexcompose Long Hex-Compose (usually a dead key) (Variant of hexcompose for longer codepoints.) @item modelock Mode Lock @item letter * @code{*} may be any UTF-8 encoded letter. @end table Keys that lock/unlock a modifer should be suffixed with a blank space and a @code{lock}. If the key is a dead key (even the compose key) should use @code{dead} instead. A position, either @code{left}, @code{right}, @code{keypad} or an index, followed by a blank space, should prefix any key that occurs on multiple position on the keyboard, unless it only appears on the keypad once and once not on the keypad. Keys without any meaning should be identified as @code{unknown}. Modifiers and dead keys should not affect the value. @item Optional header: @code{Characters} UTF-8 encoded string that has been written. @item Purpose: Enable the user to use a keyboard, physical or on-screen. @item Purpose: Enable programs to send keys as part of a script or a reply of a recorded session. @item Compulsivity: Highly-recommended, a computer is as good as useless without a keyboard. @item Reference implementation: @command{mds-kkbd}, @command{mds-kbd} and @command{mds-keytrans} @end table @node enumerate-keyboards @subsection enumerate-keyboards @table @asis @item Identifying header: @command{Command: enumerate-keyboards} @item Action: List available keyboards. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Instructions: This message must be consumed by the first server that receives it and implements support for it, and then send out a @code{Command: keyboard-enumeration} populated with the keyboard it provide as named in the @code{Keyboard} header for protocols such as @code{Command: key-sent}. @item Purpose: Make it possible for clients to list all available keyboards so that can be configured individually. @item Compulsivity: Optional. @item Reference implementation: @command{mds-kkbd} and @command{mds-kbd} @end table @node keyboard-enumeration @subsection keyboard-enumeration @table @asis @item Identifying header: @command{Command: keyboard-enumeration} @item Action: Response to @code{Command: enumerate-keyboards}. @item Required header: @code{To} The ID received under @code{Client ID} header in the @code{Command: enumerate-keyboards} message that triggered this message to be broadcasted @item Required header: @code{In response to} The ID received under the @code{Message ID} header in the @code{Command: enumerate-keyboards} message that triggered this message to be broadcasted. @item Required header: @code{Length} Length of the message. @item Message: New line separated list of available keyboards. @item Instructions: All keyboard servers should listen for this message and append all keyboards it implement to the message once recieved. @item Purpose: Make it possible for clients to list all available keyboards so that can be configured individually @item Compulsivity: Required if you implement @command{Command: enumerate-keyboards}. @item Reference implementation: @command{mds-kkbd} and @command{mds-kbd} @end table @node set-keyboard-leds @subsection set-keyboard-leds @table @asis @item Identifying header: @command{Command: set-keyboard-leds} @item Action: Activate and deactivate LED:s on a keyboard. @item Required header: @code{Active} LED:s that should be turned on. If a LED is listed here but not in @code{Mask} that LED should be turned on if it is off, and turned off if it is on. The value is a single blank space separated list of LED:s: @table @code @item num Num lock @item caps Caps lock @item scroll Scroll lock @item compose Compose @end table Unsupported LED:s should be silently ignored. @item Required header: @code{Mask} LED:s listed here that do not appear in @code{Active} should be turned off. The value of this header follows the same rules as for @code{Active}. @item Optional header: @code{Keyboard} A string that identifies the keyboard that should be affected. If omitted all keyboard are affected. @item Purpose: Enable keyboard layout servers to activate and deactive LED:s on the keyboard to indicate active locks. @item Compulsivity: Optional. @item Reference implementation: @command{mds-kkbd}, @command{mds-kbd} and @command{mds-keytrans} @end table @node get-keyboard-leds @subsection get-keyboard-leds @table @asis @item Identifying header: @command{Command: get-keyboard-leds} @item Action: List exisiting LED:s on a keyboard and their state. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Required header: @code{Keyboard} A string that identifies the keyboard that should be affected. @item Response: The server implementing support for @code{Command: get-keyboard-leds} for the keyboard indicated by @code{Keyboard} should send a message back to the client indicated by rge @code{Client ID} header (using the @code{To} header) with the headers: @table @code @item Active List of currently turned on LED:s. @item Present List of LED:s that the server believes to be present on the keyboards. @end table Both of these headers followes the rules of the @code{Active} header under @code{Command: set-keyboard-leds}. @item Purpose: Enable keyboard layout servers to automatically set active locks when the server starts based on currently active LED:s @item Compulsivity: Recommended. Required if you implement support for @code{Command: set-keyboard-leds}. If you do not support this protocol servers and clients and stall when they try to get the active LED:s @item Reference implementation: @command{mds-kkbd}, @command{mds-kbd} and @command{mds-keytrans} @end table @node keycode-map @subsection keycode-map @table @asis @item Identifying header: @command{Command: keycode-map} @item Action: Remap keyboard keycodes and query current mapping. @item Required header: @code{Action} @table @code @item remap Remap keys if the value of the header @code{Action} is @code{remap}. @item reset Reset all mappings to identity mapping if the value of the header @code{Action} is @code{reset}. @item query Query mapping if the value of the header @code{Action} is @code{query}. @end table Each affected server will send a message format like that of @code{Action: remap} with current mapping that are not identity mappings. @item Optional header: @code{Keyboard} A string that identifies the keyboard that should be affected. If omitted all keyboard are affected. @item Conditionally required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. Required if @code{Action: query} is included in the headers. @item Conditionally optional header: @code{Length} The length of the message. Available and optional if @code{Action: remap} is included in the headers. @item Message: Each line contains contains two single space delimited numbers, the first number is the keycode as determined by the scancode, the second number is keycode that scancode should generate. For example, @code{1 1} resets Escape to be mapped to Escape, and @code{1 59} remaps Escape to F1, while @example 1 59 59 1 @end example swaps Escape and F1. @item Purpose: Enable the user to swap or replace keys on the keyboard. @item Purpose: Enable the user manually correct an incorrectly mapped keyboard. @item Compulsivity: Optional. @item Reference implementation: @command{mds-kbd} and @command{mds-kkbd} @end table @node new-keyboard @subsection new-keyboard @table @asis @item Identifying header: @command{Command: new-keyboard} @item Action: Announce the existance of a new keyboard. @item Required header: @code{Length} The length of the message. @item Message: List of strings that identifies the keyboards that have been added. @item Purpose: Enable servers and clients to detect new keyboards. @item Compulsivity: Recommended. @item Reference implementation: @command{mds-kbd} and @command{mds-kkbd} @end table @node old-keyboard @subsection old-keyboard @table @asis @item Identifying header: @command{Command: old-keyboard} @item Action: Announce the removal of an old keyboard. @item Required header: @command{Length} The length of the message. @item Message: List of strings that identifies the keyboards that have been removed. @item Purpose: Enable servers and clients to detect removal of keyboards. @item Compulsivity: Recommended. @item Reference implementation: @command{mds-kbd} @end table @node Clipboard Protocols @section Clipboard Protocols @menu * clipboard:: Read or manipulate a clipboard. * clipboard-info:: Clipboard event announcements. @end menu @node clipboard @subsection clipboard @table @asis @item Identifying header: @command{Command: clipboard} @item Action: Read or manipulate a clipboard. @item Required header: @code{Level} The clipboard level, an [1, 3] integer: @table @code @item 1 Text copied/pasted using the keyboard or a menu item. (This level is called `primary'.) @item 2 Text copied/pasted using the rat. (This level is called `secondary'.) @item 3 Data to begin with a line describing the data type. (This level is called `tertiary'.) @end table @item Required header: @code{Action} What to do with the clipboard: @table @code @item add Write the message to the clipboard if the value of the header @code{Action} is @code{add}. @item read Read the clipboard if the value of the header @code{Action} is @code{read}. @item clear Clear all entries on the selected level on the clipboard if the value of the header @code{Action} is @code{read}. @item set-size Shrink/grow the clipstack if the value of the header @code{Action} is @code{set-size}. @item get-size Read the size of the clipstack if the value of the header @code{Action} is @code{get-size}. In the reply, the server will send a message containing the headers: @table @code @item Size The configured maximum size of the clipstack. @item Used The number of elements currently in the clipstack. @end table @end table @item Conditionally required header: @code{Length} Length of the message. Required if @code{Action: add} is included in the headers. @item Conditionally required header: @code{Size} The maximum number of elements in the clipstack. Required if @code{Action: set-size} is included in the headers. @item Conditionally required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. Required if @code{Action: read} or @code{Action: read} is included in the headers, or if @code{Action: add} is included in the headers and if the header @code{Time to live} is included and has a value starting with @code{until-death}. @item Conditionally optional header: @code{Index} The index of the item in the clipstack, starting at 0. Available and optional if the @code{Action: read} is included in the headers. @item Conditionally optional header: @code{Time to live} The number of seconds the entry should be available before it is removed by the server, or: @table @code @item until-death Remove entry when the client closes. @item until-death # Remove entry when the client closes, or @code{#} seconds have elapsed. @item forever: Never remove it. (This is the default.) @end table The server will always remove the entry when either: @enumerate 1 @item it is at the bottom of the clipstack and a new entry is added to the clipstack, or @item @code{Action: clear} is issued for the clipstack. @end enumerate The entry will also be removed, unless @code{Time to live: forever} is used, if the server crashes or is re-executed. It is up to the implementation to choose when the removal actually takes place. For example, the reference implementation will pop entries that have timed out when a new entry is added, the reading on the clipstack is requested or the server is reexecuted, but another implement may choose to pop entires asynchronously using another thread or an alarm an pop when @code{SIGARLM} is received. Available and optional if the @code{Action: add} is included in the headers. @item Message: The content to add to the clipboard. @item Purpose: Enable the user to duplicate content from one process into another process without requiring those processes to be aware of eathother to any extent. @item Compulsivity: Optional. @item Reference implementation: @command{mds-clipboard} @end table @node clipboard-info @subsection clipboard-info @table @asis @item Identifying header: @command{Command: clipboard-info} @item Action: The clipboard server sends out some information about what it is doing, such as automatically removing entires. @item Included header: @code{Event} @table @code @item pop The value of the header @code{Event} is @code{pop} when an item in the clipstack has been removed. If the value header--value-pair is used the following headers will also be included in the message: @table @code @item Level The clipboard level that has been affected. @item Popped The index of the item in the clipstack that has been removed. @item Size The configured maximum size of the clipstack. @item Used The number of elements currently in the clipstack. @end table @item crash The value of the header @code{Event} is @code{crash} when the clipboard has been reset because of a software crash. @end table @item Purpose: Enable clients to get notification about changes to the clipboard, that cannot trivially derived from @command{Command: clipboard} @item Compulsivity: Optional add-on to the clipboard's functionallity. @item Reference implementation: @command{mds-clipboard} @end table @node Status Icon Protocols @section Status Icon Protocols @menu * add-tray-icon:: Add a status icons to the status icon tray. * update-tray-icon:: Change the status of a status icon. * tray-update:: Send updates about the status tray to the status icon. * new-tray:: Announce the existence of a new status icon trays. @end menu @node add-tray-icon @subsection add-tray-icon @table @asis @item Identifying header: @command{Command: add-tray-icon} @item Action: Add a status icons to the status icon tray. The client should keep in mind that there can be any number of trays available on the system: zero, one, two or three, …, and that it will get a response once from every tray. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Required header: @code{Package} The name of the package to which the program announced the icon belongs. @item Required header: @code{Icon ID} An ID of the icon that can be used identify the icon, icon ID:s are not unique, but the combination of a package and a icon ID should be unque and can be used to ignore already added icons and hide icons that the user has been configured to be hidden. @item Required header: @code{Title} A title describing the icon for the user, used to configured when icons should be hidden and shown among other configuration. @item Required header: @code{Icon} The name or pathname of an icon to use together with the title. @item Response: Recipients will respond with a message containing the headers: @table @code @item To Will contain the value of the @code{Client ID} from the message that triggered this response. @item In response to Will contain the value of the @code{Message ID} from the message that triggered this response. @item Message ID Will contain a value as described in @ref{Message Passing}. @item Socket Will contain an ID to where the icon should be embeded. @item Will send update The value of this header will be @code{yes} if this message will be followed by a @code{Command: tray-update} message. Otherwise the value will be @code{no}. @end table @item Purpose: Enable clients to add a small icon that displays the status of programs, particularly minimised programs and services. @item Compulsivity: Optional. @end table @node update-tray-icon @subsection update-tray-icon @table @asis @item Identifying header: @command{Command: update-tray-icon} @item Action: Change the status of a status icon. @item Required header: @code{Status} @table @code @item hide Hide the icon if the value of the @code{Status} header is @code{hide}. @item show Show the icon if the value of the @code{Status} header is @code{show}. @item active The icon is active if the value of the @code{Status} header is @code{active}. @item inactive The icon is inactive if the value of the @code{Status} header is @code{inactive}. @end table @item Purpose: Enable status trays to automatically hide inactive icons. @item Purpose: Hide icons without actually removing them. @item Compulsivity: Required if supporting @code{Command: add-tray-icon}, only @code{Status: hide} and @code{Status show} is required. @end table @node tray-update @subsection tray-update @table @asis @item Identifying header: @command{Command: tray-update} @item Action: Send updates about the status tray to the status icon. @item Required header: @code{Socket} Where the icon is embedded, used to identify the affected tray. @item Conditionally required header: @code{Max colour} The maximum colour component value, for example, if using 24-bit colour, which component will be 8-bit and the maximum value will be 255, this also applies to the alpha component. Required if either for the @code{Colour}-, @code{Foreground}- or @code{Alpha}-header are used. @item Conditionally required header: @code{Size} The width and height, in pixels, the icon should have. Required if the @code{Length}-header is used, otherwise this header is optional. @item Conditionally required header: @code{Has alpha} @table @code @item yes The message contains an alpha channel if the value of the @code{Has alpha} header is @code{yes}. @item no The message does not contain an alpha channel if the value of the @code{Has alpha} header is @code{no}. @end table Required if the @code{Length}-header is used. @item Conditionally required header: @code{Bytes} The number of bytes the subpixels used, for example, 24-bit colours will have this set to 1 because each subpixel has 8 bits, 48-bit colours will have this set to 2 because each subpixel has 16 bits Allowed values are: 1, 2, 4 and 8. These values are used used so that CPU:s with any endianness can be trivially used as the words sizes are guaranteed to be supported in C, and mixed/middle-endiannes gets complicated if we go outside this. Required if the @code{Length}-header is used. @item Conditionally optional/required header: @code{Colour} Single blank space-separated [0, @code{}] sRGB 3-tuple. Available and optional if the @code{Length}-header is not used. Required if the @code{Foreground}-header but not @code{Length}-header is used. @item Conditionally optional header: @code{Foreground} Single blank space-separated [0, @code{}] sRGB 3-tuple. @item Optional header: @code{Alpha} The opacity of the tray. @item Optional header: @code{Length} Length of the message. @item Optional header: @code{Use urgency} @table @code @item yes The icon tray may blink if the value of the @code{Use urgency} header is @code{yes}. @item no The icon tray may not blink if the value of the @code{Use urgency} header is @code{no}. @end table @item Message: Raw binary encoding of the background image, bytes are orders: row, pixel, channel (alpha, red, green, blue), subpixel value (native CPU encoding). The Alpha channel should be included but ignored if @code{Has alpha: no}, in such as it is best to set it to full. Example image with @code{Bytes: 2}, @code{Has alpha: no} and @code{Size: 3}: @example sRGB(x0102, 0, 0), sRGB(0, x0304, 0), sRGB(0, 0, x0506) sRGB(x0708, 0, 0), sRGB(0, x090A, 0), sRGB(0, 0, x0B0C) sRGB(x0D0E, 0, 0), sRGB(0, x0F10, 0), sRGB(0, 0, x1112) @end example Encoding of example image in hexadecimal representation: @example FFFF 0102 0000 0000 FFFF 0000 0304 0000 FFFF 0000 0000 0506 FFFF 0708 0000 0000 FFFF 0000 090A 0000 FFFF 0000 0000 0B0C FFFF 0D0E 0000 0000 FFFF 0000 0F10 0000 FFFF 0000 0000 1112 @end example Note that on a big-endian system this would be: @footnote{x86_64 computers are big-endian.} @example FF FF 02 01 0 0 0 0 FF FF 0 0 04 03 0 0 FF FF 0 0 0 0 06 05 FF FF 08 07 0 0 0 0 FF FF 0 0 0A 09 0 0 FF FF 0 0 0 0 0C 0B FF FF 0E 0D 0 0 0 0 FF FF 0 0 10 0F 0 0 FF FF 0 0 0 0 12 11 @end example It is up to the networking servers to translate the encoding between machines.@footnote{The host translates to big-endian unless they can confirm that they have the same endianness.} @item Purpose: Enable clients to be aware of the appearance of the tray, such as colours, transparency and background image. @item Purpose: Enable clients to be aware of how the user wants status icons to behave. @item Compulsivity: Optional. @end table @node new-tray @subsection new-tray @table @asis @item Identifying header: @command{Command: new-tray} @item Action: Announce the existence of a new status icon trays. @item Purpose: Allow clients to add their status icons to status icon trays that have been added to the display after those programs have started and attempted to add their icons. @item Compulsivity: Required if supporting @code{Command: add-tray-icon}. @end table @node Colour Protocols @section Colour Protocols @menu * get-gamma-info:: Query gamma ramp information. * get-gamma:: Query gamma ramps. * set-gamma:: Modify gamma ramps. @end menu @node get-gamma-info @subsection get-gamma-info @table @asis @item Identifying header: @command{Command: get-gamma-info} @item Action: Query gamma ramp information. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Required header: @code{CRTC} The output name for the CRTC of interest. @item Response: The server will response with a @code{Command: error} on error, unsuccess the server will respond with a message contain the headers: @table @code @item To Will contain the value of the header @code{Client ID} in the message that was received by the server. @item In response to Will contain the value of the header @code{Message ID} in the message that was received by the server. @item Cooperative Whether a server like @command{mds-coopgamma} is running. That is, if priorities and classes are respected. The value with be either @code{yes}, for cooperative, or @code{no}, for non-cooperative. @item Depth The bit-depth of the gamma ramps. Possible values are: 8, 16, 32 och 64. @item Red size The number of stops in the red gamma ramp. @item Green size The number of stops in the green gamma ramp. @item Blue size The number of stops in the blue gamma ramp. @item Gamma support Will have one of the following values: @table @code @item yes It is known that gamma ramps are supported. @item no It is known that gamma ramps are not supported. @item maybe It is now known whether gamma ramps are supported. @end table @end table If @code{Gamma support: no} is send in the response, the headers @code{Depth}, @code{Red size}, @code{Green size} and @code{Blue size} may be omitted. @item Purpose: Enable performance optimisation when manipulating gamma ramps. @item Compulsivity: Optional. Required if your implement support for @command{Command: get-gamma} or @command{Command: set-gamma}. @item Reference implementation: @command{mds-hwgamma}, @command{mds-swgamma}, @command{mds-coopgamma} and @command{mds-cursorgamma}. @end table @node get-gamma @subsection get-gamma @table @asis @item Identifying header: @command{Command: get-gamma} @item Action: Query gamma ramps. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Required header: @code{CRTC} The output name for the CRTC of interest. @item Required header: @code{Coalesce} Whether the received the full gamma ramp filter list, of the value is @code{yes}, rather than the result of them, of the value is @code{no}. @item Required header: @code{High priority} The upper bound of the priority range of the gamma ramps to received. This is a signed 64-bit integer. @item Required header: @code{Low priority} The lower bound of the priority range of the gamma ramps to received. This is a signed 64-bit integer. @item Response: The server will response with a @code{Command: error} on error, unsuccess the server will respond with a message contain the headers: @table @code @item Depth The bit-depth of the gamma ramps. Possible values are: 8, 16, 32 och 64. @item Red size The number of stops in the red gamma ramp. @item Green size The number of stops in the green gamma ramp. @item Blue size The number of stops in the blue gamma ramp. @item Tables The number of gamma ramp lookup tables that is included in the respone's message. This header will not necessarily be included if @code{Coalesce: yes} was used in the query, rather reference implementations will exclude it. @end table These headers are included so you can make sure the no metadata for gamma ramps have changed, which could happen if the user switches between hardware and software gamma ramps. The response will also contain a @code{Length} header and a message formatted in the same manner as for @command{Command. set-gamma} messages. That is, assuming as an example that the gamma ramp depth is 16 bits, @code{Coalesce: yes} was used in the query, the red ramp is (1, 2, 3, 4, 5, 6), the green ramp is (17, 18, 19, 20, 21, 22, 23) and the blue ramp is (33, 34, 35, 36, 37, 38, 39, 40) then the message will be (hexadecimal representation): @example 0001 0002 0003 0004 0005 0006 0011 0012 0013 0014 0015 0016 0017 0021 0022 0023 0024 0025 0026 0027 0028 @end example On a big-endian system this would be: @example 01 00 02 00 03 00 04 00 05 00 06 00 11 00 12 00 13 00 14 00 15 00 16 00 17 00 21 00 22 00 23 00 24 00 25 00 26 00 27 00 28 00 @end example However if @code{Coalesce: no} was used in the query, the message will include multiple gamma ramps lookup tables. These will be in the order they are applied, that is, highest priority first. The tables will be encoded in the same way as for @code{Coalesce: yes} and they with be included without any delimiter. However, each table will be prefixed with the priority and the class. The priority will be encoded in native binary format as an @code{int64_t} and the class will be encoded as a NUL-terminated UTF-8 string @item Purpose: Enable analysis and readings of the current gamma ramps. @item Compulsivity: Optional. Required if your implement support for @command{Command: get-gamma-info} or @command{Command: set-gamma}. @item Reference implementation: @command{mds-hwgamma}, @command{mds-swgamma}, @command{mds-coopgamma} and @command{mds-cursorgamma}. @end table @node set-gamma @subsection set-gamma @table @asis @item Identifying header: @command{Command: set-gamma} @item Action: Modify gamma ramps. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Required header: @code{CRTC} The output name for the CRTC of interest. @item Required header: @code{Priority} A signed 64-bit integer of the priority for the filter. gamma correction should use zero priority. It is preferable that search logical adjustment is sent with different priorities so other programs can insert filters between them. @item Required header: @code{Class} A UTF-8 string that identifies the filter. It should be formatted as @code{pkg::cmd::role}. @code{pkg} should be the package name the package was installed with on the system. @code{cmd} should be the basename of the command for the program. @item Required header: @code{Lifespan} The value may be one of the following: @table @code @item until-removal Remove the filter when @command{Lifespan: remove} is sent. @item until-death Remove the filter when the client dies. @item remove Remove the filter now. @end table @item Conditionally required header: @code{Length} The length of the message. Available and required if @code{Lifespan: remove} is not included in the message. @item Message: The gamma ramps in binary encoding. As an example, assume the gamma ramp depth is 16 bits, the red ramp is (1, 2, 3, 4, 5, 6), the green ramp is (17, 18, 19, 20, 21, 22, 23) and the blue ramp is (33, 34, 35, 36, 37, 38, 39, 40) then the message will be (hexadecimal representation): @example 0001 0002 0003 0004 0005 0006 0011 0012 0013 0014 0015 0016 0017 0021 0022 0023 0024 0025 0026 0027 0028 @end example Note that on a big-endian system this would be: @footnote{x86_64 computers are big-endian.} @example 01 00 02 00 03 00 04 00 05 00 06 00 11 00 12 00 13 00 14 00 15 00 16 00 17 00 21 00 22 00 23 00 24 00 25 00 26 00 27 00 28 00 @end example It is up to the networking servers to translate the encoding between machines.@footnote{The host translates to big-endian unless they can confirm that they have the same endianness.} The use of binary rather than text here is chosen to increase performance for programs that try the change the adjustments fluently. For programs similar to @command{xgamma} that sets the ramps once this is however unnessary. However it does simplify the program code as one would only need to write the ramps to the message without creating a string with all stops converted and then measure the length of that string. @item Response: The server will response with a @code{Command: error}. @item Instructions: For optimal flexibility a system may run a server such as @command{mds-hwgamma} that applies the gamma ramps, and a server such as @command{mds-coopgamma} to let multiple programs adjust the output with their open filters that stack up. In a configuration like this, @command{mds-coopgamma} will keep track of all filters and when a modification is made it sends the grand result to @command{mds-hwgamma}, that is, what the filters together produce. To do this, @command{mds-coopgamma} listens for @command{Command: set-gamma} with priority @math{2^{62}} and modifies the message so the payload is filled with the result rather than to single filter. This modified message is then received by @command{mds-hwgamma} that listens with priority zero and applies the gamma ramps. @command{mds-hwgamma} will ignore the @code{Priority} and the @code{Class} header, but it will respect the @code{Lifespan} header, therefore @command{mds-coopgamma} will always modify the value of the @code{Lifespan} header to @code{until-removal}. @item Purpose: Enable colour output correction such as gamma correction. @item Purpose: Enable colour output filters such colour temperature adjustments, colour invertion and dimming. @item Compulsivity: Optional. Required if your implement support for @command{Command: get-gamma-info} or @command{Command: get-gamma}. @item Reference implementation: @command{mds-hwgamma}, @command{mds-swgamma}, @command{mds-coopgamma} and @command{mds-cursorgamma}. @end table @node Miscellaneous Protocols @section Miscellaneous Protocols @menu * echo:: Echo back a message. * kill:: The window killing protocol. @end menu @node echo @subsection echo @table @asis @item Identifying header: @command{Command: echo} @item Action: Echo back a message. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Optional header: @code{Length} Length of the message. @item Message: Message to echo. @item Purpose: Debugging and testing. @item Purpose: Network heartbeat. @item Compulsivity: Recommended for network enabled servers. @item Reference implementation: @command{mds-echo} @end table @node kill @subsection kill @table @asis @item Identifying header: @command{Command: kill} @item Action: Kill and identify processes based on the their windows. @item Required header: @code{Client ID} Your ID, provided by the @code{ID assignment} header in response to a @code{Command: assign-id} header. @item Required header: @code{Window ID} The ID of the window whose owning process should be identified or signaled. @item Required header: @code{Signal} A numerical value of the signal to send to the process. It is up to networking protocols to translate these numbers of the display spans multiple operating systems. The signal zero can usually be used if no signal is to be sent, this is however dependent on he operating system. @item Response: The server will respond with a @command{Command: error} message. In this message the server all include an ad-hoc header: @code{Process ID}. Its value will be the ID of the process that owns the window. @item Purpose: Identify and send signal to processes by refering to them by one of their windows. @item Compulsivity: Optional. @item Reference implementation: @command{mds-kill} and @command{mds-slay} @end table @node libmdsserver @chapter libmdsserver libmdsserver is library written for the reference implementation of the @command{mds} servers. llibmdsserver 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{} 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{} defines any missing signal name: currenly @code{SIGDANGER} and @code{SIGUPDATE}, and by inclusion of @file{}, 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 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-execute the server. If @code{prepare_reexec} failed or has not been called, @code{argv[0]} will be used as a fallback. This functions has three input parameters: @table @code @item argc The number of elements in @code{argv}. @item argv The command line arguments. @item reexeced Whether the server has previously been re-executed @end table This function only returns on failure. @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}. @item @code{verify_utf8}[(@code{const char* string, int allow_modified_nul}) @arrow{} @code{int}] Checks whether a NUL-terminated string's encoding matches UTF-8. This function will reject the string if it does not use the shorted possible byte-combination for each character. However, if @code{allow_modified_nul} is set, it will allow @code{192 128} in place of @code{0} for a NUL-character.@footnote{Remember @code{0} is used to terminated the string, but @code{192 128} is not.} This function returns zero if the @code{string} is properly formatted, and @code{-1} otherwise. @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 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 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 defines a hash table. @item @code{fd_table_t} @{also known as @code{struct fd_table}@} In the header file @file{}, 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 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{} 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{} 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{}, @file{} and @file{} 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{}. 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.o @chapter @file{mds-base.o} @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_danger} [(@code{int signo}) @arrow{} @code{void}] This function is called when a signal that signals the system is running out of memory has been received. The exact received signal is specified by the parameter @code{signo}. When this function is invoked, the server should free up all memory it can spare. When this function is invoked, it should set the variable @code{danger} to a non-zero value. If @code{server_characteristics.danger_is_deadly} is set, this function will never be called. @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{danger} [@code{volatile sig_atomic_t}] Whether the server has been signaled to free unneeded memory. @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 Keyboard Codes @chapter Keyboard Codes Keyboard servers receive scancodes from keyboard drivers. A scancode can either be comprised of one byte or three bytes. In each byte, the most significant bit (assuming unsigned bytes) is ignore, however for it first byte in the scancode it signifies whether the key was released: it is set of the key is released, and not set if the key was pressed or is being held down. A scancode is comprised of three bytes if the lower 7-bits of the first byte is are all cleared, and the highest bit in the two following bytes are set. Ignoring the most significant bit in all bytes, the keycode is the value of the byte if the scancode is a single byte scancode. If the scancode is comprised of three bytes, the first byte is ignored and the keycode is @math{a \cdot 128 + b} where @math{a} is the value of the second byte and @math{b} is the value of the third byte. @menu * 105-keys Keycodes:: List of keycodes for 105-keys keyboards. @end menu @node 105-keys Keycodes @section 105-keys Keycodes This is a list of keyboards for the 105-keys keyboards, using QWERTY-layout for reference. @table @asis @item @code{1} @kbd{Escape} key @item @code{2}--@code{11} Keys: @kbd{1}, @kbd{2}, @kbd{3}, @kbd{4}, @kbd{5}, @kbd{6}, @kbd{7}, @kbd{8}, @kbd{9}, @kbd{0} @item @code{12} Key right of @kbd{0}. @item @code{13} Key left of @kbd{backspace} @item @code{14} @kbd{Backspace} key @item @code{15} @kbd{Tab} key @item @code{16}--@code{25} Keys: @kbd{q}, @kbd{w}, @kbd{e}, @kbd{r}, @kbd{t}, @kbd{y}, @kbd{u}, @kbd{i}, @kbd{o}, @kbd{p} @item @code{26} Key right of @kbd{p}, once removed @item @code{27} Key right of @kbd{p}, twice removed @item @code{28} @kbd{Return} key @item @code{29} Left @kbd{control} key @item @code{30}--@code{38} Keys: @kbd{a}, @kbd{s}, @kbd{d}, @kbd{f}, @kbd{g}, @kbd{h}, @kbd{j}, @kbd{k}, @kbd{l} @item @code{39} Key right of @kbd{l}, once removed @item @code{40} Key right of @kbd{l}, twice removed @item @code{41} Key left of @kbd{1} @item @code{42} Left @kbd{shift} key @item @code{43} Key right of @kbd{l}, three times removed @item @code{44}--@code{50} Keys: @kbd{z}, @kbd{x}, @kbd{c}, @kbd{v}, @kbd{b}, @kbd{n}, @kbd{m} @item @code{51} Key right of @kbd{m}, once removed @item @code{52} Key right of @kbd{m}, twice removed @item @code{53} Key right of @kbd{m}, three times removed @item @code{54} Right @kbd{shift} key @item @code{55} @kbd{Multiply} key on the keypad @item @code{56} @kbd{Alternative} key @item @code{57} @kbd{Space} key @item @code{58} @kbd{Caps lock} key @item @code{59}--@code{68} Keys: @kbd{F1} through @kbd{F10} @item @code{69} @kbd{Num lock} key @item @code{70} @kbd{Scroll lock} key @item @code{71}--@code{73} @kbd{7}, @kbd{8}, @kbd{9} keys on the keypad @item @code{74} @kbd{Minus} key on the keypad @item @code{75}--@code{77} @kbd{4}, @kbd{5}, @kbd{6} keys on the keypad @item @code{78} @kbd{Plus} key on the keypad @item @code{79}--@code{82} @kbd{1}, @kbd{2}, @kbd{3}, @kbd{0} keys on the keypad @item @code{83} @kbd{Comma} key on the keypad @item @code{86} Key left of @kbd{z} @item @code{87} @kbd{F11} key @item @code{88} @kbd{F12} key @item @code{96} @kbd{Return} key on the keypad @item @code{97} Right @kbd{control} key @item @code{98} @kbd{Divide} key on the keypad @item @code{99} @kbd{System Request/Print Screen} key @item @code{100} @kbd{Alternative graphic} key @item @code{102} @kbd{Home} key @item @code{103} @kbd{Up} arrow key @item @code{104} @kbd{Page up} key @item @code{105} @kbd{Left} arrow key @item @code{106} @kbd{Right} arrow key @item @code{107} @kbd{End} key @item @code{108} @kbd{Down} arrow key @item @code{109} @kbd{Page down} down @item @code{110} @kbd{Insert} key @item @code{111} @kbd{Delete} key @item @code{119} @kbd{Pause/Break} key @item @code{125} Left @kbd{super} key @item @code{126} Right @kbd{super} key @item @code{127} @kbd{Application menu} key @end table @node Keyboard Layouts @chapter Keyboard Layouts Keyboard layouts as compiled from one or more files. When compiling a layout from multiple files, it is important that the files are specified in the correct order. The general rule is that the layout file, for example the Swedish QWERTY-keyboard, is specified first and is followed by add-ons such as the compose table and layout modifiers. @command{mds-kbdc} is used to compile layouts. Installed keyboard layout files are located in @file{/usr/share/mds/keyboard}.@footnote{If you are hacking in the source tree, you will find this under @file{res/keyboard}.} Layouts are located in the subdirectory @file{layout}, modifiers are located in the subdirectory @file{mods} and compose tables are located in the subdirectory @file{compose}. @command{mds-kbdc} prefixes @file{/usr/share/mds/keyboard} unless the specifed files starts with @file{/}, @file{./} or @file{../}. Dead keys are implemented by compose tables and not in the layouts. @menu * Keyboard Layout Syntax:: How to write your how layouts. * Builtin Functions:: Functions provided by the compiler. @end menu @node Keyboard Layout Syntax @section Keyboard Layout Syntax Similar to the C programming language, keyboard layout files are parsed from the top down. This means that any function or macro can only be used from lines beload the definition of said callable. However, the order of the mapping statements themself, in respect to each other, does not matter. Additionally, the layout files are parsed line by line, and leading whitespace is ignored. Comment can be started with a #-character and end at the end of the line. It is important to know that modifiers like @kbd{shift} and @kbd{control} needs to be mapped from a keycode, this and similar that many keyboards have in common, except dead key composition and compose sequences, is already available in the @file{layout/common} directory and can be included from the layout file. Compositions are implement in the @file{compose} directory and should be selected by the user at compile-time. Keyboard layout files must be written in UTF-8 (without UTF-8 BOM) and with line feeds for new lines. @menu * Mapping Statements:: Mapping keycodes to logical keys and text. * Sequence Mapping:: Implementing dead keys and compositions. * Keyboard Layout Identification:: Specifing the layout language, country and variant. * Layout Assumptions:: Making assumption about the keyboard layout. * Include Statement:: Including base files. * Layout Macros and Functions:: Reducing repetition. * Escaping:: Backslashes have so many uses. @end menu @node Mapping Statements @subsection Mapping Statements The most fundamental part of the layout files are mapping statements. These specify which keycode the keys have and what happens when certain keys pressed, combined or pressed and a sequence. If we want to map keycode 57 to the space key we write @example : @end example but then we also want the space key to product a blank space when we are writting so we add @example : " " @end example giving us @example : : " " @end example Because the order of the mapping statements does not matter we can just as well write @example : " " : @end example @code{" "} represents a text string with one blank space, but it is possible to have multiple characters. We want to extend this to @kbd{altgr+space} producing a no-break space, we can add either of the lines @example : "\u00A0" # no-break space (# comment) : "\u00A0" # no-break space @end example However, we also need a mapping to @kbd{altgr}: @example : @end example If we want to add a mapping to @kbd{ultra} from @kbd{altgr+menu} we can write @example : : <-altgr ultra> @end example @code{-altgr} means that @kbd{altgr} should not be reported as held down. As can be seen in these examples it is not possible to distinguish between modifiers and keys. It is up to the keyboard layout server and keyboard layout compiler to know this. However, it is defined in the keyboard layout files whether modifiers keys are lock keys or not. To map the keycode 58 to @kbd{caps lock} write @example : @end example But if you do not want it be a lock key, but instead be required to be held down, similar to how is normal for @kbd{shift}, instead write @example : @end example Any modifier may be a lock key. Another, just as important, use of mappings to is map letter keys. Unlike control keys like space and shift, there are no predefined letters@footnote{With letters with mean any character other than space.}. Therefore the letter is prefixed with the word `letter'. For example: @example : # The Q-key has keycode 16 (on QWERTY) : "q" # The Q-key should produce a `q' : "Q" # but `Q' when shift is used : "Q" # or when caps is used : "q" # but not when both are used @end example Special characters like simple double quotes, backspace and, in @code{<>}-notation, greater than sign must be escaped with a prepending backslash. Many keyboard layouts also have dead keys. Dead keys are keys that affect the next key-press. For example, `´' followed by `e' may product `é'. @kbd{compose} may be a dead key, just like it is in X.org, but it can also be a modifer. To define @kbd{´}, with keycode 13, @kbd{compose}, with keycode 125, as a dead keys write @example : : @end example Some may appear on multiple locations on the keyboard, for example, there may be a left and a right shift key, and a normal return key and one on the keypad: @example : : : : @end example Because @code{} and @code{} are valid keys --- they are arrow keys --- it is importatn to place them directly before the key, and not after. For instance @code{} denotes the left @kbd{shift} key, whilst @code{} denotes the left-arrow key with a @kbd{shift} key held down. Modifiers goes first. @node Sequence Mapping @subsection Sequence Mapping Compose tables use mapping statements to map key sequences. For example the compose key followed by two `s':es makes an `ß': @example "s" "s" : "ß" @end example It is also possible to map a sequence to another sequence: @example : @end example Of course, the input does not need to be a sequence: @example : @end example En alternative to @kbd{compose} as a dead key, is @kbd{compose} as a modifier. If you use this, the compose table need to be written for just that. There two ways do this this. Either you can write for example @example : "ß" @end example This maps two `s':es to a `ß', but requires that @kbd{compose} is held down during both key-presses. The other way is to write @example : "ß" # Note the `,' @end example This also requires that @kbd{compose} is not released between the key-presses. The compose table is filled with compositions where it does not matter in which order you press some of the keys. For example, instead of @example "S" "|" : "$" "|" "S" : "$" @end example you can write @example ("S" "|") : "$" @end example @code{( )} denotes an unordered subsequence. You can also use @code{[ ]} for alternation. For example, instead of @example ("S" "|") : "$" ("s" "|") : "$" @end example you can write @example (["S" "s"] "|") : "$" @end example Inside an alternation you can use a dot for specify that no key press is needed. For example, instead of @example "|" "S" : "$" "|" "|" "S" : "$" @end example you can write @example "|" ["|" .] "S" : "$" @end example It is undefined in which order alternations and unordered subsequences are expanded; neither sequencewise or levelwise. Thus, there should not side-effects where either one is used, nor does it make since to nest the two constructs in any other way than alternation inside unordered subsequence. @node Keyboard Layout Identification @subsection Keyboard Layout Identification Whilst it is possible to write a comment that states what keyboard layout a file implements, there is a standardise way to do this in code. The intention with this is to make it possible for graphical tools to easily list the layouts and easy to understand descriptions. There are three things a keyboard layout file should specify: the language, the country where it is used, and the variant. For example the Swedish QWERTY layout used in Sweden would have the code. @example information language "Swedish" country "Sweden" variant "QWERTY" end information @end example If the layout is used multiple countries, or even for multiple lanuages, @code{country} and @code{language} may be specified on multiple lines. For example: @example information language "Spanish" country "Argentina" country "Bolivia, Plurinational State of" country "Chile" country "Colombia" country "Costa Rica" country "Cuba" country "Dominican Republic" country "Ecuador" country "El Salvador" country "Guatemala" country "Haiti" country "Honduras" country "Mexico" country "Nicaragua" country "Panama" country "Paraguay" country "Peru" country "Puerto Rico" country "Uruguay" country "Venezuela, Bolivarian Republic of" variant "Latin American, QWERTY" end information @end example or @example information language "Norwegian" language "Bokmål" language "Nynorsk" country "Norway" variant "QWERTY" end information @end example @node Layout Assumptions @subsection Layout Assumptions When writing generic compose tables it can be helpful to let the compiler assume that a certain set of keys will be provided by the layout file and not making other assumptions. This is helpful because if you want to make an compose table that can compose all characters given only the ASCII letters, modifiers and a compose key, rather than written a phony layout file and select it each time you compile to compose table you can state in the compose table file that the compiler should as that those keys are provided when the compose table file is compile by itself. If this is done, the compiler can warn when one of the compositions cannot be reached from those basic keys. If we want to make the compiler assume that @kbd{compose} is available as a dead key, that @kbd{shift}, @kbd{altgr} and @kbd{space} are available and that the ASCII letter, digits and some basic special characters are available we can write. @example assumption have have have have have_range "0" "9" have_range "a" "z" have_range "A" "Z" have_chars "!\"@@#$%&/@{([)]=@}?\\^~*'<>|,;.:-_" end assumption @end example @node Include Statement @subsection Include Statement Writing layout files from scratch is probably something you want to avoid. For instance you would we need to create mappings for `A' to `Z' and `0' to `9' (assuming its a latin-based language), and map up all specific key, like modifiers, space, arrow keys, and the keypad. And you would have to make sure do only that the keys are mapped but that they are mapped to the text the should product and that they word correcly with the modifiers. These are things most keyboards have in common with many other layouts. For instance @file{layout/sv/qwerty} has two include statements to implement its basics: @example include "../common/qwerty" include "../common/base" @end example @node Layout Macros and Functions @subsection Layout Macros and Functions There is a lot of repetitive work in layouts, for instance all letters need mapping for any combination of use of @kbd{shift} and @kbd{compose}. To reduce this, you can define macros. For example instead of writing @example : "a" : "A" : "A" : "a" : "b" : "B" : "B" : "b" # and so on ... @end example you can use a macro and write @example macro letter/2 : "\1" : "\2" : "\2" : "\1" end macro letter("a" "A") letter("b" "B") # and so on ... @end example The name of this macro is `letter/2', but it is called with the name `letter' and two arguments. The `/2'-suffix means that it is invoked with exactly two arguments. You can use this do define multiple version of the same macro, with the same invocation name but with different number of arguments. For example: @example macro letter/2 : "\1" : "\2" : "\2" : "\1" end macro macro letter/1 letter(\1 \add(\sub(\1 "a") "A")) end macro letter("a") letter("b") # and so on ... letter("å" "Å") letter("ä" "Ä") letter("ö" "Ö") @end example @code{\add( )} and @code{\sub( )} are calls to two built-in functions named `add/2' and `sub/2'. Alternation can be used to invoke a macro: @example letter(["a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m"]) letter(["n" "o" "p" "q" "r" "s" "t" "u" "v" "w" "x" "y" "z"]) @end example You may use `.' in an alternation, in that case macro is called once with the argument, causing it to invoke for example `letter/0' instead of `letter/1'. A related issue are for-loops. If we for example want to call the macro `letter/1' for all letters betweeh and including `a' and `z' we can just write @example for "a" to "z" as \1 letter(\1) end for @end example instead of using the alternation-trick. You call also use if-statments. For example @example for "à" to "þ" as \1 # times sign is not upper case of division sign if \not(\equals(\a "\u00F7")) letter(\1 \add(\sub(\1 "à") "À")) end if end for @end example or equivalently @example for "à" to "þ" as \1 if \equals(\a "\u00F7") continue # times sign is not upper case of division sign end if letter(\1 \add(\sub(\1 "à") "À")) end for @end example @code{continue} can be used to stop the iteration of the innermost for-loop and skip to the next iteration. You can also use @code{break}, but it also has the effect to stop the entire loop. Similarly, @code{return} can be used to break an entire macro call, or function call. You can also use @code{if} for more example things, and use @code{else if} and @code{else if}: @example macro latter/1 if \not(\greater(\1 "z")) letter(\1 \add(\sub(\1 "a") "A")) else if \not(\greater(\1 "þ")) letter(\1 \add(\sub(\1 "à") "À")) else letter(\1 \sub(\1 1)) end if end macro @end example Note that there is no quotes around the `a' in @code{letter(\1 \sub(\1 1))}. This means that the argument will be than value 1 rather than the code point of the character `1'. Note however that values lower than zero or equals to or greater than 2 to the power of 31 not allowed and can either cause compile-time error or erroneous compiled files. Functions are similar to function macros, the difference is that a function is called inline and is prefixed with slash, and rather than inline the code inside it, the evalutes to the last value it evaluted before it returned. For example instead of @code{\not(\greater(\1 "z"))} you can write @code{\less_eq(\1 "z")} after you have defined the function `less_eq/2' with the following code: @example function less_eq/2 \not(\greater(\1 \2)) end function @end example A final constract to make layout code less repetitive is let-statements. This can be used to assign values to variables, and declar variables in undefined. The code @example macro latter/1 if \not(\greater(\1 "z")) letter(\1 \add(\sub(\1 "a") "A")) else if \not(\greater(\1 "þ")) letter(\1 \add(\sub(\1 "à") "À")) else letter(\1 \sub(\1 1)) end if end macro @end example can equivalently be writen using @code{let} as @example macro latter/1 if \not(\greater(\1 "z")) let \2 : \sub("a" "A") else if \not(\greater(\1 "þ")) let \2 : \sub("à" "À") else let \2 : 1 end if letter(\1 \sub(\1 \2)) end macro @end example It is also possible to declare arrays: @example let \1 : @{ "å" "ä" "ö" "à" "é" "ü" @} @end example Arrays may however not have arrays for values. Because arrays can be very large, they, but only them, may span multiple lines. For example you may write @example let \1 : @{ "å" "ä" "ö" "à" "é" "ü" @} @end example but not @example let \1 : @{ "å" "ä" "ö" "à" "é" "ü" @} @end example See @ref{Builtin Functions} for how they are used. Variable names can only be numerical and most not start with a zero. `0' is not valid variable name, and thus @code{\0} does not address a variable. Macro and function names, may only include `0'--`9', `a'--`z', `A'--`Z' and `_', but must and not start with `0'--`9'. Additionally, when declared macro and function names must be suffixed with `/' follwed by the exact number of arguments the macro or function takes. @node Escaping @subsection Escaping Similar to most, if not all, programming language, a backslash inside quotes can be used to parse the next character with special meaning. For instance, `\"' is parsed as a literal `"', and `\\' is parsed as a literal `\'. `\>' is too parsed as a literal `>', for example you may need to write @code{>}. The characters `(', `)', `[', `]', `@{', `@}', `<' and `,' also follow this rule to make those character accesible inside a @code{< >}. But `\' can also be used to specify characters by their code point, for example if you want an `æ' you can write @code{"\u00E6"} or @code{"\uE6"}, instead of @code{"æ"}. You can also write @code{"\0346"}, the difference between `\0' and `\u' is that `\0' uses octal whereas `\u' uses hexadecimal. `\' can also be used to access variables and parameters. For example `\1' in @example macro letter/2 : "\1" : "\2" : "\2" : "\1" end macro letter("å" "Å") @end example is expanded to an `å', where as `\2' is expanded to an `Å'. `\' is also used to call functions, for example if you want to call the function `f/0' you write @code{\f()}. Because numerical (possibly prefixed with an `u') are of variable length, it is possible to specify the escape's termination point with a dot. For instance, if you want the value of the first variable (\1) followed by two zeroes, you do not write `\100' as that would expand to the value of the hundredth variable. Instead you write `\1.00'. @node Builtin Functions @section Builtin Functions To help you write meaningful functions in your keyboard layout files, the compiler defines an almost minimal set of basic functions: @table @code @item add/2 The code points in \1 plus the code points of the corresponding characters in \2. If \1 and \2 are not of the same length, the returned string will be of the length of the longer of the parameters, and modulo is used to map to the corresponing character. @item sub/2 Like `add/2' but subtraction. @item mul/2 Like `add/2' but multiplication. @item div/2 Like `add/2' but division. @item mod/2 Like `add/2' but modulo. @item rsh/2 Like `add/2' but rightward bitwise shift. If a character in \2 is has a code point greater than 30, undefined behaviour is invoked. @item lsh/2 Like `add/2' but leftward bitwise shift. If a character in \2 is has a code point greater than 30, undefined behaviour is invoked. @item or/2 Like `add/2' but bitwise OR. @item and/2 Like `add/2' but bitwise AND. @item xor/2 Like `add/2' but bitwise XOR. @item not/1 For each character in \1, evaluate to zero if the character is not zero, and one if the character is zero. @item equals/2 For each character, evalute to one if the characters in \1 and \2 are equal and zero otherwise. @item greater/2 Like `equals/2' but \1 greater than \2 rather than \1 equals \2. @item less/2 Like `equals/2' but \1 less than \2 rather than \1 equals \2. @item set/3 Set the element with index \2, in the array with variable index \1, to \3, and return \3. For example @code{\set(1 0 4)} sets the first element in \1 to 4. @item get/2 Return the element with index \2 in the array with variable index \1. For example after @code{\set(1 0 4)} or @code{let \1 : @{ 4 3 2 1 0 @}} has been used, @code{\get(1 0)} evaluates to 4. @end table @node Discussion @chapter Discussion @menu * Server Architecture:: Discussion on fundamental design choices. * Fixing X.org Issues:: Can we avoid the problems X.org has? @end menu @node Server Architecture @section Server Architecture This chapter aims to enumerate advantages and disadvantages with micro-display servers, traditional monolithic display servers and other possible designs. Please chime in with any insight. @menu * The Microserver Architecture:: The microserver architecture. * The Monolithic Server Architecture:: The monolithic server architecture. * The Hybrid Server Architecture:: The hybrid server architecture. * The Megalithic Server Architecture:: The megalithic server architecture. * The Modular Server Architecture:: The modular server architecture. * The Modular Microserver Architecture:: The modular microserver architecture. * The Exoserver Architecture:: The exoserver architecture. @end menu @node The Microserver Architecture @subsection The Microserver Architecture Description: The display server is implement with multiple binaries that speak with each other using a well defined protocol. @noindent Implementations: mds. @noindent Advantages: @itemize @bullet{} @item Knowing the names of the servers you use and their purpose makes it very easy to find where you want to do patching in the source code. @item Spaghetti code to a larger extent is virtually impossible; the microserver architecture guarantees a certain quality of the code architecture for the display server. @item If the message passing used in the display server allows for message modification and retrieval ordering, extending, modifying and using the display server in unforeseen ways becomes much easier, and will often not require any modifications to the existing servers. @item Replacing the display server is easier for a micro-display server than it is for a monolithic display server, because the servers could be replaced one by one and could even support running under two distinct protocol during the transitional period. @item Not as many subprotocols needs to be defined. For example, recording the output of the display does not require a special protocol, one only needs to write a server that listens on messages passed between servers. @item If a server crashes it does not crash the entire session. Crashes can most often be repaired. @item Because servers can easily be omitted and replaced when starting the display server, it becomes much easier to mount the display server on top of an already running display server. For example, if you want the performance of @code{weston} but then flexibility and functionallity of @code{mds}, you could start @code{mds} inside @code{weston} and replace a small set of the servers with variants written to running on top of Wayland; of course with some functionallity of @code{mds} missing. @item It is trivial to only have setuid on for the part of the display server where it is required. @end itemize @node The Monolithic Server Architecture @subsection The Monolithic Server Architecture Description: The display server is implemented as one binary. @noindent Implementations: X11, Mir, Wayland, Surface Flinger, Quartz Compositor, Desktop Window Manager. @noindent Advantages: @itemize @bullet{} @item The monolithic architecture makes it trivial to isolate information for clients to achieve confidentiality. Prioritising confidentiality however leads to problems implementing features such as screenshooting and global hotkeys. @item Monolithic server does not need to pass messages between modules, but can rather perform normal function calls and achieve greater performance. @item Monolithic display servers can have a smaller memory footprint than its full-fledged counterparts. @end itemize @node The Hybrid Server Architecture @subsection The Hybrid Server Architecture Description: The display server is implmeneted with the microserver architecture except some components are built into the master server for performance or security reasons. @noindent Hybrid display server could arguably be called milli-display servers to emphasis that they are small, but not as small as micro-display servers, are much more closely related to micro-display servers than monolithic display servers, and, in constrast with OS kernels, have a proper distinction from monolithic systems and microsystems. @footnote{I don't know about calling them macro-display servers, that implies that they are the total opposite of micro-display servers.} @noindent Implementations: none? @noindent Advantages: @itemize @bullet{} @item Can achieve most of the microserver architecture's advantages, but not always to the same extent. @item By integrating some servers into the master server, the hybrid architecture can isolate information for clients to achieve confidentiality. Prioritising confidentiality however leads to problems implementing features such as screenshooting and global hotkeys. @item Large and high frequency messages does not need to be passed around to other servers if they are integrated into the master server. This lets hybrid display server achieve the same perfomance performance as monolithic display servers for tasks where it is desirable. @end itemize @noindent The mds protocol and its reference implemention can easily be made into a hybrid display server protocol and an implementation thereof. @node The Megalithic Server Architecture @subsection The Megalithic Server Architecture Description: A monolithic display server where applications are loaded or compiled into the display server itself. @noindent These are also known as mega-display servers. @noindent Implementations: none? @noindent Advantages: @itemize @bullet{} @item No interprocess communication is required, apart from letting the display server know to load modules if it does not compile in its programs. This lets megalithic display server achieve even greater performance than monolithic display servers. @end itemize @noindent Disadvantages: @itemize @bullet{} @item Imposes restrictions on which languages applications can use. @item Imposes restrictions on how applications can behave. @item Cannot be networked without exposing an alternative display server protocol. @item The display becomes more crash prune; if an application crashes it is likely to crash the entire display. @item Applications will run with the same privileges as the display server, which is root on most operating systems. @end itemize @noindent Megalithic display servers could be interesting for high performing gaming consoles. @node The Modular Server Architecture @subsection The Modular Server Architecture Description: A monolithic display server where server-like programs can be loaded as modules into the display server but applicates are connected with interprocess communication. @noindent Implementations: none?@footnote{Desktop Window Manager is partially modular, but as of yet, this cannot be utilised by end-users.} @noindent Advantages: @itemize @bullet{} @item Can achieve that flexibility of micro-display servers, but not when networked, with the same memory footprint as monolithic display servers. @item Has the same advantages as monolithic kernels. @item Applications that require absolute performance can be loaded as modules and achieve the same performance as megalithic kernels, however with the same caveats. @end itemize @noindent With a little work the mds protocol could be transformed into a modular server display protocol, and with some work the reference implementation could be made into a modular server display. @node The Modular Microserver Architecture @subsection The Modular Microserver Architecture Description: A modular display server with a module that enables clients to act as modules that communicates via interprocess communication rather than being loaded into the display server. @noindent Implementations: none? @noindent Advantages: @itemize @bullet{} @item The modular microserver architecture seem to provide all of the advantages of the other architecture but none of the disadvantages. However, modules can still crash and bring down the display server, but the idea is to not load unstable modules but let the be servers. Therefore exo-diplay server are slightly more robust. @end itemize @noindent With a little work the mds protocol could be transformed into a modular server display protocol, and with some work the reference implementation could be made into a modular server display. Then the untransformed version of @command{mds-server} cound be made into a module for the transformed version. @node The Exoserver Architecture @subsection The Exoserver Architecture Description: An exo-display server is a tiny display server that attempts to let applications access the underlaying system directly and implements basic interprocess communication to let applications share vital information and coordinate with each other. @noindent Implementations: none? @noindent Advantages: @itemize @bullet{} @item Can achieve the same performance as megalithic display servers. @item Can achieve the same robustness as micro-display servers. @end itemize @noindent Disadvantages: @itemize @bullet{} @item Cannot be networked without exposing an alternative display server protocol. @end itemize @noindent Exo-display servers could be interesting for high performing gaming consoles. @node Fixing X.org Issues @section Fixing X.org Issues X.org is been critiqued for several shortcoming, some of which have caused people to start on new display servers replace X.org. This chapter will list some issues and discuss how they can be avoided in mds. @menu * Automatic Cleanup:: Cleanup up after applications. * Input Problems:: Problems related to human input. * Other Issues:: Other issues in X.org. @end menu @node Automatic Cleanup @subsection Automatic Cleanup A common critique of X.org is that the monitor resolution is not restored if a game change the resolution and for some reason, for instance a software crash, does not switch back before exiting. This problem is not intrinsic to the protocol, but rather because of a lacking protocol. You can run a program like @command{xrandr} to change the monitor resolution for the entirety of the session and @command{xrandr} can exit when the resolution has changed. This is how it should be. However, there is no way to tell an X.org server to switch back if the connection between the program and server is lost. This is easily fixed by adding a lifespan parameter as found in @ref{set-gamma}. A similar critique of X.org is that gamma ramps are not restored when an application exits. Either the ones complaining about this do not understand why gamma ramps exists, namely so you can calibrate the monitor's output in respect to the colours, and just think it is a way to make the video in games brighter. Or they think we should have daemons running ideally to have gamma adjustments. Or, more likely and more validly, its is poorly phrased and they actually want a way for applications, like games, to inform the display server to undo its modifications to the gamma ramps when the program exits. This is already supported by the mds protocol. @node Input Problems @subsection Input Problems X11 allows programs to exclusively grab keyboard and mouse input. When a program that does this misbehaves or become unresponsive, you cannot do anything but manage it from another computer or restart the computer. In mds exclusively grabbing is achieved buy setting the client priority for the related message to the highest priority. @footnote{If multiple clients do this, it is arbitrary who gets the message first and can stop the others from getting it.} This is however not allowed (but nothing will stop you) as the idea is that clients should either select a predefined priority, select a priority between servers it to be between, or select a priority of 50 percent or 150 percent of another servers priority. Thus, unless a client breaks this rule, you can always have your server for switching to the TTY at a higher priority than other programs. A similar, and probably related, problem in X.org is that global keybindings don't work when a popup or menu has focus. (Thankfully GTK+ will close that item if it receives unexpected input.) I have hard time seeing how this could become an issue in mds. Another issue related to the keyboard in X.org is that hotkeys in programs do not work in a few situtations because the program was not designed with another keyboard layout in mind than the keyboard layout the developer used. I suggest that programs restrain themself from including Alternative Graph in their hotkeys and only use Shift for A through Z and space. However, what I would really like to see is that toolkits lets users modify all hotkeys. If program additionally restrain themself to having all hotkeys contain control or alt the keyboard layouts with non-latin alphabets would not suffer because they do not use the latin alphabet. @node Other Issues @subsection Other Issues X11 display servers do not let you upgrade or otherwise replace graphics drivers online. Or other parts of it. X11 display servers could allow you to send a signal, for instance SIGUSR1, to upgrade the whole server, however this is not favourable, and X.org does not do this. The reference implemention of the mds protocol lets you safely upgrade any part of it unline by sending SIGUSR1 to the server that should be upgraded. On catastrophic failure in this process 0a server would restart and lose volatile data, but the server shoul be upgraded and it would ask all running clients for resend information the server lost. Another issue with X.org is that it is not multithreaded, which can cased intensive programs to freeze your desktop. mds is inherently pervasively parallel and only subsystems, rather than the whole system, can suffer from this. It is however easy for mds servers to implement pervasive threading, that is, letting each request spin up a new thread in the server. @node GNU Free Documentation License @appendix GNU Free Documentation License @include fdl.texinfo @bye