Re: [Ksummit-discuss] Fwd: [TECH TOPIC] QR encoded oops for the kernel

[David Herrmann <dh.herrmann@gmail.com>]

Hi

On Wed, May 14, 2014 at 10:24 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Wed, May 14, 2014 at 10:00 PM, Levente Kurusa <levex@linux.com> wrote:
>> I as well would love to support QR codes in textmode, but I think that
>> it's really not possible at the moment.
>
> David Herrman is working on some new infrastructure for emergency log
> services on top of drm/kms drivers since we really, really want to
> move away from the horrors called fbcon. His design is fairly neat and
> there shouldn't be that big an issue with replacing the current
> character-painting code he has with some oops-painting code. Adding
> him to the discussion so he can point at some of the patches.

Still working on that, but I have no public tree for it right now. The
design basically asks all registered graphics driver for a
kernel-mapped framebuffer and the current mode/format. In case the
current FB is not / cannot be mapped, we try to flip to a fallback
buffer with the same mode/format. If even that fails, we try to do a
full modeset and DPMS stuff and more (this is all the responsibility
of the driver).
To avoid expensive call-paths, we do this step-by-step: first all
drivers are asked for the current FB and we render on all successfull
mappings. Then we continue with the remaining drivers and the
remaining options, and so on..

Note that setting a modern DRM driver into text-mode is far more
expensive than asking for the current FB. This is even mostly true for
any VESA-compatible card (through SimpleDRM). So I don't see why
anyone should bother using textmode for QR codes (but if you think
that's fun, I won't stop you).

The kernel-core will see one function, drm_render_oops() (or something
similar), which will try to do its best to render on all screens.
Default mode is rendering the kernel-log (through drm_log), but any
other stuff like QR is possible. There's a helper called
drm_draw_pixel() that can draw pixels in _any_ RGB format (maybe even
YUV and stuff), so the renderers don't even have to deal with DRM
formats.

I will show a prototype at LPC14, if anyone is interested.
David