From owner-svn-src-all@FreeBSD.ORG Fri Sep 5 22:51:23 2014 Return-Path: Delivered-To: svn-src-all@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 4372188A 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 B64651AED for ; Fri, 5 Sep 2014 22:51:22 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id el20so6242401lab.34 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=cfCKqwOXlwAqTuKxDJbdbgEAetHAULPnxthZeotB/wOpEq/NXFNCZnhxDyfHgSbtzb 4eoM06BKN+kOp3MZ/R9QHXhvsoM3bJwF2+WOa4Xix1AofQwHWY7QfNNkQLn4m+MfNfIQ XT17pCSnmP7DSAiXSxnhvr6NMj3XprRHasRZS7wSc84XKT4AloxhLohLXJoVg3q8yu8b s8fWErVDpW6PzI8nuXQ5k2pCrmqIM7eqEeWWaTCQY56GmnGmWvNud96bsFT2DUHV+Agc Yp34vCeTT8D3zXNjYzC3WqtiZEy1nMn5xqE+NFCSFu8X2XI8CMOGibYHulrt+LhEFI+v aOiQ== X-Gm-Message-State: ALoCoQksznJWk7RSXfTOUKkYJJlxHkwVU+Hw22dgKiZGY6zD4L5VOkA1Z1cwL+VwnzS+fs0sUd9s 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-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" 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