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

[Daniel Vetter]

On Tue, Aug 2, 2016 at 3:41 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
> 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.

Good news: We've just fixed that. And many drivers lost their ->load
callback too (But not yet amdgpu/radeon/nouveau unfortunately).
-Daniel

>  * 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



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch