Bug 211922 - Marked areas do not get cleared after they get scrolled out of the buffer on vt
Summary: Marked areas do not get cleared after they get scrolled out of the buffer on vt
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.0-RC1
Hardware: amd64 Any
: --- Affects Some People
Assignee: Ed Maste
URL:
Keywords: vt
Depends on:
Blocks:
 
Reported: 2016-08-17 00:45 UTC by Stefan
Modified: 2019-12-05 17:56 UTC (History)
3 users (show)

See Also:
sblachmann: mfc-stable12?
emaste: mfc-stable11+
emaste: mfc-stable10+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 freebsd_triage 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.