Date: Wed, 08 Jan 2014 10:48:33 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Aleksandr Rybalko <ray@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Marius Strobl <marius@alchemy.franken.de> Subject: Re: svn commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken Message-ID: <52CD7351.50704@freebsd.org> In-Reply-To: <20140108171407.50135a65a9b767d61a73b186@freebsd.org> References: <201312052238.rB5McsVN020719@svn.freebsd.org> <20131208153620.GA21278@alchemy.franken.de> <20131210022015.2a5a1ed3.ray@freebsd.org> <52A65FC6.4000502@freebsd.org> <20140108171407.50135a65a9b767d61a73b186@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/08/14 10:14, Aleksandr Rybalko wrote: > On Mon, 09 Dec 2013 18:26:46 -0600 > Nathan Whitehorn <nwhitehorn@freebsd.org> wrote: > >> On 12/09/13 18:20, Aleksandr Rybalko wrote: >>> On Sun, 8 Dec 2013 16:36:20 +0100 >>> Marius Strobl <marius@alchemy.franken.de> wrote: >>> >>>> On Thu, Dec 05, 2013 at 10:38:54PM +0000, Aleksandr Rybalko wrote: >>>>> Author: ray >>>>> Date: Thu Dec 5 22:38:53 2013 >>>>> New Revision: 259016 >>>>> URL: http://svnweb.freebsd.org/changeset/base/259016 >>>>> >>>>> Log: >>>>> Merge VT(9) project (a.k.a. newcons). >>>>> >>>>> Reviewed by: nwhitehorn >>>>> MFC_to_10_after: re approval >>>> Have you addressed any of the points raised in: >>>> http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045887.html >>>> to get VT(9) at least en par with syscons(4) regarding being able to >>>> use a hardware cursor, allowing different low-level console drivers >>>> to compete for the same hardware etc. in the meantime? >>>> >>>> Marius >>>> >>> Hello Marius! >>> >>> Yes and No :) >>> >>> Lets make it as list with short items: >>> 1. Making these drivers work as low-level console. >>> 2. Drivers priority. >>> 3. Using hardware acceleration. >>> 4. Using the 12 x 22 gallant font. >>> 5. Allowing Xorg to map the frame buffer. >>> 6. (Part of 5) Other register banks as needed. >>> 7. Allowing late attachment. >>> >>> Answers: >>> 1. Works, I did testing on ARM board Efika MX with vt_fb_early driver. >>> (Still have to discuss several things with arm@ guys, then commit) >> As I mentioned in my review, this particular code is a really weird >> bug-filled copy of ofwfb.c, which already works as a low-level console >> early in the boot process. > TODO :) > >>> 2. Works. F.e. amd64 start with vt_vga driver, then vt_kms driver >>> override it as more specific. >> I think Marius meant having early-boot drivers bid amongst each other >> for attachment.... > Early-boot drivers selected on console driver bid rules. I see early > drivers as something really special, because resource management is not > ready at this stage and many device even is not able to get all > required info to be initialized fully. So I prefer model with simple > driver like vt_fb_early which is replaced later by full functional and > allocated by kernel's resource management rules. > > The issue is that your vt_early is not a panacea. It's a driver for one specific type of hardware (the Efika/RPI framebuffer, it looks like), no different than any other. What if you have multiple options for framebuffers? For example, on PowerPC, there are three graphics console drivers: wiifb, ps3fb, and ofwfb. wiifb is in its own kernel, which simplifies things, but ps3fb and ofwfb are both in GENERIC64 and have to bid against each other to attach. They need to do it before the MMU is even up, because otherwise there is no option for a console. sparc64 likewise has a variety of "early" console drivers in GENERIC. There needs to be a way to handle this; it's why the whole "early" FB concept is flawed. There's also nothing particularly "early" about these drivers: on both PPC and SPARC, they do attach in early boot, but nothing ever replaces them. They are around for the whole life of the system. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52CD7351.50704>