From owner-svn-src-stable@FreeBSD.ORG Thu Sep 4 09:05:34 2014 Return-Path: Delivered-To: svn-src-stable@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 6C1F28E6; Thu, 4 Sep 2014 09:05:34 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 29392194A; Thu, 4 Sep 2014 09:05:34 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XPSyy-000AJE-9H; Thu, 04 Sep 2014 11:05:32 +0200 Message-ID: <54082B57.6070007@FreeBSD.org> Date: Thu, 04 Sep 2014 11:05:27 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Alexey Dokuchaev , Ed Maste Subject: Re: svn commit: r271023 - stable/10/sys/dev/vt References: <201409031400.s83E0bK6049810@svn.freebsd.org> <20140903140757.GA7494@FreeBSD.org> <20140903145753.GA25935@FreeBSD.org> In-Reply-To: <20140903145753.GA25935@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DK2vAneQ59WJfRLHsfdJusUX13K0lB5vh" Cc: svn-src-stable@freebsd.org, "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , svn-src-stable-10@freebsd.org X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 09:05:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DK2vAneQ59WJfRLHsfdJusUX13K0lB5vh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03.09.2014 16:57, Alexey Dokuchaev wrote: >> The VGA vt(4) issues all stem from the relatively complex and arcane >> VGA hardware and a somewhat limited vt_vga implementation. >=20 > Can you elaborate a bit on the technical side of things? Particularly,= it > looks strange that syscons(4) was able to work just fine on "relatively= > complex and arcane VGA hardware", while more modern vt(4) is fighting w= ith > problems. VGA requires that you write 8 pixels at a time (8 pixels stored in one byte). To update one pixel, the previous version of vt_vga would read one byte so that the 8 pixels are loaded in special registers (called "latches"), then would write a new byte to the video memory. The VGA hardware would process the new byte and the content of the latches to compute the final data. That's how one pixel out of eight could be modifi= ed. Unfortunately, reading from the video memory is very expensive. The new version of vt_vga never reads from the video memory. Instead, it uses the console history to know what those 8 pixels should look like and write one byte which doesn't need further processing. One bug in vt(4) was that the mouse cursor position, even if it was invisible before moused(8) starts, was always considered "dirty" and required a redraw. The default position being [0;0], each new character written would trigger a full refresh of the screen from [0;0] to the position of this character. Those two problems combined explain the slownness of vt(4), especially with discrete GPU and virtual machines; i915 users were mostly spared. Regarding the incorrect refresh when vt-switching, it was caused by a race between the redraw thread and the switch. The redraw thread was not stopped during a switch. Therefore, if the thread ran while the switch was in progress, it could mark the screen as "up-to-date" even though it displayed the wrong data. One change did reduce the vt-switch time specifically: in vt_vga, a switch triggers a clear of the video memory. The loop did read from the video memory, then wrote 8 black pixels. The useless read was removed. --=20 Jean-S=E9bastien P=E9dron --DK2vAneQ59WJfRLHsfdJusUX13K0lB5vh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUCCtbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMgQEP/068sb1oqO5Ei0IBR2hSs4qn NFlOEIiwhKQpHDiVfdLARtzCZKBRamhVGEFwJN6vbVQg4kBWmvi55gwyail6kM2Y boykexLupH1zmhJ+7sqLlbhdGyhOVffRzaGBZ7moJBdRqRn8yRLpBPjw/SSCGwxb xJw27/9lAWrAtyqhI0egZXywQEUegRKlWPjCAxkM3DAjYQexgj26Yjz+MbH4SDRa m5eKFJeQ6CM+nLHa7mepxvNFewlG45Gq/XpoRQJ3TnPH9S4+TuD3qDWwcc7RKQyh g/ctE/7Tgf8Gi0ONtrQFLCSSfBO1YD+D+RCrLYzANah2fTcgYgON8PbFKS1f6pRg kWIG2wobUGyocmblktbmzggTby/UFyxc/EvwAQyIWlR2KpBcWMH/C13wcfNncrkW GSMOpzWEsNzTYMqC/2W+HG1dXrquqi+8Y5duyxDWVolU2LNOrcmkJUnBtwwnBS2D gfBlVQTC0RLq1ftaJRm4QKJJspMlfiJiZwUkSuKkTJ9vO8l75fw+cqL0X4REx7Zr JkGJN6BZGVFlIgfDKlnNbo4fzUVUOmUd1Qcsqtpv543P2DR3OJQoB/GDQhLUqXJM eQPuwCieCIMgyzOM0HD6BnfPXa2cOMxY6JvN87dLeyBOlwqK8NeDL0TDwubnan63 UackK2RHnPvSui5FZwNu =KngB -----END PGP SIGNATURE----- --DK2vAneQ59WJfRLHsfdJusUX13K0lB5vh--