Date: Sat, 6 Sep 2014 01:48:59 +0300 From: Aleksandr Rybalko <ray@ddteam.net> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, Ed Maste <emaste@freebsd.org>, svn-src-stable@freebsd.org, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, svn-src-stable-10@freebsd.org, =?KOI8-U?Q?Jean-S=E9bastien_P=E9dron?= <dumbbell@FreeBSD.org> Subject: Re: svn commit: r271023 - stable/10/sys/dev/vt Message-ID: <20140906014859.1c31f3aac5c84605ec6155dc@ddteam.net> In-Reply-To: <20140905163433.GA80322@FreeBSD.org> References: <201409031400.s83E0bK6049810@svn.freebsd.org> <20140903140757.GA7494@FreeBSD.org> <CAPyFy2B8F_mWOeTGXormEQ2amzQ00rFotmsNpXmgaKTy63DYzA@mail.gmail.com> <20140903145753.GA25935@FreeBSD.org> <54082B57.6070007@FreeBSD.org> <20140905163433.GA80322@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Alexey! On Fri, 5 Sep 2014 16:34:34 +0000 Alexey Dokuchaev <danfe@FreeBSD.org> wrote: > 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.) Yeah, it is known. It is due different logic than in syscons(4). vt(4) save not skected text, but position inside history buffer. Return to old (well known syscons(4)) behaviour is in TODO. > > > 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 > -- Aleksandr Rybalko <ray@ddteam.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140906014859.1c31f3aac5c84605ec6155dc>