·OpenBSD最初是文本模式控制台。传统上，*BSD、Linuxon i386和AMD64使用文本模式控制台，默认情况下提供25行80列的80x25模式。此模式使用VGA BIOS中存储的8x16字体(不同供应商的字体可能略有不同)。
CRT显示器允许设置您想要的分辨率，因此在更大的显示器上，文本模式下的80x25控制台相当大，但不模糊。
FrameBuffer控制台允许利用更大的监视器尺寸，以容纳更多的列和行。由于转向液晶显示器，部分原因是笔记本电脑的成本不断下降，固定大小的面板成为一个问题，因为文本模式的分辨率需要拉伸，导致失真和模糊。
有些人可能没有意识到，文本模式和帧缓冲区控制台之间在覆盖整个屏幕所需写入的数据量方面存在巨大差异。在文本模式下，每个字符只需写入2字节：1字节用于ASCII码，1字节用于属性。因此，在80x25文本模式下，我们只需要写入80*25*2字节的数据，即4000字节，并且VGA卡本身负责将字符绘制到屏幕上。然而，在帧缓冲区中，要以32bpp模式填充4K UHD-1(3840x2160)屏幕，我们需要发送3840*2160*4字节的数据，即33177600字节(大约33MB)。
虽然它们已经在没有VGA卡的平台上使用了一段时间，但2013年才在i386和AMD64上为inteldrm(4)和radeondrm(4)启用了帧缓冲区控制台。
OpenBSD期刊上有一篇关于脾脏的文章，提供了更多信息，特别是关于与屏幕分辨率相关的字体选择机制。
有趣的是，尽管NetBSD多年来一直在向rasops(9)添加很多特性，但OpenBSD采取了更为保守的方法。然而，NetBSD目前拥有的一个主要功能将是有益的：加载不同规格的字体并随后调整屏幕大小的能力。
展望未来，各种操作的性能仍有可能提高，可能是通过利用新的OpenBSD动态跟踪机制来分析瓶颈。
另一个悬而未决的问题是UTF-8支持，miod Vallat早在2013年就开始了这方面的工作，但仍然有一些不足之处。我计划在未来实现稀疏字体文件支持，至少这样人们就可以利用方框绘制和可能的块元素字符。
最后，一个主要的痛点是RAMDISKkernels中缺少较大的字体，这使得安装和升级非常困难，而且由于文本基本上不可读，因此无法在大型DPI显示器上进行错误修复。没有技术上的障碍来实现这一点，具有讽刺意味的是，这使得它成为最难解决的问题。