From owner-svn-src-all@freebsd.org Sun Apr 9 07:58:47 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99557D369C8; Sun, 9 Apr 2017 07:58:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 2EEB1A45; Sun, 9 Apr 2017 07:58:46 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 2CDA3D6823A; Sun, 9 Apr 2017 17:33:10 +1000 (AEST) Date: Sun, 9 Apr 2017 17:33:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: Bruce Evans , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r316642 - head/sys/dev/syscons In-Reply-To: <23b8c635-f856-51b5-a338-d9bb53aefc7c@freebsd.org> Message-ID: <20170409164754.E1567@besplex.bde.org> References: <201704081000.v38A0dBU078784@repo.freebsd.org> <4a498d83-3b64-18ac-bb0f-890a0c2893fc@freebsd.org> <23b8c635-f856-51b5-a338-d9bb53aefc7c@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=zyuj5AaQCvbWOqxV1wsA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 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: Sun, 09 Apr 2017 07:58:47 -0000 On Sun, 9 Apr 2017, Andrey Chernov wrote: > On 09.04.2017 7:54, Andrey Chernov wrote: >> On 08.04.2017 13:00, Bruce Evans wrote: >>> Log: >>> Quick fix for removal of the mouse cursor in vga direct graphics modes >>> ... >> >> Please don't forget that this 5 cells range (0xd0-0xd4, last one becomes >> SC_CURSOR_CHAR) can be redefined with "vidcontrol -M", it is needed for >> the case they overlap valid characters region for some code tables. > > Probably we just can change default to remove additional vidcontrol -M > setup. I usually have this range started with 0x03. That can only work if you also avoid 9-bit text modes. 9-bit modes give 1-bit separations between characters, except for those in the graphics range (starting at about 0xd0). Hmm, syscons already seems to have bugs handling this. The mouse cursor is always 8x16, usually split into 4. For cells placed outside the graphics region, this gives 1-bit gaps in 9-bit mode. For cells placed in the graphics region, it is a difficult or impossible transformation which is not done to rearrange the pixels to fill in the gaps correctly. 9-bit mode basically gives an 9x16 cursor, but the 9th bit is already unusable within a single cell, since it would extend the rightmost pixels in the 8x16 cursor in an ugly way. These pixels are for 1 end of the arrow and the end of its right barb. The extension occurs every 8th x position when the cursor is moved from left to right. Also, when the cursor is moved over an ordinary character, the ordinary character is merged into the cursor and drawn as part of the cursor. This gives ugly extensions of '0' characters in a font carefully designed for 9-bit mode (the '0' characters are a full 8 bits wide and if they are in the graphics range the become 9 bits wide with extra pixels on the right). This problem doesn't occur in graphics mode. However, graphics mode should support 9-bit mode in software, so that the fonts carefully designed for 9-bit mode can be used. 8 bits wide is too narrow for a good font (it requires '0' to be only 7 bits wide...), and is even worse when used with fonts designed for 9-bit mode (their '0's and 'M's are not separated). vt uses a 10x16 mouse cursor and only supports it in graphics mode. The extra bit makes it look much better. Support for 9-bit mode is otherwise worse in vt than in sc. E.g, the cp437 glyphs for line drawing characters don't work in 9-bit text mode, since a gap is left between then. I think the bit that controls extension is forced off together with the bit that controls blinking fg/bg brightness, so even if these glyphs are rendered using a char in the graphics range, they are not extended. 9-bit text modes are hard to avoid. 90-column sc modes avoid them, but tend to be broken on newer hardware. The newer hardware tends to force 9-bit modes because this is normal and works better. I have just 1 system (an 11 year old laptop) than forces 8-bit mode instead. Bruce