Fbbootlogd doesn't do non-blocking operations, so fevent isn't needed.
And the kernel shouldn't pass closed handles to us and even if it does
due to a bug, it is harmless to silently ignore the fact that the handle
was closed.
While for now this for now only includes helpers for the current limited
display interface which is relatively simple to implement manually, in
the future we will likely need a more complex interface with gpu drivers
that would be hard to get right without a common crate proving the
interface.
Graphics clients will need to handle resizing themself anyway for
handoff between graphics drivers and as such don't need the graphics
to modify the framebuffer during resize.
This unifies the driver interface handling between graphics drivers and
makes it easier to change all graphics drivers in lockstep when adding
new features.
Resources are global for the entire virtio-gpud device, not local to a
single display. In the future resource creation will become entirely
detached from specific displays.
With fbbootlogd split out it is no longer essential to avoid blocking
operations on the main thread of fbcond. Moving them back to the main
thread simplifies things a fair bit.
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.
bjorn3