[RFC] drm: add kernel-log renderer
bonbons at linux-vserver.org
Thu Mar 6 13:56:31 PST 2014
On Thu, 06 March 2014 David Herrmann <dh.herrmann at gmail.com> wrote:
> 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
> whole screen.
> 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.
Does it make sense to express drm_log_ensure_size() with pixel arguments
and have the buffer below operated in characters? Shouldn't the pixel->char
calculation be done at a higher level? (see also below regarding high-DPI)
> 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.
Would it be possible to pass the dlog_font to drm_log_draw() so that
DRM driver or high-level code could choose a larger font on high-DPI
monitors (think retina-like)?
Without that option kernel would need to be built specifically for a
given DPI range and not be able to provide readable debug output on
multiple CRTCs with (very) different DPIs.
> No high-level API is introduced, yet. So for now drivers need to decide
> when and where to render on their own. A generic interface with
> panic-handlers, scheduled redrawing and automatic modesetting will be
> added in follow-ups.
> A few more notes:
> - This is for *debugging*, and for debugging only! You can use this
> renderer to get a kernel-log onto your framebuffers. However, the
> renderer is horribly slow! There is no intention to speed it up. No-one
> cares whether it takes 500ms to render your panic-screen!
> - If you enable the log-renderer for a continous boot-log, you're
> supposed to redraw on vblanks. The renderer does not support
> damage-tracking as each new-line causes a scroll-up, anyway.
> - The renderer works bottom-up and right-to-left. This is required to
> avoid pre-calculating log sizes.
> - The renderer supports multiple columns. This is quite handy on high-res
> screens where you can get bigger backlogs this way. Usually 80% of the
> screen are black. Now you can reuse this for the next log-column.
> - I have some wrappers to use this in user-space. I did several tests
> with resizing and different buffer-sizes and valgrind didn't complain.
> Results looked all fine.
> - The renderer supports *any* RGB target, from 8bit to 32bit with
> big-endian and little-endian support. The related pixel-renderer will
> probably never win a beauty-contest, but it works.. Again, who cares
> for debug-log rendering speed?
> - If you want a normal boot-log, use a user-space log-renderer (like
> experimential systemd-er (no merged, yet)). They can render with proper
> speed, can do hw-scrolling and more.
> Or: Enable VTs! Seriously, if you want all the VT features, use VTs! I
> will not tell you to disable them.
> On a last note:
> With this (and the high-level integration) in place, you can easily
> disable CONFIG_FB, CONFIG_VT and CONFIG_FRAMEBUFFER_CONSOLE. Combined
> with a proper user-space system-console, you will end up with more
> features, less bugs and definitely some happy kernel maintainers.
More information about the dri-devel