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

[David Herrmann]

Hey

On Thu, Jul 28, 2016 at 4:15 PM, Noralf Trønnes <noralf at tronnes.org> 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?

Sorry, haven't done much on this stuff lately. I still appreciate
being put on CC, thanks for that!
I did change my mind several times when working on the VT-replacement
layer and everything involved. In the end, my plan was this:

 * Make VTs obsolete. Make sure a system can run with CONFIG_VT=n.
systemd-logind provides an alternative access-control, but I would not
mind dropping it as well and just go with a setup that only has a
single gfx/input user per seat. No VTs, no multiplexing, etc. (which
is what Ubuntu is going for with the system compositor).

 * Make fbdev obsolete. Provide SimpleDRM as a slow-path for any
graphics device that no real driver exists for. SimpleDRM always runs
a _shadow_ FB, so no direct access to gfx-resources from user-space.
If you need that, use something else.

 * Support turnover from SimpleDRM to other drivers. This is as simple
as destroying the related platform-device before loading a gfx-driver.
Patches exist, but requires i915 to move aperture-management out of
the ->load callback (i.e., out of drm_global_mutex). The best solution
would be to drop ->load entirely. It is not needed, anyway.

 * Write an in-kernel terminal layer that can be loaded as dynamic
module and is a pure API _consumer_. Nothing can depend on it, hence,
it is completely passive and can be loaded on-demand (unlike VTs,
which lots of stuff is hooked into). This terminal/console serves as
debugging console for developers and can be blended over any current
screen content. It simply grabs all input and shadows DRM-Master. It
can be toggled via SYSRQ. User-space is unaware of its existence.

Code for all these parts exists (I even wrote the console replacement
using the DRM atomic APIs). However, I got distracted with kdbus+bus1,
so haven't pushed on it lately.

I can see that the drmcon backend you propose is a nice-to-have, but I
don't think it is the ultimate solution. It is a step forward, though,
so maybe we should just take it and avoid thinking of the ultimate
dream-solution... I don't know.

If there is interest in pushing SimpleDRM and/or related parts, ping
me on IRC (@dvdhrm or via email in private). I'd gladly discuss this
and try to find some time to revive the patches.

Thanks
David