On Sat, Jul 30, 2016 at 5:48 PM, Noralf Trønnes <noralf@xxxxxxxxxxx> wrote: > Den 29.07.2016 10:23, skrev Daniel Vetter: >> >> Actually adding David. >> -Daniel >> >> On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote: >>> >>> On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote: >>>> >>>> This patchset explores the idea of adding a DRM text mode >>>> (like VGA text mode) to get an alternative to fbcon/fbdev. >>>> >>>> David Hermann has done alot of work on a fbcon replacement: >>>> - drm: add kernel-log renderer (Mar 2014)[1] >>>> - kmscon: >>>> development started Nov 2011 >>>> added to systemd Oct 2014 >>>> removed from systemd Jul 2015[2] >>>> >>>> Since this work seems to have stalled, I propose an alternative solution >>>> to this problem that will also give VT console support while we're >>>> waiting >>>> for a userspace console. >>>> >>>> The idea is that the driver provides a modeset like with the fbdev >>>> emulation >>>> code, and from this a text buffer representation is made. The console >>>> code >>>> can now write to this text buffer and ask for the text buffer to be >>>> flushed/rendered to the pixel buffer. >>>> >>>> In this hack/implementation of the idea, I have just hijacked a CMA >>>> backed >>>> fbdev framebuffer to keep it simple. >>>> I have reused the default buffer format that VT uses. >>>> Getting panic handling to actually work, seems to be a challenge as >>>> Daniel >>>> describes on the DRMJanitors page[3]. >>>> >>>> Is this idea of a DRM text mode worth developing further? >>> >>> I guess some simpler drm console with vt support which would allow us to >>> get rid of fbdev could make sense. And there's definitely going to be a >>> lot of overlap with a full userspace solution using something like >>> kmscon. >>> >>> But we can't just add a new drm text console, there's a pile of prep work >>> needed that David started for either approach: >>> - Nuking fbdev means no more fbdev drivers for firmware consoles (uboot, >>> uefi, vga, ...). The simpledrm driver would cover this, would be great >>> to get that landed (especially now that we have the simple pipe >>> helpers!). > > > I have rebased simpledrm on drm_simple_display_pipe and have it working on > a Raspberry Pi. modetest gives me a wrong picture, but that is probably > because of some wrong format conversion since fbdev using the native > rgb565 format works fine. > > I could finish this up and send a patch unless David is working on > something? > > I have used this version of simpledrm: [PATCH 09/11] drm: add SimpleDRM > driver > https://lists.freedesktop.org/archives/dri-devel/2014-January/052594.html David seems busy with kdbus/bus1 still right now (I chatted with him on irc), so just go ahead. But please cc him so he can take a quick look and ack your version. >>> - One nice benefit of fbdev is that it automatically gets rid of these >>> firmware-based display drivers when the real driver loads. Some >>> drivers >>> do this properly even when fbdev isn't enabled (see >>> i915_kick_out_vgacon >>> and i915_kick_out_firmware_fb), but pretty much all others fail in >>> some >>> way or the other. David also had some code (iirc as part of simpledrm) >>> to solve this issue. >>> >>> - I think we need more than rbg565 render support, iirc David also had >>> some work in that area. >>> >>> - None of these approaches has a good answer yet to the configuration >>> question. For a full VT I think we definitely should share the setup >>> logic with the fbdev emulation code to make it useful, but as describe >>> in the DRMJanitors page handlings panics is an entierly different >>> problem. >>> >>> Definitely coordinate with David Herrmann here too, since if we do >>> something in this area it should be widely supported. >>> >>> Aside: Where's the pull request for your driver? ;-) > > > I have been working on tinydrm for 6 months straight now and it wasn't fun > anymore. So I figured this was a good time to take a break from it and do > something else for a while :-) :( Still looking forward to it, I think with all the nice prep work you've done it would be a shame if the reason for it all wouldn't make it in. -Daniel > > > Noralf. > > >>> Cheers, Daniel >>> >>>> >>>> Noralf. >>>> >>>> [1] https://lwn.net/Articles/589858/ >>>> [2] https://github.com/systemd/systemd/pull/747 >>>> [3] https://www.x.org/wiki/DRMJanitors/#makepanichandlingwork >>>> >>>> >>>> Noralf Trønnes (3): >>>> drm: Add support for text framebuffer >>>> drm/text: Add panic and boot console support >>>> drm/text: Add VT console support >>>> >>>> drivers/gpu/drm/Makefile | 1 + >>>> drivers/gpu/drm/drm-text/Makefile | 5 + >>>> drivers/gpu/drm/drm-text/drm-text-buffer.c | 340 >>>> ++++++++++++++++++++++++++++ >>>> drivers/gpu/drm/drm-text/drm-text-console.c | 205 +++++++++++++++++ >>>> drivers/gpu/drm/drm-text/drm-text-debugfs.c | 295 >>>> ++++++++++++++++++++++++ >>>> drivers/gpu/drm/drm-text/drm-text-vt.c | 197 ++++++++++++++++ >>>> drivers/gpu/drm/drm-text/drm-text.h | 99 ++++++++ >>>> 7 files changed, 1142 insertions(+) >>>> create mode 100644 drivers/gpu/drm/drm-text/Makefile >>>> create mode 100644 drivers/gpu/drm/drm-text/drm-text-buffer.c >>>> create mode 100644 drivers/gpu/drm/drm-text/drm-text-console.c >>>> create mode 100644 drivers/gpu/drm/drm-text/drm-text-debugfs.c >>>> create mode 100644 drivers/gpu/drm/drm-text/drm-text-vt.c >>>> create mode 100644 drivers/gpu/drm/drm-text/drm-text.h >>>> >>>> -- >>>> 2.8.2 >>>> >>>> _______________________________________________ >>>> dri-devel mailing list >>>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >>> -- >>> Daniel Vetter >>> Software Engineer, Intel Corporation >>> http://blog.ffwll.ch > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
