It is quite likely that the next graphics API won't be the last one and
as such would become a legacy API too. Consistently using version
numbers makes it easier to refer to the exact version you mean.
Instead of requiring the graphics driver to create a fixed set of VTs in
advance. This fixes the graphical interface when there is a graphics
driver but no boot framebuffer. Previously in that case vesad would exit
before it creates any VT and thus no consumer could show anything as
their VT was missing. In the future creating new VTs on the fly could
also allow a display manager to use a separate VT for each user session.
Effectively the only way to recover from errors in the communication
with pcid is by restarting the driver from scratch possibly after
restarting pcid. As such moving the aborts from individual drivers to
pcid_interface simplifies drivers while at the same time allowing nicer
error messages.
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.
bjorn3