From owner-svn-src-all@FreeBSD.ORG Wed Jan 8 15:48:46 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EE5D88F; Wed, 8 Jan 2014 15:48:46 +0000 (UTC) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 537E41644; Wed, 8 Jan 2014 15:48:45 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MZ300300A8H5Q00@smtpauth3.wiscmail.wisc.edu>; Wed, 08 Jan 2014 09:48:38 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.8.153914, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (pool-72-66-107-173.washdc.fios.verizon.net [72.66.107.173]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MZ300GLAAKXU820@smtpauth3.wiscmail.wisc.edu>; Wed, 08 Jan 2014 09:48:35 -0600 (CST) Message-id: <52CD7351.50704@freebsd.org> Date: Wed, 08 Jan 2014 10:48:33 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Aleksandr Rybalko 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 References: <201312052238.rB5McsVN020719@svn.freebsd.org> <20131208153620.GA21278@alchemy.franken.de> <20131210022015.2a5a1ed3.ray@freebsd.org> <52A65FC6.4000502@freebsd.org> <20140108171407.50135a65a9b767d61a73b186@freebsd.org> In-reply-to: <20140108171407.50135a65a9b767d61a73b186@freebsd.org> X-Enigmail-Version: 1.6 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Marius Strobl X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 15:48:46 -0000 On 01/08/14 10:14, Aleksandr Rybalko wrote: > On Mon, 09 Dec 2013 18:26:46 -0600 > Nathan Whitehorn wrote: > >> On 12/09/13 18:20, Aleksandr Rybalko wrote: >>> On Sun, 8 Dec 2013 16:36:20 +0100 >>> Marius Strobl 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