daniel
7f415e724f
The display's first use of threads (docs/threading.md, docs/display.md). The
compositor stays the single owner of the framebuffer — only the main
service.run loop touches the backend and layer stack — and a dedicated
mouse-listener thread runs beside it:
- Listener: blocks on input.subscribeMouse(), accumulates relative dx/dy
into an absolute cursor position clamped to the screen, and hands it to
the compositor. It never touches the compositor, so no lock guards the
framebuffer; a parked next() lets the core halt.
- CursorChannel: a single-slot latest-value cell under a Thread.Mutex (the
renderer wants where the cursor is now, not a replay of deltas), with a
coalesced self-ipc.send poke that wakes the main loop — parked in
replyWait — as a message-notification. At most one poke is queued while
the last is undrained, so a fast mouse can't flood the endpoint.
- Render: the cursor is a top-z compositor layer; on the poke the main loop
moves it via configure + present (which damages old + new footprints).
The display binary opts into threads (addThreadedUserBinary), and
input-source gains a "mouse" mode that publishes pure motion to drive it.
Two kernel-level findings this surfaced, both fixed:
1. IPC handles do not cross threads. The handle table lives on the Task, so
the listener can't reuse the main loop's endpoint handle — it
ipc.lookup(.display)s its own handle to the same endpoint to poke through.
2. Concurrent IPC from two threads raced unlocked kernel state. The display
is the first process issuing IPC syscalls from two threads at once, which
exposed a data race (flaky #GP in installEntry): create_ipc_endpoint /
ipc_register / ipc_lookup allocate from the kernel heap and mutate the
global registry, endpoint refcounts, and handle tables without the big
kernel lock. They were safe only while a process couldn't race itself.
They now sync.enter() like call/reply_wait/send already did (the kernel
heap has no lock of its own yet — heap.zig: "a lock comes with
threads/SMP" — so the big lock keeps its callers serialized).
Test: -Dtest-case=display-cursor (smp:4) spawns the input service, the
threaded display, and input-source in mouse mode; asserts the display's
"cursor tracking mouse ok" marker once the cursor has tracked a run of motion
end to end. Verified green 6/6 under stress (the race hit ~1-in-4 before the
lock fix) and in the full 29-case QEMU guardrail suite; zig build test clean.
57 lines
2.5 KiB
Zig
57 lines
2.5 KiB
Zig
//! system/services/input-source — a hardware-free synthetic input source, used to exercise
|
|
//! the input service end to end without a real PS/2 controller (the `input` test case, and
|
|
//! any bring-up where there is no hardware). It stands in for a driver: it connects to the
|
|
//! input service and publishes a rolling stream that cycles through all device classes —
|
|
//! keyboard, mouse, and joystick/gamepad — which the service routes to interested
|
|
//! subscribers.
|
|
//!
|
|
//! It stays silent after startup (no per-event logging) so it can share the boot serial
|
|
//! transcript with a subscriber whose output is the test's success marker. The real
|
|
//! keyboard and mouse drivers publish their own synthetic streams today; swapping in
|
|
//! decoded hardware is a follow-up (see docs/input.md).
|
|
|
|
const std = @import("std");
|
|
const runtime = @import("runtime");
|
|
const input = runtime.input;
|
|
const system = runtime.system;
|
|
|
|
pub fn main(init: runtime.process.Init) void {
|
|
var source = input.connectSource() orelse {
|
|
_ = system.write("input-source: input service unavailable\n");
|
|
return;
|
|
};
|
|
|
|
// "mouse" mode publishes a steady stream of pure motion (dx=dy=+1), for driving a
|
|
// cursor (the `display-cursor` test). The default "rotate" mode cycles all device
|
|
// classes to exercise the service's per-device routing (the `input` test).
|
|
const mode = init.arguments.get(1) orelse "rotate";
|
|
if (std.mem.eql(u8, mode, "mouse")) {
|
|
_ = system.write("input-source: publishing synthetic mouse motion\n");
|
|
while (true) {
|
|
_ = source.publishMouseEvent(.{
|
|
.kind = @intFromEnum(input.MouseEventKind.motion),
|
|
.button = 0,
|
|
.dx = 1,
|
|
.dy = 1,
|
|
.scroll_x = 0,
|
|
.scroll_y = 0,
|
|
.buttons = 0,
|
|
});
|
|
system.sleep(20); // ~50 events/sec: moves the cursor briskly
|
|
}
|
|
}
|
|
|
|
_ = system.write("input-source: publishing synthetic input events\n");
|
|
var step: usize = 0;
|
|
while (true) : (step +%= 1) {
|
|
// Rotate across the device classes so every publish path (and the service's
|
|
// per-device routing) is exercised.
|
|
switch (step % 3) {
|
|
0 => _ = source.publishKeyboardEvent(input.syntheticKeyEvent(step)),
|
|
1 => _ = source.publishMouseEvent(input.syntheticMouseEvent(step)),
|
|
else => _ = source.publishJoystickEvent(input.syntheticJoystickEvent(step)),
|
|
}
|
|
system.sleep(200);
|
|
}
|
|
}
|