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.
This will make it easier to change the way logging is done for all
drivers. This also fixes the log category for a couple of drivers as
well as makes failing to set the logger a fatal error. Only when a
logger is already set is it impossible to set another logger.
The current frame allocator limits requests to powers of two, between 4
KiB and 4 MiB. As such, a 8-bit color 1920x1080 framebuffer needs at
least two allocations.
bjorn3