[RFC] drm: add kernel-log renderer

[Bruno Prémont]

Hi David,

On Fri, 7 Mar 2014 00:41:05 +0100 David Herrmann wrote:
> On Thu, Mar 6, 2014 at 10:56 PM, Bruno Prémont wrote:
> > On Thu, 06 March 2014 David Herrmann 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)
> 
> I don't want to expose "character" sizes. Any external API should be
> dealing with pixels and only pixels. There is no reason to let them
> deal with glyphs and text.. Regarding DPI, see below.
> 
> >> 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.
> 
> First of all, I won't support any fancy high-DPI features, that's just
> wrong for debugging stuff. What I can do (and what we do in fallback
> consoles in user-space) is to add an "dpi" or "scale" argument to
> drm_log_draw() which does _integer_ scaling of glyphs. This allows you
> to render glyphs 2x or 3x .. as big as usual.

Integer scaling would do as well. Just some way to avoid tiny glyphs
on high-DPI monitors (so that it can be applied per-CRTC) is needed.

> I don't think it makes sense to modify drm_log_ensure_size(). I mean,
> the worst that can happen is that the *text*-backlog is twice as big
> as required. But if you have a high-dpi display, you already require
> like 10x as much space for each framebuffer than for the entire
> log-buffer. The log-buffer requires 1 byte per *char*. The frambuffer
> requires at least 8*16*4=512 bytes per char.

That's fair, especially as drm_log_ensure_size() is grow-only.

> Anyhow, integer-scaling should be fairly easy to get done.

I thought providing the font to drm_log_draw() and express
drm_log_ensure_size() in chars - or pass font to it as well - would be
easier than scaling.

Bruno

> Thanks
> David