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

[Alexey Dokuchaev]

On Thu, Sep 04, 2014 at 11:05:27AM +0200, Jean-SИbastien PИdron wrote:
> 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.

For quite a while (since I started using vt(4)) I'm observing a rather
annoying thing: sometimes small area of screen would get selected like if
pressed mouse button or something.  If I do a long build on the console,
periodically, white rectangle (selected area) will suddenly pop up and
scroll away.  Is this a known thing?  It can be very annoyting for text
editing on the console, as these sporadic "selects" are overwriting my
selection buffer contents with whatever was on the screen at that time
when they suddenly appear.  (Rat itself it motionless while it happens.)

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

I must say that after I rebuilt my -CURRENT kernel today, vt(4) behaves
much nicer than few weeks ago: switching is fast, no damaged screen any-
more (both before and after I do "kldload i915kms").  Good work guys, and
thanks for explanations!

./danfe