-- Leo's gemini proxy
-- Connecting to gemini.exoticsilicon.com:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
256 colours
Dim text
Invisible text
Double underline
Strike-through
True bold font rendering
Italic text
Keyboard control sequences that better match Xterm
Console screenshots
There's no need to cry a river ...
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!
... just apply our rather spiffy patchset and compile away!
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 colour to the bright versions of the ANSI colours.
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:
Part 1 - 256 colours, dim, invisible, double underline, and strike-through
Part 2 - Updated key sequences
Part 3 - True bold, and italic text rendering
Part 4 - Screenshot functionality
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.
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.
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).
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.
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.
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:
Either of parts 1 and 2 can be applied in isolation, or both can be applied together.
Part 3 requires part 1, which should be applied first if applying all of the first three patches.
Part 4 is intended to be applied on top of parts 1, 2, and 3.
Part 4 can be applied to a system which has only received parts 1 and 2, and skipped part 3. In this case, the patch for part 4 will apply with an offset which can be ignored.
Part 4 can also be applied to a system which has not received any of the other parts. In this case, the patch will report some offsets and a non-existent line in the source file, which can also be ignored.
The simplest option, with the widest hardware compatibility is to:
Apply parts 1 and 2, and set TERM=xterm-256color.
Once this has been tested and seen to be working, then apply part 3 for testing.
If necessary, back out part 3.
Apply part 4.
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
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:
vt220 - Basically the lowest common denominator. No colour support. Some function keys incorrectly mapped. pccon - Mostly works, but has known issues. ANSI colours 0-7 only. Can't use colour together with underline. xterm - Works well for output. Some function keys will be incorrectly mapped. ANSI colours 0-7.
With parts 1 and 2 applied, the following options become available:
xterm - Now works well for input and output. Function keys should work in the vast majority of cases. ANSI colours 0-7. xterm-256color - As above, but with 256 colour support.
Here at Exotic Silicon, we are using the xterm-256color entry on a daily basis on production machines without any issues.
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.
Part 3 requires part 1 to have been applied first.
Part 3 does not require part 2 in order to compile, but for practical usage in conjunction with the xterm-256color termtype, part 2 will likely be desired so that the function keys generate control sequences that are appropriate for that termtype.
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 userland utility for graphical screendumps does not require any changes to work on an OpenBSD 7.3 system with the new version of the kernel patches.
The userland utility for text screendumps should either be re-compiled with the ENHANCED_CONSOLE compile time option set, if this was not previously enabled, or alternatively upgraded to version 1.1, which always has this functionality included and removes support for the old bitfield layout used in OpenBSD 7.2.
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
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:
RWRn5d3Yx35u01WPIhNxZWPAEXOTIciNJeYgzB2l1RyHE5VIhpA3Bc+I
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 colour 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/
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:
screendump.asc contains the contents of the screen as ASCII, (or more correctly, 8-bit), text, with lines trimmed to their correct length, and line breaks inserted at the end of each line. Codepoints above 255 are reduced modulo 256.
screendump.raw also contains the raw values reduced modulo 256, but doesn't trim lines or insert line breaks. As a result, each visible screen line is effectively padded with spaces to the width of the terminal.
screendump.html is a very simple attempt to preserve colour and some formatting of the dumped display as HTML with embedded CSS.
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.
Copyright 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023 Exotic Silicon. All rights reserved.
-- Response ended
-- Page fetched on Sat May 11 19:28:32 2024