From owner-svn-src-stable-10@FreeBSD.ORG Fri Sep 5 22:51:23 2014 Return-Path: Delivered-To: svn-src-stable-10@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42B33889 for ; Fri, 5 Sep 2014 22:51:23 +0000 (UTC) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B64B41AEE for ; Fri, 5 Sep 2014 22:51:22 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id el20so6087589lab.6 for ; Fri, 05 Sep 2014 15:51:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=K0TJAeFe7oAYpxjQvt2VbN+9v4jClV9XzS8Xgnj3vgI=; b=kAXRl2qFuh20s+h63nnBq2jsmveSpaDEZUfCuOKoXpvCwPg8erim25f0XIrGKSpp+V PDRF2EeYOB4O2jOq3dVzF3B66S+m2uY3fdaOsoGaWBClaQNo+z+kFw6HJHSsmLQ7TbSO KqeGpcxVYda1vYfLy83btMm7o1RnkB5Njl+RTA5oRkQk1h9EDzz2eL7VRKx7n1b38vRw gLxv7nw4XwnRHZI7utKWkj1L5iY+Cv+5IIyHtXUvk0luEkYwlAEktgcJpIPAQE9MmKdD YZz3Xvgb/CIn0nmtA+z6WJYuy3vEX9QWshpxyqTWQH8A0dPvoi1Jc47nI/1WIra90e0i /G8Q== X-Gm-Message-State: ALoCoQkr6UEx0EfM5mOfNSrVbdQpQ5as3WQ9U/BeC6x+EAhhVNyg8L/T0N4V5K3LvGLsiKMOiS3l X-Received: by 10.112.158.199 with SMTP id ww7mr13914041lbb.71.1409957473467; Fri, 05 Sep 2014 15:51:13 -0700 (PDT) Received: from raynote.ddteam.net (12-162-133-95.pool.ukrtel.net. [95.133.162.12]) by mx.google.com with ESMTPSA id s7sm1150472lby.45.2014.09.05.15.51.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Sep 2014 15:51:12 -0700 (PDT) Date: Sat, 6 Sep 2014 01:48:59 +0300 From: Aleksandr Rybalko To: Alexey Dokuchaev 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> <20140903145753.GA25935@FreeBSD.org> <54082B57.6070007@FreeBSD.org> <20140905163433.GA80322@FreeBSD.org> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 8bit Cc: "src-committers@freebsd.org" , Ed Maste , svn-src-stable@freebsd.org, "svn-src-all@freebsd.org" , svn-src-stable-10@freebsd.org, =?KOI8-U?Q?Jean-S=E9bastien_P=E9dron?= X-BeenThere: svn-src-stable-10@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for only the 10-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:51:23 -0000 Hi Alexey! On Fri, 5 Sep 2014 16:34:34 +0000 Alexey Dokuchaev 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