src-test/sys/dev/vt/vt.h, branch main

vt: clean up empty lines in .c and .h files

2020-09-01T21:47:32Z

Move font related data structured to sys/font.c and update vtfontcvt

2020-06-14T06:58:58Z

Prepare support to be able to handle font data in loader, consolidate data structures to sys/font.h and update vtfontcvt. vtfontcvt update is about to output set of glyphs in form of C source, the implementation does allow to output compressed or uncompressed font bitmaps. Reviewed by: bcr Differential Revision: https://reviews.freebsd.org/D24189

vt(4): Add support for `vidcontrol -C'

2020-05-28T21:22:30Z

Extract scrollback buffer initialization into a common routine, used both during vt(4) init and in handling the CONS_CLRHIST ioctl. PR: 224436 Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D24815

vt: store a pointer to the keyboard instead of index

2019-12-20T17:15:09Z

This effectively reverts r355935, but is functionally equivalent. We gain no benefit from storing the index and repeatedly fetching the keyboard with `kbd_get_keyboard` when we need it. We'll be notified when it's going away so we can clean up the pointer. All existing references were trivially converted. Only once instance actually needed the index.

vt: use colors from terminal emulator

2019-09-25T13:24:31Z

Instead of hardcoded colors, use terminal state. This also means, we need to record the pointer to terminal state with vtbuf.

Speed up vt(4) by keeping a record of the most recently drawn character and

2018-08-25T16:14:56Z

the foreground and background colours. In bitblt_text functions, compare values to this cache and don't re-draw the characters if they haven't changed. When invalidating the display, clear this cache in order to force characters to be redrawn; also force full redraws between suspend/resume pairs since odd artifacts can otherwise result. When scrolling the display (which is where most time is spent within the vt driver) this yields a significant performance improvement if most lines are less than the width of the terminal, since this avoids re-drawing blanks on top of blanks. (Note that "re-drawing" here includes writing to the VGA text mode buffer; on virtualized systems this can be extremely slow since it triggers a glyph being rendered onto a 640x480 screen). On a c5.4xlarge EC2 instance (with emulated text mode VGA) this cuts the time spent in vt(4) during the kernel boot from 1200 ms to 700ms; on my laptop (with a 3200x1800 display) the corresponding time is reduced from 970 ms down to 155 ms. Reviewed by: imp, cem Approved by: re (gjb) Relnotes: Significant speedup in vt(4) and the system boot generally. Differential Revision: https://reviews.freebsd.org/D16723

Clean up vt source whitespace issues

2018-05-16T11:19:03Z

vt(4): Resume vt_timer() in vtterm_post_input() only

2018-05-16T10:08:50Z

There is no need to try to resume it after each smaller operations (putchar, cursor_position, copy, fill). The resume function already checks if the timer is armed before doing anything, but it uses an atomic cmpset which is expensive. And resuming the timer at the end of input processing is enough. While here, we also skip timer resume if the input is for another windows than the currently displayed one. I.e. if `ttyv0` is currently displayed, any changes to `ttyv1` shouldn't resume the timer (which would refresh `ttyv0`). By doing the same benchmark as r333669, I get: * vt(4), before r333669: 1500 ms * vt(4), with this patch: 760 ms * syscons(4): 700 ms

teken, vt(4): New callbacks to lock the terminal once

2018-05-16T09:01:02Z

... to process input, instead of inside each smaller operations such as appending a character or moving the cursor forward. In other words, before we were doing (oversimplified): teken_input() vtterm_putchar() VTBUF_LOCK() VTBUF_UNLOCK() vtterm_cursor_position() VTBUF_LOCK() VTBUF_UNLOCK() Now, we are doing: vtterm_pre_input() VTBUF_LOCK() teken_input() vtterm_putchar() vtterm_cursor_position() vtterm_post_input() VTBUF_UNLOCK() The situation was even worse when the vtterm_copy() and vtterm_fill() callbacks were involved. The new callbacks are: * struct terminal_class->tc_pre_input() * struct terminal_class->tc_post_input() They are called in teken_input(), surrounding the while() loop. The goal is to improve input processing speed of vt(4). As a benchmark, here is the time taken to write a text file of 360 000 lines (26 MiB) on `ttyv0`: * vt(4), unmodified: 1500 ms * vt(4), with this patch: 1200 ms * syscons(4): 700 ms This is on a Haswell laptop with a GENERIC-NODEBUG kernel. At the same time, the locking is changed in the vt_flush() function which is responsible to draw the text on screen. So instead of (indirectly) using VTBUF_LOCK() just to read and reset the dirty area of the internal buffer, the lock is held for about the entire function, including the drawing part. The change is mostly visible while content is scrolling fast: before, lines could appear garbled while scrolling because the internal buffer was accessed without locks (once the scrolling was finished, the output was correct). Now, the scrolling appears correct. In the end, the locking model is closer to what syscons(4) does. Differential Revision: https://reviews.freebsd.org/D15302

Implement "vidcontrol -h " for vt(4)

2017-12-05T22:19:59Z

PR: 210415 Submitted by: Siva Mahadevan Reviewed by: ray (earlier) MFC after: 1 month Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D11814