This issue(s) seem to need a variety of reporting contexts for coverage. My coverage at this point is more of a check if something reverted for my type of context but when it started my context was a failure case.
I'm no longer testing a context based on the earlier patch (before its commital) but now caught up to recently enough on the ThreadRipper to have screen.textmode be the intended means of control: # ~/fbsd-based-on-what-freebsd-main.sh mm-src b1ea63e2e3c92d1346af067f5cf609e3e062f8b9 CommitDate: 2021-01-06 13:18:37 -0800 fa0b97dbe6e1 b1ea63e2e3c9 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. FreeBSD FBSDFHUGE 13.0-CURRENT FreeBSD 13.0-CURRENT mm-src-c255637-gfa0b97dbe6e1 GENERIC-NODBG amd64 amd64 1300133 1300133 For this vintage of my context . . . screen.textmode="1" works. (With the huge, blocky font on the 1920x1200 display. But nothing significant about that is recently changed.) screen.textmode="0" works, including with screen.font="8x16" . There is a difference, in that it displays some material at the very beginning that it was not displaying since the recent problems started (until now or so). This initial material displays in screen.textmode="1" style before the display switches to the screen.textmode="0" style of display for alter output. (I'm not complaining, just noting the visible sequence.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
