When using vt console in text mode, the marked area does not get cleared after it scrolled out of the buffer. How to reproduce: 0. % less somelargetextfile 1. Mark some area with the left mouse button. 2. Then press and hold the space bar to quickly scroll. You will see the marked background color flash up regularly every time the console scroll buffer got cycled through. (Or build a kernel or such, you will see this flashing up regularly. You can verify that by clearing the marked area with a single mouse click - after that the repeated "flashing" of the former marking is gone. I am very willing to assist with finding and fixing the problem. So, if you need any details or more informations, just ask.
ray@ addressed most of this issue in r313547
A commit references this bug: Author: emaste Date: Wed Jul 19 13:28:25 UTC 2017 New revision: 321199 URL: https://svnweb.freebsd.org/changeset/base/321199 Log: MFC r313547, r313777: fix mouse selection when vt(4) scrolls r313547 (ray, submitted by hselasky): o Reset mouse selection when new lines reach selection lines. o Fix how selection handled on display. r313777 (rpokala): Un-break vt(4) for {powerpc,powerpc64,sparc64} LINT kernel builds The {powerpc,powerpc64,sparc64} LINT kernel builds fail with this error: sys/dev/vt/vt_buf.c:198: warning: 'vtbuf_htw' defined but not used Move vtbuf_htw() inside the '#if SC_NO_CUTPASTE' block where it belongs, and put it in the proper order. This fixes the immedate issue w/ vt(4), but all three then fail on different issues. PR: 211922 Relnotes: Yes Changes: _U stable/11/ stable/11/sys/dev/vt/vt_buf.c
A commit references this bug: Author: emaste Date: Wed Jul 19 13:32:08 UTC 2017 New revision: 321200 URL: https://svnweb.freebsd.org/changeset/base/321200 Log: MFC r313547, r313777: fix mouse selection when vt(4) scrolls r313547 (ray, submitted by hselasky): o Reset mouse selection when new lines reach selection lines. o Fix how selection handled on display. r313777 (rpokala): Un-break vt(4) for {powerpc,powerpc64,sparc64} LINT kernel builds The {powerpc,powerpc64,sparc64} LINT kernel builds fail with this error: sys/dev/vt/vt_buf.c:198: warning: 'vtbuf_htw' defined but not used Move vtbuf_htw() inside the '#if SC_NO_CUTPASTE' block where it belongs, and put it in the proper order. This fixes the immedate issue w/ vt(4), but all three then fail on different issues. PR: 211922 Relnotes: Yes Changes: _U stable/10/ stable/10/sys/dev/vt/vt_buf.c
Note there is still one todo ray@ identified in the commit: track mouse select direction Also a related issue described on the wiki page still exists: Having text marked for copy and paste and then launching something that clears the screen, f. e. vi(1), leaves the region of previous text still marked. However I believe the main problem reported in this PR is now fixed in stable/11 and stable/10 (but unfortunately not in then 11.1 release branch). Stefan, if you have an opportunity to test a kernel built from stable/11 and confirm I would appreciate it. This change is a candidate for an errata fix for FreeBSD 11.1
(In reply to Ed Maste from comment #4) Sorry for the late reply. The email with which I posted the initial bug report is invalid now, so I missed your update. I recently installed 11.1 Release, and the bug seems still present. I would be very willing to help testing, as I now found the cause for the main problem that kept me from using vt (see PR 224069). However, there is another problem with vt that made me switch back to sc. I need huge scrollback buffers. The defaults are way too small. How can I increase the buffer when using vt, like I do with sc "options SC_HISTORY_SIZE=32000"?
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"
This issue is only partially fixed. I used: % jot 500 | less - mark some text - page down: marked area cleared, as expected - attempt to mark some text (try to mark much of the window), observe gaps in marked area (2 chars marked, 2 not, repeating) - page down: marked area cleared, as expected - mark some text (observe gaps) - page up or scroll up 1 line at a time, observe marked area not cleared
Just installed a system with 12.0-RELEASE (from DVD ISO). I confirm that the issues which Ed Maste described in comments #4 and #7 are still present in 12.0 RELEASE r341666.
In follow up to Comment (In reply to Stefan B. from comment #8) Because freebsd-update from 12.0 to 12.1 borked the base source, rendering the system unable to build kernel, I was forced to reinstall from USB. When checking out whether the bug still exists on 12.1, I not only found that comment #8 still applies. I found that there are even more embarrassing issues with vt. If one plays with all three mouse buttons, it is quite easy to use vt as a painting program. Just see that screen photo: http://imgbox.com/lESbd8Bk Suggestion: Couldn't the VT console be put back to experimental status until its issues are fixed? This would relieve users from the need of switching to sc as very first post-installation step.
Hello Stefan, Wow, is it mouse track ontop of wrong marked area? Is it VGA driver? (Does not saw that with UEFI/KMS/FB) Thanks.
Ahh, sorry. Forgot to reread thread.
(In reply to Stefan B. from comment #9) > Because freebsd-update from 12.0 to 12.1 borked the base source, rendering the > system unable to build kernel, I was forced to reinstall from USB. Is there a PR for that issue? > Couldn't the VT console be put back to experimental status until its issues are > fixed? No, because sc(4) does not work with UEFI or with KMS graphics drivers, leaving many users with no console at all.
(In reply to Ed Maste from comment #12) > > Because freebsd-update from 12.0 to 12.1 borked the base source, rendering the > > system unable to build kernel, I was forced to reinstall from USB. > Is there a PR for that issue? I added one here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242457 (In reply to Aleksandr Rybalko from comment #10) System is an Atom 2550 with onboard graphics, 4GB RAM and a 4-port igb card, using unmodded 12.1-RELEASE GENERIC kernel. As the 12.0 sc console worked fine on it, I suppose the system is non-UEFI. It seems to be VGA driver, as dmesg said "vtvga0 vt vga driver on mobo". dmesg reported it as "vgapci0 VGA-compatible display" being the "boot video device". There are no other graphics cards installed, and there is no mention of UEFI/KMS/FB. The issue is really weird. Easiest way to reproduce: Put the vt console into "bug mode": Press two of the three buttons simultaneously. (Maybe moving mouse doing this or creating wheel events influences things, too) In about 1 of 10 times I am then able to "draw pictures" with a mouse key depressed. The "painting" on the photo was created by moving the mouse with the right key depressed, after marking a big part of the screen. If one "paints" on an unmarked screen area, the "painting" is white on black. Moving the mouse over the screen without depressing any mouse key doesn't change the "pictures". So I am not sure that the issue is of "mouse trace" type.
(In reply to Stefan B. from comment #13) > In about 1 of 10 times I am then able to "draw pictures" with a mouse key > depressed. > The "painting" on the photo was created by moving the mouse with the right key > depressed, after marking a big part of the screen. > If one "paints" on an unmarked screen area, the "painting" is white on black. If you can build and test on a stable branch, please give it a try now. Marked areas are still not cleared when scrolling up but I believe other issues should be fixed. Ensure that the stable branch includes at least: stable/13 9352de39c3dc stable/12 e4fcff8ee124
The issue originally reported in this PR is no longer reproducible and presumed fixed by the referenced commits in comment #14. To avoid confusion from having different issues mentioned in the same PR the issues I noted in comment #4 and comment #7 have been moved to a new PR, 260069.