From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruno =?UTF-8?B?UHLDqW1vbnQ=?= Subject: Re: [RFC] drm: add kernel-log renderer Date: Fri, 7 Mar 2014 08:44:20 +0100 Message-ID: <20140307084420.20eda4b9@pluto> References: <1394131242-29567-1-git-send-email-dh.herrmann@gmail.com> <20140306225631.0eb29cf3@neptune.home> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) by gabe.freedesktop.org (Postfix) with ESMTP id 3305AFB2D2 for ; Thu, 6 Mar 2014 23:52:23 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: David Herrmann Cc: Daniel Vetter , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org SGkgRGF2aWQsCgpPbiBGcmksIDcgTWFyIDIwMTQgMDA6NDE6MDUgKzAxMDAgRGF2aWQgSGVycm1h bm4gd3JvdGU6Cj4gT24gVGh1LCBNYXIgNiwgMjAxNCBhdCAxMDo1NiBQTSwgQnJ1bm8gUHLDqW1v bnQgd3JvdGU6Cj4gPiBPbiBUaHUsIDA2IE1hcmNoIDIwMTQgRGF2aWQgSGVycm1hbm4gd3JvdGU6 Cj4gPj4gT24gbW9kZXJuIGxpbnV4IHVzZXItc3BhY2UsIHRoZSBWVCBzdWJzeXN0ZW0gaXMgbm8g bG9uZ2VyIG5lZWRlZCBmb3IKPiA+PiBzeXN0ZW0gY29uc29sZXMuIEFsdGhvdWdoIG1vc3QgREVz IHdpbGwgZmFpbCBpZiBWVHMgYXJlIGRpc2FibGVkLCB0aGVyZQo+ID4+IGFyZSBzZXZlcmFsIGdm eC1zeXN0ZW1zIHRoYXQgc3VwcG9ydCB0aGlzIG1vZGUuIEVzcGVjaWFsbHkgdGhlIGxvd2VyCj4g Pj4gc3lzdGVtIHN0YWNrIGhhcyBiZWVuIGV4dGVuZGVkIHRvIHdvcmsgd2l0aG91dCBWVHMuCj4g Pj4KPiA+PiBIb3dldmVyLCB0aGVyZSBpcyBvbmUgbWFqb3IgZHJhd2JhY2sgaWYgVlRzIGFyZSBk aXNhYmxlZDogWW91IGRvbid0IGdldAo+ID4+IG9vcHMvcGFuaWMtc2NyZWVucyBub3IgZWFybHkg Ym9vdC1kZWJ1Z2dpbmcuIFRoZSBWVCBzdWJzeXN0ZW0gcmVnaXN0ZXJzIGEKPiA+PiBjb25zb2xl LWRyaXZlciwgdGh1cyBkaXNwbGF5cyB0aGUga2VybmVsIGxvZyBhbmQgb29wcy9wYW5pYyBzY3Jl ZW5zIGluCj4gPj4gdGhvc2Ugc2l0dWF0aW9ucy4gVGhpcyBwYXRjaCBpbnRyb2R1Y2VzIGEgZmFs bGJhY2sgZm9yIENPTkZJR19WVD1uLgo+ID4+Cj4gPj4gQSBuZXcgRFJNLUxvZyBjb3JlIGlzIGFk ZGVkLiBBdCBpdHMgaGVhcnQsIERSTS1Mb2cgbWFpbnRhaW5zIGEgbG9nLWJ1ZmZlcgo+ID4+IG9m IGtlcm5lbC1sb2cgbWVzc2FnZXMuIEl0IHJlZ2lzdGVycyBhIGNvbnNvbGUtZHJpdmVyIGFuZCBw dXNoZXMgbmV3Cj4gPj4gbWVzc2FnZXMgaW50byB0aGlzIGJ1ZmZlciB3aGVuZXZlciB0aGV5IGFw cGVhci4gVGhlIHNpemUgb2YgdGhlIGxvZy1idWZmZXIKPiA+PiBjYW4gYmUgY2hhbmdlZCB2aWEg ZHJtX2xvZ19lbnN1cmVfc2l6ZSgpLiBJbml0aWFsbHksIGEgc3VpdGFibGUgYnVmZmVyIGlzCj4g Pj4gY2hvc2VuLCBidXQgd2hlbmV2ZXIgZHJpdmVycyByZWdpc3RlciBoaWdoLXJlcyBDUlRDcywg dGhleSBvdWdodCB0bwo+ID4+IGluY3JlYXNlIHRoYXQgYnVmZmVyIHRvIGd1YXJhbnRlZSB0aGVy ZSdzIGFsd2F5cyBlbm91Z2ggZGF0YSB0byByZW5kZXIgdGhlCj4gPj4gd2hvbGUgc2NyZWVuLgo+ ID4+IFRoaXMgbG9nLWJ1ZmZlciBpcyBtYW5hZ2VkIGF0IHRoZSBjaGFyYWN0ZXItbGV2ZWwsIG5v dCBwaXhlbC1sZXZlbC4gSXQgaXMKPiA+PiBzaGFyZWQgYWNyb3NzIGFsbCB1c2Vycywgc3VwcG9y dHMgcGFyYWxsZWwsIGF0b21pYyByZWFkZXJzIGFuZCB3cml0ZXJzIGFuZAo+ID4+IHN1cHBvcnRz IHNlYW1sZXNzIHJlc2l6aW5nLgo+ID4KPiA+IERvZXMgaXQgbWFrZSBzZW5zZSB0byBleHByZXNz IGRybV9sb2dfZW5zdXJlX3NpemUoKSB3aXRoIHBpeGVsIGFyZ3VtZW50cwo+ID4gYW5kIGhhdmUg dGhlIGJ1ZmZlciBiZWxvdyBvcGVyYXRlZCBpbiBjaGFyYWN0ZXJzPyBTaG91bGRuJ3QgdGhlIHBp eGVsLT5jaGFyCj4gPiBjYWxjdWxhdGlvbiBiZSBkb25lIGF0IGEgaGlnaGVyIGxldmVsPyAoc2Vl IGFsc28gYmVsb3cgcmVnYXJkaW5nIGhpZ2gtRFBJKQo+IAo+IEkgZG9uJ3Qgd2FudCB0byBleHBv c2UgImNoYXJhY3RlciIgc2l6ZXMuIEFueSBleHRlcm5hbCBBUEkgc2hvdWxkIGJlCj4gZGVhbGlu ZyB3aXRoIHBpeGVscyBhbmQgb25seSBwaXhlbHMuIFRoZXJlIGlzIG5vIHJlYXNvbiB0byBsZXQg dGhlbQo+IGRlYWwgd2l0aCBnbHlwaHMgYW5kIHRleHQuLiBSZWdhcmRpbmcgRFBJLCBzZWUgYmVs b3cuCj4gCj4gPj4gQWRkaXRpb25hbGx5IHRvIHRoZSBsb2ctYnVmZmVyIGhhbmRsaW5nLCBhIGdl bmVyaWMgc29mdHdhcmUgcmVuZGVyZXIgaXMKPiA+PiBpbnRyb2R1Y2VkLiBkcm1fbG9nX2RyYXco KSByZW5kZXJzIHRoZSBjdXJyZW50IGxvZy1idWZmZXIgaW50byBhbnkKPiA+PiBtZW1vcnktbWFw cGVkIGZyYW1lYnVmZmVyIHlvdSB3YW50LiBOb3RlIHRoYXQgaXQgc3VwcG9ydHMgc3BsaXR0aW5n IGxpbmVzCj4gPj4gaW4gY2FzZSB5b3VyIGZyYW1lYnVmZmVyIGlzIHNtYWxsZXIgdGhhbiB0aGUg bG9nLWJ1ZmZlciwgYnV0IGFsc28gbWVyZ2luZwo+ID4+IGNvbnRpbnVhdGlvbiBsaW5lcyBpbiBj YXNlIHlvdXIgZnJhbWVidWZmZXIgaXMgd2lkZXIuIFRoaXMgYWxsb3dzCj4gPj4gcmVuZGVyaW5n IGFuIDgweDI1IGxvZy1idWZmZXIgaW4gZnVsbC13aWR0aCBvbiBoaWdoLXJlcyBkaXNwbGF5cy4g T24gdGhlCj4gPj4gb3RoZXIgaGFuZCwgODAweDI1MCBsb2ctYnVmZmVycyBjYW4gYmUgcmVuZGVy ZWQgd2l0aG91dCBpbmZvcm1hdGlvbiBsb3NzCj4gPj4gKGFwYXJ0IGZyb20gYSBzaG9ydGVyIGJh Y2tsb2cpIG9uIGxvdy1yZXMgZGlzcGxheXMuCj4gPgo+ID4gV291bGQgaXQgYmUgcG9zc2libGUg dG8gcGFzcyB0aGUgZGxvZ19mb250IHRvIGRybV9sb2dfZHJhdygpIHNvIHRoYXQKPiA+IERSTSBk cml2ZXIgb3IgaGlnaC1sZXZlbCBjb2RlIGNvdWxkIGNob29zZSBhIGxhcmdlciBmb250IG9uIGhp Z2gtRFBJCj4gPiBtb25pdG9ycyAodGhpbmsgcmV0aW5hLWxpa2UpPwo+ID4KPiA+IFdpdGhvdXQg dGhhdCBvcHRpb24ga2VybmVsIHdvdWxkIG5lZWQgdG8gYmUgYnVpbHQgc3BlY2lmaWNhbGx5IGZv ciBhCj4gPiBnaXZlbiBEUEkgcmFuZ2UgYW5kIG5vdCBiZSBhYmxlIHRvIHByb3ZpZGUgcmVhZGFi bGUgZGVidWcgb3V0cHV0IG9uCj4gPiBtdWx0aXBsZSBDUlRDcyB3aXRoICh2ZXJ5KSBkaWZmZXJl bnQgRFBJcy4KPiAKPiBGaXJzdCBvZiBhbGwsIEkgd29uJ3Qgc3VwcG9ydCBhbnkgZmFuY3kgaGln aC1EUEkgZmVhdHVyZXMsIHRoYXQncyBqdXN0Cj4gd3JvbmcgZm9yIGRlYnVnZ2luZyBzdHVmZi4g V2hhdCBJIGNhbiBkbyAoYW5kIHdoYXQgd2UgZG8gaW4gZmFsbGJhY2sKPiBjb25zb2xlcyBpbiB1 c2VyLXNwYWNlKSBpcyB0byBhZGQgYW4gImRwaSIgb3IgInNjYWxlIiBhcmd1bWVudCB0bwo+IGRy bV9sb2dfZHJhdygpIHdoaWNoIGRvZXMgX2ludGVnZXJfIHNjYWxpbmcgb2YgZ2x5cGhzLiBUaGlz IGFsbG93cyB5b3UKPiB0byByZW5kZXIgZ2x5cGhzIDJ4IG9yIDN4IC4uIGFzIGJpZyBhcyB1c3Vh bC4KCkludGVnZXIgc2NhbGluZyB3b3VsZCBkbyBhcyB3ZWxsLiBKdXN0IHNvbWUgd2F5IHRvIGF2 b2lkIHRpbnkgZ2x5cGhzCm9uIGhpZ2gtRFBJIG1vbml0b3JzIChzbyB0aGF0IGl0IGNhbiBiZSBh cHBsaWVkIHBlci1DUlRDKSBpcyBuZWVkZWQuCgo+IEkgZG9uJ3QgdGhpbmsgaXQgbWFrZXMgc2Vu c2UgdG8gbW9kaWZ5IGRybV9sb2dfZW5zdXJlX3NpemUoKS4gSSBtZWFuLAo+IHRoZSB3b3JzdCB0 aGF0IGNhbiBoYXBwZW4gaXMgdGhhdCB0aGUgKnRleHQqLWJhY2tsb2cgaXMgdHdpY2UgYXMgYmln Cj4gYXMgcmVxdWlyZWQuIEJ1dCBpZiB5b3UgaGF2ZSBhIGhpZ2gtZHBpIGRpc3BsYXksIHlvdSBh bHJlYWR5IHJlcXVpcmUKPiBsaWtlIDEweCBhcyBtdWNoIHNwYWNlIGZvciBlYWNoIGZyYW1lYnVm ZmVyIHRoYW4gZm9yIHRoZSBlbnRpcmUKPiBsb2ctYnVmZmVyLiBUaGUgbG9nLWJ1ZmZlciByZXF1 aXJlcyAxIGJ5dGUgcGVyICpjaGFyKi4gVGhlIGZyYW1idWZmZXIKPiByZXF1aXJlcyBhdCBsZWFz dCA4KjE2KjQ9NTEyIGJ5dGVzIHBlciBjaGFyLgoKVGhhdCdzIGZhaXIsIGVzcGVjaWFsbHkgYXMg ZHJtX2xvZ19lbnN1cmVfc2l6ZSgpIGlzIGdyb3ctb25seS4KCj4gQW55aG93LCBpbnRlZ2VyLXNj YWxpbmcgc2hvdWxkIGJlIGZhaXJseSBlYXN5IHRvIGdldCBkb25lLgoKSSB0aG91Z2h0IHByb3Zp ZGluZyB0aGUgZm9udCB0byBkcm1fbG9nX2RyYXcoKSBhbmQgZXhwcmVzcwpkcm1fbG9nX2Vuc3Vy ZV9zaXplKCkgaW4gY2hhcnMgLSBvciBwYXNzIGZvbnQgdG8gaXQgYXMgd2VsbCAtIHdvdWxkIGJl CmVhc2llciB0aGFuIHNjYWxpbmcuCgpCcnVubwoKPiBUaGFua3MKPiBEYXZpZApfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBs aXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNr dG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751210AbaCGHwY (ORCPT ); Fri, 7 Mar 2014 02:52:24 -0500 Received: from smtprelay.restena.lu ([158.64.1.62]:47508 "EHLO smtprelay.restena.lu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750834AbaCGHwX convert rfc822-to-8bit (ORCPT ); Fri, 7 Mar 2014 02:52:23 -0500 X-Greylist: delayed 480 seconds by postgrey-1.27 at vger.kernel.org; Fri, 07 Mar 2014 02:52:22 EST Date: Fri, 7 Mar 2014 08:44:20 +0100 From: Bruno =?UTF-8?B?UHLDqW1vbnQ=?= To: David Herrmann Cc: dri-devel@lists.freedesktop.org, Daniel Vetter , linux-kernel@vger.kernel.org Subject: Re: [RFC] drm: add kernel-log renderer Message-ID: <20140307084420.20eda4b9@pluto> In-Reply-To: References: <1394131242-29567-1-git-send-email-dh.herrmann@gmail.com> <20140306225631.0eb29cf3@neptune.home> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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