From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id AC396912 for ; Mon, 19 May 2014 11:59:15 +0000 (UTC) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA28B1F8A0 for ; Mon, 19 May 2014 11:59:13 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id y20so5205729ier.34 for ; Mon, 19 May 2014 04:59:13 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20140511162918.GA2527@linux.com> <1995824.rdvEX5SOIt@avalon> <20140511171824.GB2527@linux.com> <20140512161539.GX12708@titan.lakedaemon.net> <20140513070851.GA20002@thin> <53739333.30108@zytor.com> <20140514185449.GB4475@jtriplet-mobl1> <20140514200043.GA2516@linux.com> Date: Mon, 19 May 2014 13:59:13 +0200 Message-ID: From: David Herrmann To: Daniel Vetter Content-Type: text/plain; charset=UTF-8 Cc: PJ Waskiewicz , Sarah A Sharp , "ksummit-discuss@lists.linuxfoundation.org" , Anton Arapov , Dirk Hohndel Subject: Re: [Ksummit-discuss] Fwd: [TECH TOPIC] QR encoded oops for the kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi On Wed, May 14, 2014 at 10:24 PM, Daniel Vetter wrote: > On Wed, May 14, 2014 at 10:00 PM, Levente Kurusa 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