23,114
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
linuxnewer 2002-07-25
- 打赏
- 举报
see
linuxnewer 2002-07-25
- 打赏
- 举报
see
wwwunix 2002-07-25
- 打赏
- 举报
建议看看unicon
daehappy 2002-07-21
- 打赏
- 举报
up!gz!
NetBird_China 2002-07-18
- 打赏
- 举报
miniChinput的源码挺好的
waterstream 2002-07-18
- 打赏
- 举报
为什么,我的正版redhat 7.3只有3张盘呢?~*~
x86 2002-07-18
- 打赏
- 举报
redhat 7.3 disk4 可以找到miniChinput的源码
x86 2002-07-18
- 打赏
- 举报
看看源代码吧，chinput或者zhcon都不错
uaiia 2002-07-18
- 打赏
- 举报
兄弟谢了！我早就试过了！很难找的！
StarLee 2002-07-18
- 打赏
- 举报
你可以去http;//www.google.com查查看
应该能找到的
应该能找到的
bittcn 2002-07-18
- 打赏
- 举报
通常Linux下控制台（console）是由几个设备构成的。分别是/dev/ttyN（其中tty0就是/dev/console，tty1、tty2就是不同的虚拟终端（virtual console））。这些tty设备对应于linux/drivers/char/console.c和lvt.c。其中console.c负责绘制屏幕上的字符，vt.c负责管理不同的虚拟终端，并且负责提供console.c需要绘制的内容。Vt.c把不同虚拟终端下的需要交给console.c绘制的内容，放到不同的缓存中去。Vt.c管理者这样一个缓冲区的数组，并且负责在这些缓存之间切换，并指定哪一个缓冲区是被激活的。你所看到的虚拟终端就对应着被激活的缓冲区。Console.c同时也负责接收终端的输入，然后把接收到的输入的信息放到缓冲区。
帧缓冲（framebuffer）
Framebuffer是把显存抽象后的一个种设备，可以通过这个设备的读写直接对显存进行操作。我们不必关心物理显存的位置、换页机制等等具体细节，这些都是由Framebuffer设备驱动程序来完成的。 Framebuffer对应的源文件在linux/drivers/video/目录下。总的抽象设备文作为fbcon.c，在这个目录下还有与各种显卡驱动程序相关的源文件。
在使用帧缓冲时，Linux是将显卡置于图形模式下的。
系统内核在显示字符时把每一个字符通过conv_uni_to_pc()转换成8位的显示字符。这样做的主要目的是使不同语言的国家能把16位的Unicode码映射到8位的显示字符集里，目前主要还是针对欧洲国家的语言，映射结果为8位，不包含双字节(double byte)的范围。
这种从Unicode到显示字符的映射表上，会把中文的字符映射到其他的字符上，这是我们不希望看到也是不需要的，所以我们有两种选择：
1） 不进行conv_uni_to_pc()的转换
2） 加载符合双字节处理的映射关系，即对控制字符进行一对一的不变映射，我们自己定制了一个符合这种映射关系的Unicode码表是direct.uni。
要想看/装载当前系统的Unicode映射表，可使用外部命令loadunimap。
经过conv_uni_to_pc()转换之后，”hello, world.\n”中的字符被一个一个地填写到tty的缓冲区中，然后do_con_write()调用底层的驱动程序，把缓冲区中的内容输出到显示器上（也就相当于把缓冲区的内容拷贝到VGA显存中去）
sw->con＿putcs(vc_cons[currcons].d,
(u16 *)draw_from, (u16 *)draw_to_
(u16 *)draw_rwom, Y, draw_x);
之所以要调用底层驱动程序,是因为存在不同的显示设备,其对应VGA显存的存取方式也不一样。
上面的Sw->con_putcs()就会调用fbcon.c中的fbcon_putcs()函数(con_putcs是一个函数的指针，在 Framebuffer模式)下指向fbcon_putcs()函数，也就是说，在do_con_write()函数中是直接调用了fbcon_putcs()函数来进行字符的绘制，比如说在256色模式下，真正负责输出的函数是：void fbcon_cfb8_putcs(struct vc_data *conp,struct display *p, const unsignde short *s, int count, int YY, int xx )
显示中文
比如说我们试输出一句中文：putcs(你好\n”)（“你好”的内码为0xc4.0xe3.0ba.0xc3）。这时候会怎么样呢？有一点可以肯定，“你好”肯定不会出现在屏幕上，原因是：
1、核心中没有汉字字库，中文显示就是无米之炊了。
2、在负责字符显示的void fbcon_cfb8_putcs()函数中，原有操作如下：
对于每个要显示的字符，依次从虚拟终端缓冲区中以WORD为单位读取（低位字节是ASCII码，高8位是字符的属性）。由于汉字是双字节编码方式，所以这种操作是不可能显示出汉字的，只能显示出xxxx_putcs()输出的是一个一个的VGA字符。
因此，要解决的问题：确保在调用do_con_write()时进行uni_pc转换不会改变原有编码，一个很直接的实现方式就是加载一个我们自己定制的Unicode映射表，loadunimap dirdct.uni，或者进接把direct.uni设置为核心的缺省映射表。
针对以上问题，我们要做的第一个尝试方案如下：
首先需要在核心中加载汉字字库，然后修改fbcon_cfb8_putcs()函数，在fbcon_cfb8_putcs()中一次读两个WORD，检查这两个WORD的低位字节是否能拼成一个汉字，如果发现能拼成一个汉字，就算出这个汉字在汉字字库的的偏移，然后把它当成个16×16的VGA字符来显示。
试验的结果表明：
1、能够输出汉字，但仍有许多不理想的地方，比如说，输出以半个汉字开始的一串汉字，则这半个汉字后面的汉字都会是乱码，这是“半个汉字”的问题。
2、光标移动会破坏汉字的显示，表现为，光标移动过的汉字会变成乱码，这是因为光标的更新是通过xxxx_putc()函数来完成的。
xxxx_putc()函数与xxxx_putcs()函数实现的功能够类似，但是xxxx_()函数只刷新一个字符而不是一个字符串，因而xxxx_putc()的输入参数是一个整数，而不是一个字符串的地址，xxxx_putc()函数的声明如下：
void fbcon_cfb8_putc(struct vc_data *conp, struct display *p, int c, int YY, int xx)
下一个尝试方案就是同时修改xxxx_putc()函数和xxxx_putc()函数为了解决半个汉字的问题，每一次输出之前，都从屏幕当前行的起始位置开始打措，以确定要输出的字符是否落在半个汉字的位置上，如果是在半个汉字的位置上，如果是在半个汉字的位置，则进行相应的调整，即从向前移动一个字节的位置开始输出。
这个方案有一个困难，即xxxx_putc()函数不用缓冲区的地址，而是用一个整数作为参数，所以xxxx_putc()无法直接利用相邻的字符来判别该字符是否是汉字。
解决方案是，利用xxxx_putc()的光标们置参数（yy,xx），可以逆推出该字符在缓冲区中的位置，但仍一些小麻烦，在Linux的虚拟终端下，用户可能会上卷该屏幕(Shift+Pageup)，导致光标的y座标和相应字符在缓冲区的行数不一致，相应的解决方案是，在逆推的过程中，考虑在屏的参量。
这样一来，我们就又进了一步，得到了一个相对更好的版本。但仍有问题没有解决，敲入turbonetcfg，会发现菜单的边框字符也被当成汉字显示，这是因为，这种边框字符是扩展字符，也使用了字符的低8位，因而被当成汉字显示，这是因为，这种边框字符是扩展字符，也使用了字符的低8位，因而被当作汉字来赤示。例如，单线“—”的制表符内码为0xC4，当连成一条长线时就是由一连串0xC4组成的，而0Xc4c4正是汉字“哪”，于是水平的制表符被一连串的“哪”字替代了，因为制表符的种类比较多，而且垂直制表符与其后面字符的组合形式又多种多样，因而很难判断出相应位置的字符是不是制表符，从理论上说，无论采取什么样的排除算法，都必然存在误判的情况，因为总存在二义性，没有充足的条件来推断出当前字符究竟是制表符还是汉字。
我们一方面寻找更好的排除组合算法，一方面试图寻找其他的解决方案，要想从根本上解决这个问题，必须利用其他的辅助信息，仅仅利用缓冲区的字符来判断是不够的。
经过一番努力，我们发现，在UNIX中使用扩展字符时，都要先输出字符转义序列（Escape sepuence）来切换当前字符集。字符转义序列是以控制字符Ecs为首的控制命令，在UNIX的虚拟终端中完成终端控制命令，这种命令包括移动光标座标、卷屏、删除、切换字符集等等。也就是说，在输出代表制表的字符串之前，通常是要先输出特定的字符转义序列，在console.c里，有根据字符转义序列命令来记录字符状态的变量，结合该变量提供的信息，就可以非常准确地把制表符与汉字区别开来。
在如上思路的指引下，我们又产生了新的解决方案，经过改动得到了另一版本。
在这个新的版本上，turbonetcfg在初次绘制的时候，制表符与汉字被清晰地区分开，但还有问题：turbonetcfg在重绘的时候（如切换虚拟终端或是移动鼠标光标的），制表符还是变成了汉字，因为重绘完全领带于缓冲区，而这时用来记录字符集状态的变量并不反映当前字符集状态。问题还是没有最终解决，我们又回到了起点。
看来问题的最终解决手段必须是把字符集的状态伴随着每一个字符在缓冲区中，让我们来研究一下缓冲区的结构。
每一个字符占用16位的缓冲区，低6、8位是ASCII值，完全被利用，高8位应是前景颜色和背景颜色的属性，也没有多余的空间可以利用，因而只能另外开辟新的缓冲区。为了保持一致性，我们决定在原来的缓冲区后面添加相同大小的缓冲区，用来存放是否汉字的信息。
其实，如果再添加一位来标志当前字符是汉字的左半边还是历半边的话，就会省去扫描屏幕上当前整行字符串的工作，这样一来，编程会更简单，但是有读者会问，即使是这样，使用8位总够用了吧？为什么还要使用16位呢？
我们的做法是：用低8位来存放汉字另外一半的内码，用高8位中的2位来存放上面所讲的辅助信息，高8位的剩余6位可以用来存放汉字或其他编码方式（如BIG5或日文、韩文）的信息，从而使我们可以实现同屏显示多种双字节语言的字符而不会相互干扰。另外，在编程时，双倍缓冲也比较容易计算。
迄今为止，我们有了一套彻底解决汉字和制表符相互干扰，半个汉字的刷新、重绘等问题的方案。剩下的就是具体编程来实现的问题了。
但是，由于Framebuffer的驱动程序很多，修改每一个驱动程序的xxxx_putc()函数和xxxx_putcs()函数会是一项不小的工作，而且，改动驱动程序后，每种驱动程序的测试也是很麻烦的，尤其是对于有硬件加速的显卡，修改和测试会更不容易。
那么，是否存在一种不需要修改显卡驱动程序的方法呢？经过一番努力，我们发现，可以调用xxxx_putcs()或xxxx_putc()函数输出汉字之前，修改VGA字库指针使其指向所需显示的汉字在汉字字库中的位置，即把一个汉字当成两个VGA ASCII字符输出。也就是说，在内核中存在两个字库，一个是原有的VGA字符字库，另一个是汉字字库，当我们需要输出汉字的时候，就把VGA字库的指针指向汉字字库的相应位置，汉字输出完之后，再把该指针指向VGA字库的原有位置。
这样一来，我们就只需要修改fbcon..c和console.c，其中console.c负责维护双倍缓冲区，把每一个字符的信息存入附加的缓冲区中；而fbcon.c负责利用双倍缓冲区中的附加的信息，调理 VGA字库的指针，调用底层的显示驱动程序。
这里还有几个需要注意的地方：
1、由于屏幕重绘等原因，调用底
帧缓冲（framebuffer）
Framebuffer是把显存抽象后的一个种设备，可以通过这个设备的读写直接对显存进行操作。我们不必关心物理显存的位置、换页机制等等具体细节，这些都是由Framebuffer设备驱动程序来完成的。 Framebuffer对应的源文件在linux/drivers/video/目录下。总的抽象设备文作为fbcon.c，在这个目录下还有与各种显卡驱动程序相关的源文件。
在使用帧缓冲时，Linux是将显卡置于图形模式下的。
系统内核在显示字符时把每一个字符通过conv_uni_to_pc()转换成8位的显示字符。这样做的主要目的是使不同语言的国家能把16位的Unicode码映射到8位的显示字符集里，目前主要还是针对欧洲国家的语言，映射结果为8位，不包含双字节(double byte)的范围。
这种从Unicode到显示字符的映射表上，会把中文的字符映射到其他的字符上，这是我们不希望看到也是不需要的，所以我们有两种选择：
1） 不进行conv_uni_to_pc()的转换
2） 加载符合双字节处理的映射关系，即对控制字符进行一对一的不变映射，我们自己定制了一个符合这种映射关系的Unicode码表是direct.uni。
要想看/装载当前系统的Unicode映射表，可使用外部命令loadunimap。
经过conv_uni_to_pc()转换之后，”hello, world.\n”中的字符被一个一个地填写到tty的缓冲区中，然后do_con_write()调用底层的驱动程序，把缓冲区中的内容输出到显示器上（也就相当于把缓冲区的内容拷贝到VGA显存中去）
sw->con＿putcs(vc_cons[currcons].d,
(u16 *)draw_from, (u16 *)draw_to_
(u16 *)draw_rwom, Y, draw_x);
之所以要调用底层驱动程序,是因为存在不同的显示设备,其对应VGA显存的存取方式也不一样。
上面的Sw->con_putcs()就会调用fbcon.c中的fbcon_putcs()函数(con_putcs是一个函数的指针，在 Framebuffer模式)下指向fbcon_putcs()函数，也就是说，在do_con_write()函数中是直接调用了fbcon_putcs()函数来进行字符的绘制，比如说在256色模式下，真正负责输出的函数是：void fbcon_cfb8_putcs(struct vc_data *conp,struct display *p, const unsignde short *s, int count, int YY, int xx )
显示中文
比如说我们试输出一句中文：putcs(你好\n”)（“你好”的内码为0xc4.0xe3.0ba.0xc3）。这时候会怎么样呢？有一点可以肯定，“你好”肯定不会出现在屏幕上，原因是：
1、核心中没有汉字字库，中文显示就是无米之炊了。
2、在负责字符显示的void fbcon_cfb8_putcs()函数中，原有操作如下：
对于每个要显示的字符，依次从虚拟终端缓冲区中以WORD为单位读取（低位字节是ASCII码，高8位是字符的属性）。由于汉字是双字节编码方式，所以这种操作是不可能显示出汉字的，只能显示出xxxx_putcs()输出的是一个一个的VGA字符。
因此，要解决的问题：确保在调用do_con_write()时进行uni_pc转换不会改变原有编码，一个很直接的实现方式就是加载一个我们自己定制的Unicode映射表，loadunimap dirdct.uni，或者进接把direct.uni设置为核心的缺省映射表。
针对以上问题，我们要做的第一个尝试方案如下：
首先需要在核心中加载汉字字库，然后修改fbcon_cfb8_putcs()函数，在fbcon_cfb8_putcs()中一次读两个WORD，检查这两个WORD的低位字节是否能拼成一个汉字，如果发现能拼成一个汉字，就算出这个汉字在汉字字库的的偏移，然后把它当成个16×16的VGA字符来显示。
试验的结果表明：
1、能够输出汉字，但仍有许多不理想的地方，比如说，输出以半个汉字开始的一串汉字，则这半个汉字后面的汉字都会是乱码，这是“半个汉字”的问题。
2、光标移动会破坏汉字的显示，表现为，光标移动过的汉字会变成乱码，这是因为光标的更新是通过xxxx_putc()函数来完成的。
xxxx_putc()函数与xxxx_putcs()函数实现的功能够类似，但是xxxx_()函数只刷新一个字符而不是一个字符串，因而xxxx_putc()的输入参数是一个整数，而不是一个字符串的地址，xxxx_putc()函数的声明如下：
void fbcon_cfb8_putc(struct vc_data *conp, struct display *p, int c, int YY, int xx)
下一个尝试方案就是同时修改xxxx_putc()函数和xxxx_putc()函数为了解决半个汉字的问题，每一次输出之前，都从屏幕当前行的起始位置开始打措，以确定要输出的字符是否落在半个汉字的位置上，如果是在半个汉字的位置上，如果是在半个汉字的位置，则进行相应的调整，即从向前移动一个字节的位置开始输出。
这个方案有一个困难，即xxxx_putc()函数不用缓冲区的地址，而是用一个整数作为参数，所以xxxx_putc()无法直接利用相邻的字符来判别该字符是否是汉字。
解决方案是，利用xxxx_putc()的光标们置参数（yy,xx），可以逆推出该字符在缓冲区中的位置，但仍一些小麻烦，在Linux的虚拟终端下，用户可能会上卷该屏幕(Shift+Pageup)，导致光标的y座标和相应字符在缓冲区的行数不一致，相应的解决方案是，在逆推的过程中，考虑在屏的参量。
这样一来，我们就又进了一步，得到了一个相对更好的版本。但仍有问题没有解决，敲入turbonetcfg，会发现菜单的边框字符也被当成汉字显示，这是因为，这种边框字符是扩展字符，也使用了字符的低8位，因而被当成汉字显示，这是因为，这种边框字符是扩展字符，也使用了字符的低8位，因而被当作汉字来赤示。例如，单线“—”的制表符内码为0xC4，当连成一条长线时就是由一连串0xC4组成的，而0Xc4c4正是汉字“哪”，于是水平的制表符被一连串的“哪”字替代了，因为制表符的种类比较多，而且垂直制表符与其后面字符的组合形式又多种多样，因而很难判断出相应位置的字符是不是制表符，从理论上说，无论采取什么样的排除算法，都必然存在误判的情况，因为总存在二义性，没有充足的条件来推断出当前字符究竟是制表符还是汉字。
我们一方面寻找更好的排除组合算法，一方面试图寻找其他的解决方案，要想从根本上解决这个问题，必须利用其他的辅助信息，仅仅利用缓冲区的字符来判断是不够的。
经过一番努力，我们发现，在UNIX中使用扩展字符时，都要先输出字符转义序列（Escape sepuence）来切换当前字符集。字符转义序列是以控制字符Ecs为首的控制命令，在UNIX的虚拟终端中完成终端控制命令，这种命令包括移动光标座标、卷屏、删除、切换字符集等等。也就是说，在输出代表制表的字符串之前，通常是要先输出特定的字符转义序列，在console.c里，有根据字符转义序列命令来记录字符状态的变量，结合该变量提供的信息，就可以非常准确地把制表符与汉字区别开来。
在如上思路的指引下，我们又产生了新的解决方案，经过改动得到了另一版本。
在这个新的版本上，turbonetcfg在初次绘制的时候，制表符与汉字被清晰地区分开，但还有问题：turbonetcfg在重绘的时候（如切换虚拟终端或是移动鼠标光标的），制表符还是变成了汉字，因为重绘完全领带于缓冲区，而这时用来记录字符集状态的变量并不反映当前字符集状态。问题还是没有最终解决，我们又回到了起点。
看来问题的最终解决手段必须是把字符集的状态伴随着每一个字符在缓冲区中，让我们来研究一下缓冲区的结构。
每一个字符占用16位的缓冲区，低6、8位是ASCII值，完全被利用，高8位应是前景颜色和背景颜色的属性，也没有多余的空间可以利用，因而只能另外开辟新的缓冲区。为了保持一致性，我们决定在原来的缓冲区后面添加相同大小的缓冲区，用来存放是否汉字的信息。
其实，如果再添加一位来标志当前字符是汉字的左半边还是历半边的话，就会省去扫描屏幕上当前整行字符串的工作，这样一来，编程会更简单，但是有读者会问，即使是这样，使用8位总够用了吧？为什么还要使用16位呢？
我们的做法是：用低8位来存放汉字另外一半的内码，用高8位中的2位来存放上面所讲的辅助信息，高8位的剩余6位可以用来存放汉字或其他编码方式（如BIG5或日文、韩文）的信息，从而使我们可以实现同屏显示多种双字节语言的字符而不会相互干扰。另外，在编程时，双倍缓冲也比较容易计算。
迄今为止，我们有了一套彻底解决汉字和制表符相互干扰，半个汉字的刷新、重绘等问题的方案。剩下的就是具体编程来实现的问题了。
但是，由于Framebuffer的驱动程序很多，修改每一个驱动程序的xxxx_putc()函数和xxxx_putcs()函数会是一项不小的工作，而且，改动驱动程序后，每种驱动程序的测试也是很麻烦的，尤其是对于有硬件加速的显卡，修改和测试会更不容易。
那么，是否存在一种不需要修改显卡驱动程序的方法呢？经过一番努力，我们发现，可以调用xxxx_putcs()或xxxx_putc()函数输出汉字之前，修改VGA字库指针使其指向所需显示的汉字在汉字字库中的位置，即把一个汉字当成两个VGA ASCII字符输出。也就是说，在内核中存在两个字库，一个是原有的VGA字符字库，另一个是汉字字库，当我们需要输出汉字的时候，就把VGA字库的指针指向汉字字库的相应位置，汉字输出完之后，再把该指针指向VGA字库的原有位置。
这样一来，我们就只需要修改fbcon..c和console.c，其中console.c负责维护双倍缓冲区，把每一个字符的信息存入附加的缓冲区中；而fbcon.c负责利用双倍缓冲区中的附加的信息，调理 VGA字库的指针，调用底层的显示驱动程序。
这里还有几个需要注意的地方：
1、由于屏幕重绘等原因，调用底
uaiia 2002-07-18
- 打赏
- 举报
那位发到我的邮箱：uaiia@163.net 立即送分！
