vasilito
f31522130f
Build system (5 gaps hardened): - COOKBOOK_OFFLINE defaults to true (fork-mode) - normalize_patch handles diff -ruN format - New 'repo validate-patches' command (25/25 relibc patches) - 14 patched Qt/Wayland/display recipes added to protected list - relibc archive regenerated with current patch chain Boot fixes (fixable): - Full ISO EFI partition: 16 MiB → 1 MiB (matches mini, BIOS hardcoded 2 MiB offset) - D-Bus system bus: absolute /usr/bin/dbus-daemon path (was skipped) - redbear-sessiond: absolute /usr/bin/redbear-sessiond path (was skipped) - daemon framework: silenced spurious INIT_NOTIFY warnings for oneshot_async services (P0-daemon-silence-init-notify.patch) - udev-shim: demoted INIT_NOTIFY warning to INFO (expected for oneshot_async) - relibc: comprehensive named semaphores (sem_open/close/unlink) replacing upstream todo!() stubs - greeterd: Wayland socket timeout 15s → 30s (compositor DRM wait) - greeter-ui: built and linked (header guard unification, sem_compat stubs removed) - mc: un-ignored in both configs, fixed glib/libiconv/pcre2 transitive deps - greeter config: removed stale keymapd dependency from display/greeter services - prefix toolchain: relibc headers synced, _RELIBC_STDLIB_H guard unified Unfixable (diagnosed, upstream): - i2c-hidd: abort on no-I2C-hardware (QEMU) — process::exit → relibc abort - kded6/greeter-ui: page fault 0x8 — Qt library null deref - Thread panics fd != -1 — Rust std library on Redox - DHCP timeout / eth0 MAC — QEMU user-mode networking - hwrngd/thermald — no hardware RNG/thermal in VM - live preload allocation — BIOS memory fragmentation, continues on demand
50 lines
2.2 KiB
XML
50 lines
2.2 KiB
XML
<?xml version='1.0' encoding='utf-8' ?>
|
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
<!ENTITY % BOOK_ENTITIES SYSTEM "Wayland.ent">
|
|
<!ENTITY doxygen SYSTEM "ServerAPI.xml">
|
|
%BOOK_ENTITIES;
|
|
]>
|
|
<appendix id="sect-Library-Server">
|
|
<title>Server API</title>
|
|
<section><title>Introduction</title>
|
|
<para>
|
|
The open-source reference implementation of Wayland protocol is
|
|
split in two C libraries, <link
|
|
linkend="sect-Library-Client">libwayland-client</link> and
|
|
libwayland-server. Their main responsibility is to handle the
|
|
Inter-process communication (<emphasis>IPC</emphasis>) with each
|
|
other, therefore guaranteeing the protocol objects marshaling and
|
|
messages synchronization.
|
|
</para>
|
|
<para>
|
|
The server library is designed to work much like libwayland-client,
|
|
although it is considerably complicated due to the server needing
|
|
to support multiple versions of the protocol. It is best to learn
|
|
libwayland-client first.
|
|
</para>
|
|
<para>
|
|
Each open socket to a client is represented by a <link
|
|
linkend="Server-structwl__client">wl_client</link>. The equivalent
|
|
of the <link linkend="Client-classwl__proxy">wl_proxy</link> that
|
|
libwayland-client uses to represent an object is <link
|
|
linkend="Server-structwl__resource">wl_resource</link> for
|
|
client-created objects, and <link
|
|
linkend="Server-structwl__global">wl_global</link> for objects
|
|
created by the server.
|
|
</para>
|
|
<para>
|
|
Often a server is also a client for another Wayland server, and
|
|
thus must link with both libwayland-client and libwayland-server.
|
|
This produces some type name conflicts (such as the <link
|
|
linkend="Client-classwl__display">client wl_display</link> and
|
|
<link linkend="Server-structwl__display">server wl_display</link>,
|
|
but the duplicate-but-not-the-same types are opaque, and accessed
|
|
only inside the correct library where it came from. Naturally that
|
|
means that the program writer needs to always know if a pointer to
|
|
a wl_display is for the server or client side and use the
|
|
corresponding functions.
|
|
</para>
|
|
</section>
|
|
&doxygen;
|
|
</appendix>
|