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.