# XLibre upstream bug reports (illumos / Solaris os-support)

Draft reports for filing at https://github.com/X11Libre/xserver/issues.
Found building XLibre xserver **25.1.8** for Hammerhead (an illumos fork).
Root cause for each: XLibre CI has no illumos/Solaris target, so the
`hw/xfree86/os-support/solaris/` backend and the Solaris event-ports code paths
are unexercised. Local patches live in `zports/base/xlibre-xserver-xorg/patches/`.

---

## Bug 1 — Threaded input busy-loops on Solaris/illumos (event-ports ospoll), pegging ~2 CPUs

**Severity:** high (100% CPU on two cores at idle). **Component:** `os/inputthread.c`, `os/ospoll.c` (Solaris `PORT_SOURCE_FD` backend).

**Symptom:** On illumos with a real input device, Xorg pegs ~2 full cores while idle. `prstat -mL` shows two server threads at 100% (`[MainThread]` + `[InputThread]`); `mpstat` shows ~1,000,000 syscalls/sec; DTrace shows the InputThread doing `portfs`+`write` 1:1 (~340k/s) and the MainThread `portfs`+`read` 1:1 (~225k/s). `pfiles` shows the two hot fds are the **input-thread → main-thread wakeup self-pipe**, not the input devices (which read fine, errno 0).

**Cause:** the threaded-input wakeup pipe fd, registered in the InputThread's ospoll (Solaris event-ports / `port_associate` backend), is re-armed reporting `POLLIN` "ready" every cycle with nothing to deliver, so InputThread and MainThread ping-pong on the self-pipe as fast as the CPU allows. Event ports are one-shot (must re-`port_associate` after `port_get`); the re-arm appears to fire on an already-drained/edge condition.

**Repro:** run Xorg on illumos with `xf86-input-keyboard`/`-mouse` and a real `/dev/kbd`+`/dev/mouse`. XLibre also **removed** the historic `-noThreadedInput` command-line flag (only `-dumbSched` still disables the input thread, as a side effect of disabling the smart scheduler).

**Workaround in use:** patch `os/inputthread.c` default `InputThreadEnable = TRUE` → `FALSE` (input serviced in the main dispatch loop; pre-2016 default). Proper fix: correct the event-ports ospoll re-arm so a drained fd is not re-reported ready.

---

## Bug 2 — `sun_apm.c` fails to build: PM hook declarations moved to `xf86_priv.h`, Solaris backend not updated

**Severity:** medium (build break on the only platform that compiles it). **Component:** `hw/xfree86/os-support/solaris/sun_apm.c`.

**Symptom:** `xf86OSPMOpen()` fails to compile on illumos under GCC 14 with `xf86PMGetEventFromOs`/`xf86PMConfirmEventToOs`/`xf86HandlePMEvents` undeclared (hard error).

**Cause:** XLibre moved the power-management hook declarations into `hw/xfree86/common/xf86_priv.h` (lowercase-underscore) and updated the Linux backend (`lnx_apm.c`/`lnx_acpi.c` now include `"xf86_priv.h"`) but **not** the Solaris backend — `sun_apm.c` still includes only `"xf86Priv.h"` (capital-P, a different header).

**Fix:** add `#include "xf86_priv.h"` to `sun_apm.c` (matching `lnx_apm.c`). One line.

---

## Bug 3 — `os/meson.build` / os-support `sunos` guards don't match a downstream illumos sysname

**Severity:** low (portability; only bites forks whose `uname` isn't `SunOS`). **Component:** `os/meson.build`, `hw/xfree86/os-support/meson.build`.

**Symptom/Cause:** the Meson os-support selection keys the Solaris backend on `sunos`; a Solaris-derived OS reporting a different `system()` name (here `hammerhead`) silently gets no Solaris os-support and fails to link the console/VT layer. (Reported for awareness — an illumos-derived downstream, not stock illumos, so may be WONTFIX; the pattern of extending the `sunos` case is the same one the Linux backends already use for kFreeBSD etc.)

**Workaround:** extend the `sunos` arm to also accept the downstream sysname.