[RFC] drm: add kernel-log renderer
David Herrmann <dh.herrmann <at> gmail.com>
2014-03-06 18:40:42 GMT
On modern linux user-space, the VT subsystem is no longer needed for
system consoles. Although most DEs will fail if VTs are disabled, there
are several gfx-systems that support this mode. Especially the lower
system stack has been extended to work without VTs.
However, there is one major drawback if VTs are disabled: You don't get
oops/panic-screens nor early boot-debugging. The VT subsystem registers a
console-driver, thus displays the kernel log and oops/panic screens in
those situations. This patch introduces a fallback for CONFIG_VT=n.
A new DRM-Log core is added. At its heart, DRM-Log maintains a log-buffer
of kernel-log messages. It registers a console-driver and pushes new
messages into this buffer whenever they appear. The size of the log-buffer
can be changed via drm_log_ensure_size(). Initially, a suitable buffer is
chosen, but whenever drivers register high-res CRTCs, they ought to
increase that buffer to guarantee there's always enough data to render the
This log-buffer is managed at the character-level, not pixel-level. It is
shared across all users, supports parallel, atomic readers and writers and
supports seamless resizing.
Additionally to the log-buffer handling, a generic software renderer is
introduced. drm_log_draw() renders the current log-buffer into any
memory-mapped framebuffer you want. Note that it supports splitting lines
in case your framebuffer is smaller than the log-buffer, but also merging
continuation lines in case your framebuffer is wider. This allows
rendering an 80x25 log-buffer in full-width on high-res displays. On the
other hand, 800x250 log-buffers can be rendered without information loss
(apart from a shorter backlog) on low-res displays.