为何图形模式控制台也不能显示汉字要解释图形模式控制台为何不能显示汉字，首先我们来了解一下虚拟终端是怎么管理屏幕上的文字显示的。虚拟终端的实现在 drivers/tty/vt/vt.c 。代表虚拟终端的数据是 struct vc。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| struct vc{
struct vc_data;
struct work_struct;
};
故而 struct vc_data 才是我們要的虛擬終端的定義。我們先來看看 struct vc_data 到底定義了什麼東西吧。
struct vc_data 的定義在 include/linux/console_struct.h, 定義摘錄如下，爲了不延長篇幅，有省略的部分：
struct vc_data {
struct tty_port port; /* Upper level data */
unsigned short vc_num; /* Console number */
unsigned int vc_cols; /* [#] Console size */
unsigned int vc_rows;
省略 ...
const struct consw *vc_sw;
unsigned short *vc_screenbuf; /* In-memory character/attribute buffer */
unsigned int vc_screenbuf_size;
省略 ...
};
|
其中 vc_screenbuf 存储了虚拟终端要显示在屏幕上的文字。 const struct consw *vc_sw 指向控制台驱动提供的函数。虚拟终端利用里面的函数指针调用相应的操作，比如重绘屏幕，绘制一个字符等等。这些操作由 vgacon 和 fbcon 等控制台驱动实现。当你切换终端的时候，实际上就是把当前终端设置为你要切换过去的终端，并且重新绘制当前终端 vc_data->vc_screenbuf 存储的内容。当你从键盘输入命令或者程序运行过程中要输出内容的时候，虚拟终端首先将输出的字符进行编码转化，转化为对于字符的 GLYPH 代码，并且将 GLYPH 和当前字符属性结合，最后将合成结果写入当前光标所处的位置。内核中实际的算法要复杂的多，还牵涉到中断，但是为了简单快递的把我们关心的部分的核心表达出来，我使用一下伪代码表示不那么严谨的过程。希望了解全部的读者可以自行查看内核相关的代码，主要代码在 drivers/tty/vt.c 的 do_con_write() 中。
清单 1. 伪代码1
2
3
4
5
6
7
8
9
10
11
12
| vc_write(vc_data * vc, const char * string, int count){
for( ; count ; ){
/* 和当前编码有关，如果是 utf8 就以 utf8 方式解码不是 utf8 就按照 扩展的 ASCII 方式，也就是一个字节就是一个字母。*/
int glyph = next_char(vc->utf,&string,&count);
int c = vc_build_attribute(vc)|(vc_glyph_mask& glyph);
// 把当前设置的前景色背景色等属性结合 ,glyph 不能超过描述它的位段 ;
vc->vc_screenbuf[vc->vc_pos] = c; // 写入当前位置
update_pos(); // 更新当前光标位置
}
notify_redraw(vc); // 调用 cosole 这个观察者重会屏幕
}
|
你也许想知道 vc_screenbuf 指向的缓冲区的格式到底是怎样的，现在也可以回答 提到过的为何图像控制台依然不能支持汉字显示的问题了：vc_screenbuf 的格式就是 VGA 文字模式时显卡所使用的文字缓冲区格式。上述伪代码中的 vc_glyph_mask 就是 0xFF, 也就是 glyph 被截断只能 8 比特长度。打从一开始，fbcon 就是按照 VGA 字符发生器设计的。因为当 vc_screenbuf 的格式和 VGA 字符缓冲区的格式一致的时候，切换终端就可以只需要 memcpy ——快速的拷贝到 VGA 字符缓冲区就能实现“重绘”当前终端。现在看来这种做法局限性非常大，但是单年 PC 性能还不够强大的时候，能做到快速的重绘是非常重要的。重绘例程中，notify_redraw(vc) 用伪代码表示为
清单 2. notify_redraw(vc) 伪代码1
2
3
4
5
6
7
8
| notify_redraw(vc_data * vc){
for(int rows = 0 ; rows < vc->rows ; rows ++){
unsigned short * current_line = &
vc->vc_screen_buf [vc_size_row * rows + vc->vc_visible_origin ] ;
// 在屏幕的第 row 行第 0 列绘制一行 current_line 指向的内容共 vc->cols 个字符。
vc->vc_sw->con_puts(vc,current_line,vc->cols,0,rows);
}
}
|
vc_sw 是个由控制台代码提供的指针，类型为 structconsw * , 控制台驱动的初始化部分会使用 vt_unbind() 将自己绑定为虚拟终端使用的控制台，传入的信息中就包括 vc_sw。在 vgacon 中 vc_sw->con_puts 事实上就是将要显示的内容简单的拷贝到 VGA 的字符缓冲区。对于 fbcon 而言则要复杂的多。 fbcon 提供的 con_puts 将 glyph 作为一个下标在 vc->vc_font 中找到对应的位图数据，然后拷贝到帧缓冲区。 TTY-> 虚拟终端 -> 控制台 -> 屏幕的路径用一幅图片表达为：
图 2. 路径 图形模式控制台的改造
fbcon 将 glyph 作为下标到 vc_font 中获取位图数据，而 glyph 要么是一个 unicode （vc->utf=1 的时候，当然是被截断到 8 个比特）要么就是扩展的 ASCII 代码。由于扩展 ASCII 只有 8 个比特位表示一个字符，所以只能请出 unicode 作为中文的数字表示。要想控制台能支持汉字显示，需要解决 3 个问题：
- 必须使用 UTF-8 模式 ( 默认 vc->utf=1 即可 )
- 虚拟控制台的 vc_screenbuf 必须修改以为 glyph 提供至少 16bit 的空间。
- 图形控制台需要 vc_font包含更多的字符，不只是 255 个，并提供代码绘制双倍宽度的中文字形，字体中的字符按照 UNICODE 排列，这样 glyph 就是字符的 UNICODE 编码。
修改虚拟控制台一开始，我的打算是 vc_screenbuf 修改为 unsigned long long* 类型，32bit 给字符属性，分别表示 16bit 终端前景色和背景色。glyph 则拥有 31bit 的空间 , 因为汉字的宽度为双倍的英文字母 ，其中 1 bit 用来表示双字符宽度。比如 '我' 会表达为 两个 '我'，第二个'我'的最高位为 1：绘制任何字形的时候，只绘制字形的左半部分；如果发现最高位为 1 则绘制字体位图中的右半部分。这样同样的绘制代码可以适应英文字母和汉字。写入 vc_screenbuf 的时候， 如果是双倍宽度的字符，需要同时写入两份，第二份的最高位置 1 就可以。但是 vc_screenbuf 的格式已经被到处假定为每字符两个字节。如此修改导致牵一发动全身。许多艰涩难懂的代码都依赖 vc_screenbuf 是 每字符两个字节的设定，直接修改定义后，光是编译器能直接检测出来的就有百余个地方需要修改，还有更多的逻辑并不能被编译器检测出来。如此修改的后果就是会出现许多隐晦的错误，非常难于调式。挣扎后，为最终选择了另一条道路 :
为汉字重新分配一块 vc_unicode_screenbuf vc_unicode_screenbuf 紧挨着 vc_screenbuf , 事实上 vc_screenbuf 在分配空间的时候，多分配了一倍的空间，多分配的空间充作 vc_unicode_screenbuf，因此 struct vc_data 里并没有添加 vc_unicode_screenbuf 成员。 vc_unicode_screenbuf 同样为每字符 2 个字节，并不包含字符属性，所以 2 个字节如数用来保存 glyph。vc_screenbuf 格式未变，所以 vgacon 不需要修改，这就减少了大量的工作量。向 vc_screenbuf 写入字符的时候，同时写入一份到 vc_unicode_screenbuf 。如果是汉字，由于其 glyph 大于 254 , 所以 vc_screenbuf 的那两个字符 ( 汉字双倍宽度 ) 实际写入的是 0xff 和 0xfe ( 故而上文提到是 glyph 大于 254 的字符 ,0xfe 被保留它用了 )。0xff 表示该字符的 glyph 要到 vc_unicode_screenbuf 提取，然后绘制左半部分；0xfe 表示该字符的 glyph 要到 vc_unicode_screenbuf 提取，然后绘制右半部分。对于 glyph 大于 254 但是又不是双倍宽度的字符，就不需要 0xfe 作陪了。比如屏幕上显示的文字是黑底白字的 “牛 B” , vc_screenbuf 的内容就是 “0x00ff, 0x0ffe, 0x0f42 ” , vc_unicode_screenbuf 的内容则是 “牛 , 牛 ,b” 。这是因为一个汉字为两倍的英文字母宽度。在屏幕文字缓冲区上也必须占用两个字符的位置。并且必须有一种机制能知道应该绘制左半部分和右半部分，我使用的就是 0xff 和 0xfe。
修改图形控制台绘制代码要修改的地方只有 3 个。
- struct console_font 添加 charcount 成员。将主线内核的字体设置为 charcount = 255。 主线内核带的字体都是 255 个 glyph 的，所以没有添加字符个数的必要。不过我们即将要添加的字体会有数万字符。
- 添加一个新的字体，复盖 UNICODE BMP 基本区域的所有符号。
- 修改字符绘制代码，添加 vc_unicode_screenbuf 的支持。
字符绘制代码的修改比较繁琐，代码分布在 drivers/video/console/ 下的多个文件中。fbcon_putc(s) 由由 vc->vc_sw->con_putc(s) 调用， fbcon_putc(s) 转而调用分散于 drivers/video/console/ 的多个 puts 实现。因为终端要支持 console_rotate , decoration , timing , 故而每种模式下的绘制实现都是不同的。我拿 drivers/video/console/bitblt.c 最常用的不倾斜、不加装饰等的终端模式为例来讲解绘图部分的修改。由于中文字体为 16x16 点阵，是对齐的字体，故而其绘制代码为 bit_putcs_aligned() 原先的代码以 glyph 为下标到 vc->vc_font->data 获得字体数据，然后调用 fb_pad_aligned_buffer 执行块拷贝操作。我的修改很简单，原来获得字体数据的代码修改后放入 font_bits() 辅助函数。 在 font_bits 里，要判断 glyph 是否为 0xff 或者 0xfe, 如果不是，使用 glyph 为下标获得字体的左半部分后并返回。 如果是，则从 vc_unicode_screenbuf 获得真正的 glyph 数值，然后再依据现有的 glyph 是 0xff 还是 0xfe 去获得字体的右半部分还是左半部分返回。font_bits 获得字体数据后执行 fb_pad_aligned_buffer 块拷贝。需要修改的地方还有 drivers/video/console/fbcon_ccw.c fbcon_cw.c fbcon_ub.c 。依原理进行修改即可。 |
