The daemon responsible for the boot log must never ever block to avoid
deadlocks, but doing so while still accepting keyboard input is
non-trivial. This commit splits the boot log out from fbcond into a
separate daemon to make this a lot easier to implement. This will also
allow making fbcond blocking again, which will simplify some things.
This ensures that the foreground VT doesn't lockup if a background VT
spams us with flush requests. In the future we may want to add a
scheduler or collapse redundant flush requests.
This will hopefully avoid confusion if someone in the future changes the
XferToHost2d in flush to pass a smaller GpuRect. Without adjusting
offset this would cause glitches.
It is now possible to write multiple damage locations in a single write
call. Vesad also no longer processes damage for background vt's. The
entire framebuffer will be redrawn once the vt switches to the
foreground anyway. And finally fsync now consistently redraws the entire
screen rather than having different behavior between vesad and
virtio-gpud.
With this virtio-gpud no longer has to support getting deactivated at
any time to hand back control to vesad. This makes it much easier to add
many new features that a proper graphics driver is supposed to support.
Be aware that virtio-gpud waits for the vsync on every flush request.
Fbcond and orbital are not really happy about this right now and when
something changes multiple times within a single frame, flush requests
queue up, causing the ui to hang until all flush requests are finished.
It is still possible to switch to another VT though which won't hang.
The code will become simpler once handoff is implemented such that
virtio-gpud no longer needs to support reset and reinitialization of the
virtio gpu device.
Previously inputd would directly push vt activation events to the
graphics driver, which required being quite lazy to prevent deadlocks as
well as the graphics driver having a location where events can be pushed
to. By having graphics drivers pull the vt activation events instead,
the effective control flow becomes simpler and it becomes easier to
correctly handle multiple graphics drivers on the system. For example it
becomes possible for multiple graphics drivers to present displays for a
single VT as well as making it easier to provide a handoff from the
early framebuffer to a real graphics driver.
ControlHandle is used to switch the active vt, while DisplayHandle is
used by display drivers to register new vt's. There are entirely
unrelated tasks and the fact that they had been merged together has been
confusing me for a while.
Also changed activating a VT to no longer create a new vt when none
existed previously. The target graphics driver may not be able to handle
the new VT. inputd -A already didn't allow activating non-existent VT's
as it first tried to open a consumer handle for the target VT.
bjorn3