Hi David, On Thu, 06 March 2014 David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > On modern linux user-space, the VT subsystem is no longer needed for > system consoles. Although most DEs will fail if VTs are disabled, there > are several gfx-systems that support this mode. Especially the lower > system stack has been extended to work without VTs. > > However, there is one major drawback if VTs are disabled: You don't get > oops/panic-screens nor early boot-debugging. The VT subsystem registers a > console-driver, thus displays the kernel log and oops/panic screens in > those situations. This patch introduces a fallback for CONFIG_VT=n. > > A new DRM-Log core is added. At its heart, DRM-Log maintains a log-buffer > of kernel-log messages. It registers a console-driver and pushes new > messages into this buffer whenever they appear. The size of the log-buffer > can be changed via drm_log_ensure_size(). Initially, a suitable buffer is > chosen, but whenever drivers register high-res CRTCs, they ought to > increase that buffer to guarantee there's always enough data to render the > whole screen. > This log-buffer is managed at the character-level, not pixel-level. It is > shared across all users, supports parallel, atomic readers and writers and > supports seamless resizing. Does it make sense to express drm_log_ensure_size() with pixel arguments and have the buffer below operated in characters? Shouldn't the pixel->char calculation be done at a higher level? (see also below regarding high-DPI) > Additionally to the log-buffer handling, a generic software renderer is > introduced. drm_log_draw() renders the current log-buffer into any > memory-mapped framebuffer you want. Note that it supports splitting lines > in case your framebuffer is smaller than the log-buffer, but also merging > continuation lines in case your framebuffer is wider. This allows > rendering an 80x25 log-buffer in full-width on high-res displays. On the > other hand, 800x250 log-buffers can be rendered without information loss > (apart from a shorter backlog) on low-res displays. Would it be possible to pass the dlog_font to drm_log_draw() so that DRM driver or high-level code could choose a larger font on high-DPI monitors (think retina-like)? Without that option kernel would need to be built specifically for a given DPI range and not be able to provide readable debug output on multiple CRTCs with (very) different DPIs. Bruno > No high-level API is introduced, yet. So for now drivers need to decide > when and where to render on their own. A generic interface with > panic-handlers, scheduled redrawing and automatic modesetting will be > added in follow-ups. > > A few more notes: > - This is for *debugging*, and for debugging only! You can use this > renderer to get a kernel-log onto your framebuffers. However, the > renderer is horribly slow! There is no intention to speed it up. No-one > cares whether it takes 500ms to render your panic-screen! > - If you enable the log-renderer for a continous boot-log, you're > supposed to redraw on vblanks. The renderer does not support > damage-tracking as each new-line causes a scroll-up, anyway. > - The renderer works bottom-up and right-to-left. This is required to > avoid pre-calculating log sizes. > - The renderer supports multiple columns. This is quite handy on high-res > screens where you can get bigger backlogs this way. Usually 80% of the > screen are black. Now you can reuse this for the next log-column. > - I have some wrappers to use this in user-space. I did several tests > with resizing and different buffer-sizes and valgrind didn't complain. > Results looked all fine. > - The renderer supports *any* RGB target, from 8bit to 32bit with > big-endian and little-endian support. The related pixel-renderer will > probably never win a beauty-contest, but it works.. Again, who cares > for debug-log rendering speed? > - If you want a normal boot-log, use a user-space log-renderer (like > experimential systemd-er (no merged, yet)). They can render with proper > speed, can do hw-scrolling and more. > Or: Enable VTs! Seriously, if you want all the VT features, use VTs! I > will not tell you to disable them. > > On a last note: > With this (and the high-level integration) in place, you can easily > disable CONFIG_FB, CONFIG_VT and CONFIG_FRAMEBUFFER_CONSOLE. Combined > with a proper user-space system-console, you will end up with more > features, less bugs and definitely some happy kernel maintainers. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
