Hey On Thu, Jul 28, 2016 at 4:15 PM, Noralf Trønnes <noralf@xxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
