On Tue, Aug 2, 2016 at 3:41 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > 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. 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
