Currently only fbbootlogd and fbcond make use of support for multiple
damage areas and they are not all that performance critical anyway.
Orbital always passes a single damage area per write call. Out of all
graphics drivers we have and are likely to get only vesad could
potentially benefit from fine-grained damage areas. This commit doesn't
significantly impact performance of fbcond.
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.
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.
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