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>

Makefile

@@ -180,13 +180,14 @@ endif
 # completely different things:
 #
 #   stdvga      the boot splash, then the text console and your shell
-#   virtio-gpu  whatever vgpud drew, which at the moment is a test pattern
+#   virtio-gpu  the mark, and then the same console, mirrored there by vgpud
 #
-# So a window sitting on the virtio-gpu display shows colour bars and no
-# prompt, and one that opened before vgpud drew shows black. Nothing is wrong
-# when that happens; you are looking at the other screen. `make qemu-console`
-# below boots with one display and no GPU to hand over, which is the quickest
-# way to tell that apart from an actual failure.
+# So the two windows show the same thing once vgpud is up, which is the point:
+# a head showing the running system is a head you can tell is working. Before
+# vgpud starts, the virtio-gpu display is black -- nothing is wrong when that
+# happens, you are looking at a device nobody has drawn on yet. `make
+# qemu-console` below boots with one display and no GPU to hand over, which is
+# the quickest way to tell that apart from an actual failure.
 QEMU_DISPLAY = -vga std -device virtio-gpu-pci
 
 # One display, carrying the console. No virtio-gpu, so vgpud finds nothing to