svn commit: r271023 - stable/10/sys/dev/vt

[Jean-Sébastien Pédron]

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.
> 
> 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 with
> 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 modified.

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.

-- 
Jean-Sébastien Pédron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20140904/cd5a99cc/attachment.sig>