Bug 211922

Summary:	Marked areas do not get cleared after they get scrolled out of the buffer on vt
Product:	Base System	Reporter:	Stefan <blachste>
Component:	kern	Assignee:	Ed Maste <emaste>
Status:	Closed FIXED
Severity:	Affects Some People	CC:	emaste, grahamperrin, ray, sblachmann
Priority:	---	Keywords:	vt
Version:	11.0-RC1	Flags:	sblachmann: mfc-stable12? emaste: mfc-stable11+ emaste: mfc-stable10+
Hardware:	amd64
OS:	Any
See Also:	https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248628 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260069

Description Stefan 2016-08-17 00:45:39 UTC

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.

Comment 1 Ed Maste freebsd_committer

2017-02-10 14:24:56 UTC

ray@ addressed most of this issue in r313547

Comment 2 commit-hook freebsd_committer

2017-07-19 13:29:24 UTC

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

Comment 3 commit-hook freebsd_committer

2017-07-19 13:32:29 UTC

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

Comment 4 Ed Maste freebsd_committer

2017-07-19 13:41:23 UTC

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

Comment 5 Stefan B. 2017-12-04 04:32:05 UTC

(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"?

Comment 6 Eitan Adler freebsd_committer

2018-05-20 23:50:42 UTC

For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"

Comment 7 Ed Maste freebsd_committer

2019-09-20 11:05:05 UTC

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

Comment 8 Stefan B. 2019-10-22 09:38:01 UTC

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.

Comment 9 Stefan B. 2019-12-05 05:00:42 UTC

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.

Comment 10 Aleksandr Rybalko freebsd_committer

2019-12-05 08:21:47 UTC

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.

Comment 11 Aleksandr Rybalko freebsd_committer

2019-12-05 08:23:17 UTC

Ahh, sorry. Forgot to reread thread.

Comment 12 Ed Maste freebsd_committer

2019-12-05 15:51:28 UTC

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

Comment 13 Stefan B. 2019-12-05 17:56:02 UTC

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

Comment 14 Ed Maste freebsd_committer

2021-09-25 18:25:56 UTC

(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

Comment 15 Ed Maste freebsd_committer

2021-11-26 20:00:31 UTC

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.