[RFC 0/3] drm: Add DRM text mode

Tue Aug 2 13:05:53 UTC 2016

On Sat, Jul 30, 2016 at 5:48 PM, Noralf Trønnes <noralf at tronnes.org> 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 at lists.freedesktop.org
>>>> 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