“Now you can have both!”
Our console enhancement patchset updated for the latest OpenBSD release
Missing these features from your new OpenBSD 7.3 system?
There's no need to cry a river!
Just apply our rather spiffy patchset and compile away!
Great news!
We've created updated versions of our console enhancement patches, and they now apply to OpenBSD 7.3-release. What's more, these new versions are available to download immediately right from this page!
During the development cycle of OpenBSD 7.3, various patches developed at Exotic Silicon to enhance the functionality of the framebuffer console were accepted and added to CVS.
As a result of this, a stock installation of OpenBSD 7.3 now already includes support for a few additional control sequences for cursor movement, a backtab key, and directly setting the foreground and background color to the bright versions of the ANSI colors.
No additional manual patching is required to use these features anymore!
However, some of the other functionality that we developed at the same time has not yet been added to CVS, and as a result is not included in the standard OpenBSD 7.3 release.
(That's what this patchset fixes.)
The patchset has been divided in to four parts:
Note: a small piece of the italic code is intentionally included in part 1, to reduce the overall size of the patchset. However this code is effectively a no-op without part 3 installed.
Status of each part
Part 1
Well tested, and is expected to work on most if not all systems.
The actual rendering of the new attributes is only supported on 32-bpp framebuffers, but the code is not expected to crash or cause issues when run on non 32-bpp displays.
Part 2
Also well tested, and not expected to crash the kernel.
Compatibility with userland programs when using a termtype compatible with xterm should be very good. However there exists the possibility of differences in behaviour compared to the framebuffer console without this patch when using programs that configure the keyboard in unusual ways, (such as using the keypad in application mode).
Part 3
Known to have issues with some graphics drivers.
Typically such issues will result in a crash very early in the kernel initialisation. These issues have not been fully debugged yet, making this part currently unusable on the affected systems.
Part 4
Tested on a limited range of graphics hardware.
Whilst it is not expected the crash the kernel, the quality of the results from the graphical screendump routines may be sub-optimal. This function is still considered to be in the alpha stage of development. Text based screenshots are expected to work without problems, with the limitation that codepoints above 255 will not be preserved, but instead be reduced to the 0 - 255 range.
Compatibility of the various parts
The combination of all four patches applied has received much more testing than any other.
However, with some restrictions, it is possible to apply each part selectively if you don't want or can't use all of the features:
Quick-start cheat sheet
The simplest option, with the widest hardware compatibility is to:
  1. Apply parts 1 and 2, and set TERM=xterm-256color.
  2. Once this has been tested and seen to be working, then apply part 3 for testing.
  3. If necessary, back out part 3.
  4. Apply part 4.
  5. Copy the kernel header file /usr/src/sys/dev/wscons/wsconsio.h to /usr/include/dev/wscons/wsconsio.h
Remember to copy the updated kernel header file to the location expected by userland programs
Choosing a suitable termtype
The default termtype for the framebuffer console is vt220.
With none of the patches above installed, in other words on a stock installation of OpenBSD 7.3-release, the following termtype options are usable to varying degrees:
vt220Basically the lowest common denominator. No color support. Some function keys incorrectly mapped.
pcconMostly works, but has known issues. ANSI colors 0-7 only. Can't use color together with underline.
xtermWorks well for output. Some function keys will be incorrectly mapped. ANSI colors 0-7.
With parts 1 and 2 applied, the following options become available:
xtermNow works well for input and output. Function keys should work in the vast majority of cases. ANSI colors 0-7.
xterm-256colorAs above, but with 256 color support.
Here at Exotic Silicon, we are using the xterm-256color entry on a daily basis on production machines without any issues.
Using just one of either part 1 or part 2
It is technically possible to apply either part 1 or part 2 without the other part.
However this doesn't really create a useful system in most cases.
Note that with part 2 applied, (either alone or with other parts), the use of pccon is no longer recommended as some function keys will not work due to the new sequences.
If you particularly want or need to use the pccon termtype entry and cannot switch to either xterm or xterm-256color, but would like to have direct access to the new escape sequences implemented in part 1 independently of the terminfo system, then applying part 1 without part 2 will achieve this.
Alternatively, if you are not interested in the enhanced text rendering functions, but would like to use the xterm entry with programs that use function keys, then applying part 2 without part 1 is also possible. In this case, the xterm-16color entry can likely be used successfully, but this configuration has not been widely tested by us.
Using part 3
Screendumps - using part 4
To use the screendump kernel facilities, some accompanying userspace programs are required. These are almost unchanged from the versions used with the previous kernel patches for screendumps.
The file /usr/src/sys/dev/wscons/wsconsio.h needs to be copied to /usr/include/dev/wscons/wsconsio.h after applying the kernel patch, so that the userland screendump programs can find the new version.
Remember to copy the updated kernel header file to the location expected by userland programs after applying part 4 of the patchset
Downloading and applying the patches
The kernel patchset and userland utilities for the screendump facility are available to download in a single tar archive.
The individual files in the archive are signed with our signify key.
Assuming that you have downloaded the tar archive and our signify key to /root, the first two kernel patches can be applied as follows:
# cd /root
# tar -xf console_patches_73.tar
# cd /usr/src/
# signify -Vep /root/exoticsilicon.pub -x /root/console_patches_73/part_1.sig -m - | patch
# signify -Vep /root/exoticsilicon.pub -x /root/console_patches_73/part_2.sig -m - | patch
Then re-compile the kernel in the normal way, and re-boot in to the new kernel to test the new functionality.
Parts 3 and 4 can be applied in the same way, obviously replacing part_?.sig above with the correct filename.
After applying part 4, copy the modified header file to the /usr/include/ hierarchy:
# cp -p /usr/src/sys/dev/wscons/wsconsio.h /usr/include/dev/wscons/
The userland utilities for screendumps can then be compiled and added to /usr/local/bin:
# cd /root/screendump_utilities
# signify -Cp /root/exoticsilicon.pub -x checksums.sig
# cc -O3 -o screendump_graphical screendump_graphical.c
# cc -O3 -o screendump_text screendump_text.c
# mv screendump_graphical /usr/local/bin/
# mv screendump_text /usr/local/bin/
A demonstration program is also included that displays the 256 color palette along with various combinations of the new attributes:
# cd /root/demo
# signify -Cp /root/exoticsilicon.pub -x checksums.sig
# cc -O3 -o demo_256_and_attributes demo_256_and_attributes.c
# mv demo_256_and_attributes /usr/local/bin/
Taking screendumps
The userland screendump utilities are very simplistic, and intended as examples of how to use the new ioctls rather than comprehensive applications in their own right. For more programming information, please refer to the original console screendumps article.
Nevertheless, they are somewhat usable and can be invoked from the command line without any arguments.
The graphical screendump utility will create a single file rgb_screendump.ppm in the current directory.
The text screendump utility will create three files in the current directory:
Note that text-based screendumps of displays containing codepoints above 255 may contain unexpected control characters in the 0-31 and 160-192 range, due to the reduction of the character cell value to an unsigned 8-bit value.