From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 21:18:19 2014 Return-Path: Delivered-To: freebsd-current@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 D6A11986 for ; Tue, 19 Aug 2014 21:18:19 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A05E930FF for ; Tue, 19 Aug 2014 21:18:19 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s7JLIBHO021109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Aug 2014 14:18:11 -0700 Message-ID: <53F3BF13.7040208@freebsd.org> Date: Tue, 19 Aug 2014 14:18:11 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r269471 make unusable VT console References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> <53F30DF3.1090301@dumbbell.fr> <53F37B2D.3070807@FreeBSD.org> <53F38D8E.8090605@freebsd.org> <53F39F3D.9010104@FreeBSD.org> In-Reply-To: <53F39F3D.9010104@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVagRxhN2Cv8pUPYNu1gN9PI8/1m2ZcF3PoCkeyOCdISLPNm6Bp0A5vsbyBChUnWlFW1UMLBLoFq8FA3gUH4aZhDiFMlv2HGhDs= X-Sonic-ID: C;3LK7UuYn5BGYoPofoK8kYw== M;2MIJU+Yn5BGYoPofoK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 21:18:19 -0000 On 08/19/14 12:02, Jean-Sébastien Pédron wrote: > On 19.08.2014 19:46, Nathan Whitehorn wrote: >> On 08/19/14 09:28, Jean-Sébastien Pédron wrote: >>> o vt_vga introduces a new callback, vd_bitblt_text_t, which takes >>> as argument the text buffer, the dirty area, the font and the >>> cursor (position, map, colors). >> Why is this necessary? I'd really prefer to avoid complicating this API. >> One of the great things about writing newcons drivers is that there is >> basically only one function you need to implement. If the current API >> does not provide enough information to do this efficiently, I'd much >> rather change it than add new callbacks. > I don't want to have two callbacks for the same feature either, and I'd > like to transition other drivers to this new one. > > The current bitbltchr callback only knows about one character. In the > case of vt_vga, if this character (or the cursor) isn't aligned on > 8-pixels boundaries, it needs to redraw several "blocks" of pixels. With > this character-centric approach, if a block needs a redraw, it'll be > refreshed for the character on its left side, then refreshed again for > the character on its right side. > > The advantage of giving the callback the whole text/area is that it > allows the driver to manipulate the pixels block by block, instead of > character by character. > > The patch isn't finished yet. Meanwhile, I'll commit the bug fixes I > made (especially the cursor handling in vt_flush()). But eventually, the > plan is to convert all drivers to this new callback, if you find the new > API sensible. > That sounds great. There are only a few (3?) discrete implementations of bitbltchr in the tree right now, so the conversion should be easy. -Nathan