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