vgpud: the second head shows the console, not a logo

"but Virtio GPU is still non functional. it only shows logo" -- and that was
a fair reading of it. A second monitor showing a mark for ever is
indistinguishable from a second monitor that does not work.

The mark was the right answer to the question hybrid.md asked: H2 and H3 needed
a screenshot that proved a *userspace process* had drawn something, and that
the driver came back after being killed. Both are closed. What was left was a
display whose entire output was a logo, on a machine whose console was sitting
on the other head.

So vgpud mirrors the console onto it.

**A copy with a diff.** /dev/fb0 maps the console's framebuffer; the virtio
backing store is already mapped, because vgpud allocated it. The backing
therefore holds, at all times, exactly what was last sent to the device --
which means it *is* the previous frame, and "what changed" needs no third
buffer. Ten times a second: compare rows, skip the ones that match, copy the
ones that do not, transfer the one rectangle spanning the rows that changed.

Hence present() becoming present_rect(). Moving one line of text through a
full-screen transfer of a 1280x800 resource is most of a megabyte of copy for
a few hundred bytes of difference, and this loop runs whether or not anything
is happening.

Mapping /dev/fb0 does not take the screen from the console: the pages are the
ones the console draws into, and fb_mapped() only arranges a redraw when the fd
is closed. This one never is.

Sizes differ, so a head larger than the console centres it on the theme ground
the mark already draws, and a smaller head shows the top-left corner -- which
is where a terminal puts everything worth seeing. Scaling is the alternative
and it is the wrong one; text resampled to a non-integer ratio is text you
cannot read. The blocking accept() became poll() with the frame interval as its
timeout, because holding the device is no longer the only thing to do.

Not the endpoint: a compositor will want this head for itself, and when there
is one this goes away. Until then the honest thing for a working display to
show is the system that is running on it.

**And a bug older than any of it.** schmode reported "cannot reach vgpud on
/run/vgpud -- it is not running" about a process that was running perfectly
well. Every boot after the first, on any image whose root is writable, and
nothing to do with this change -- it reproduces on the previous commit, 3 runs
in 4.

bind() creates a node at the path, and /run is a directory on the root
filesystem rather than a tmpfs. The node outlived the process that bound it and
the boot it was bound in, so the next boot's vgpud claimed the device, drew,
held it -- and then failed bind() on a name that already existed. A driver
nobody could talk to, and an error message naming the wrong cause.

It unlinks before binding now, which is what a Unix daemon does. The usual
objection, that this lets a second instance steal a live socket, does not apply
here: two vgpuds cannot coexist, because the first holds the PCI claim and the
second is refused the device long before it reaches bind(). The claim is the
mutual exclusion; the socket node never was.

Verified by screendumping both heads over QMP: with the console at 1280x800 the
two are byte-identical, and after `schmode 1024 768` the virtio head carries
the console at the new mode. Three consecutive boots of one image all reach a
working control socket, where the previous commit managed one. Both supported
configurations: one boot each, no traps, no panics, socktest and memfdtest
green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/architecture/graphics.md

@@ -106,6 +106,68 @@ and `mmap` of the real framebuffer at its real physical address.
 > happens with no further syscalls. `fb_mapped()` is called there, and
 > `fbclose()` puts it back.
 
+## What the second head shows
+
+A machine with both a stdvga and a virtio-gpu has two displays, and `vgpud` —
+the out-of-kernel driver, `cmd/vgpud/main.c` — owns the second one. For a long
+time it drew a test card there: colour bands, gradients, a checkerboard, and
+its own pid in binary along the bottom. That was scaffolding for
+[../plan/hybrid.md](../plan/hybrid.md)'s H2 and H3, where a screenshot had to
+answer *did a userspace process put this here* and *did the driver come back*.
+
+Both of those are closed, so the test card became the Shift mark. Which was
+honest about ownership and useless about everything else: **a second monitor
+showing a logo for ever is indistinguishable from a second monitor that does
+not work**, and that is exactly what it got called.
+
+It shows the console now.
+
+### A copy with a diff
+
+The console framebuffer is mapped through `/dev/fb0`; the virtio backing store
+is already mapped, because `vgpud` allocated it. So the backing holds, at all
+times, exactly what was last sent to the device — which means it *is* the
+previous frame, and answering "what changed" needs no third buffer. Ten times
+a second: compare each row, skip the ones that match, copy the ones that do
+not, and transfer the single rectangle spanning the rows that changed.
+
+This is why `present()` became `present_rect()`. Moving one line of text with a
+full-screen transfer of a 1280×800 resource is most of a megabyte of copy for a
+few hundred bytes of difference, and the loop runs whether or not anything is
+happening.
+
+Mapping `/dev/fb0` does not take the screen away from the console — the
+mapping is of the same physical pages the console draws into, and the kernel's
+`fb_mapped()` only arranges a redraw when the fd is *closed*. `vgpud` never
+closes it.
+
+A head larger than the console centres it on the theme ground. A head smaller
+shows the top-left corner, which is where a terminal puts everything worth
+seeing. Scaling is the alternative and it is the wrong one: text resampled to a
+non-integer ratio is text you cannot read.
+
+**This is not the endpoint.** A compositor (Gate 3) will want this head for
+itself, and when there is one, the mirror goes away. Until then the honest
+thing for a working display to show is the system running on it.
+
+### /run is not a tmpfs
+
+Found while testing the above, and older than it: `schmode` reported *"cannot
+reach vgpud on /run/vgpud — it is not running"* about a process that was
+running perfectly well, on every boot after the first.
+
+`bind()` creates a node at the path, and `/run` is a directory on the root
+filesystem rather than a tmpfs. So the node outlived the process, and the boot.
+The next boot's `vgpud` claimed the device, drew, held it — and failed `bind()`
+on a name that already existed, leaving a driver nobody could talk to and an
+error message that named the wrong cause.
+
+`vgpud` unlinks the path before binding it, which is what a Unix daemon does.
+The usual objection — that it lets a second instance steal a live socket — does
+not apply: two `vgpud`s cannot coexist, because the first holds the PCI claim
+and the second is refused the device long before it reaches `bind()`. The claim
+is the mutual exclusion; the socket node never was.
+
 ## Text
 
 [`include/text.h`](../../include/text.h) + `kernel/dev/text.c`.