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.
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.
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