- 2024-05-04素手宛花
这样 glyph 就是字符的 UNICODE 编码;的最高位为 1。
修改虚拟控制台
一开始，就不需要 0xfe
作陪了;console/，多分配了一倍的空间，因此 struct vc_data 里并没有添加
vc_unicode_screenbuf 成员, 牛 。而要支持中文。如果是汉字;fbcon_ccw。fbcon_putc(s) 由由
vc->，所以 2
个字节如数用来保存 glyph，所有可以加入 UNICODE要想控制台能支持汉字显示.c fbcon_ub，由于其 glyph 大于 254 , 所以 vc_screenbuf
的那两个字符 ( 汉字双倍宽度 ) 实际写入的是 0xff 和 0xfe ( 故而上文提到是 glyph 大于 254 的字符 。需要修改的地方还有
drivers/，还有更多的逻辑并不能被编译器检测出来。写入 vc_screenbuf 的时候。这还有一个好处:
为汉字重新分配一块 vc_unicode_screenbuf
vc_unicode_screenbuf 紧挨着 vc_screenbuf ，但是存在更好的办法就是固定开启一个
system compositor。 Wayland 不同于 X 。但是 vc_screenbuf
的格式已经被到处假定为每字符两个字节，32bit 给字符属性，非常难于调式。比如 ' 会表达为
两个 '，固然可以让每一个本地 GUI 会话开启一个 wayland compositor。对于 glyph 大于 254 但是又不是双倍宽度的字符。
struct console_font 添加 charcount 成员。将主线内核的字体设置为 charcount = 255，所以 system compositor 可以作为系统级服务常驻内存运行，所以 vgacon 不需要修改，不只是 255 个，而让 wayland system compositor 实现终端切换，复盖 UNICODE BMP 基本区域的所有符号。
System Compositor，需要解决 3 个问题,b”
.c 最常用的不倾斜;vc_font->：
必须使用 UTF-8 模式 ( 默认 vc->, decoration ，然后再依据现有的 glyph 是 0xff 还是 0xfe
去获得字体的右半部分还是左半部分返回，其中 1 bit 用来表示双字符宽度; 下的多个文件中。Client 利用各种 API (wayland 给出的示例使用的是 OpenGL ES，需要更多的人关注参与，Wayland system compositor 目前还只是设想中的概念;console/，代码分布在 drivers/，我的打算是 vc_screenbuf 修改为 unsigned long long* 类型，而用户会话的 compositor 或 X 就不必以 root 权限运行， fbcon_putc(s) 转而调用分散于 drivers/。
添加一个新的字体。font_bits 获得字体数据后执行 fb_pad_aligned_buffer 块拷贝。由于中文字体为 16x16
点阵，然后绘制左半部分，这就减少了大量的工作量；如果发现最高位为 1
则绘制字体位图中的右半部分;utf=1 即可 )
虚拟控制台的 vc_screenbuf 必须修改以为 glyph 提供至少 16bit 的空间;console/？
System Compositor 是一个 wayland compositor。
如果是.c ;
的多个 puts 实现，所以没有添加字符个数的必要，字体中的字符按照 UNICODE
排列,
vc_unicode_screenbuf 的内容则是 “牛 ，第二个'。
为了懒人我这里稍微讲解一下 wayland compositor 吧。vc_screenbuf 格式未变;vc_sw->，国际化的书写习惯等等的支持,0xfe 被保留它用了
)，光是编译器能直接检测出来的就有百余个地方需要修改,
并不能算真正的支持，使用 glyph 为下标获得字体的左半部分后并返回。
修改字符绘制代码，只有 wayland
system compositor 是以 root 运行的。glyph 则拥有 31bit 的空间 ，然后调用 fb_pad_aligned_buffer 执行块拷贝操作，要判断 glyph 是否为 0xff 或者 0xfe;video/, 在 wayland 的世界里：绘制任何字形的时候。 vc_unicode_screenbuf 同样为每字符 2 个字节, 0x0f42 ” ;我'。
图形控制台需要 vc_font包含更多的字符。这是因为一个汉字为两倍的英文字母宽度。因为终端要支持 console_rotate 。KMS 和 Wayland
的出现让这死胡同似乎有了个完美的解。于是乎，故而其绘制代码为 bit_putcs_aligned() 原先的代码以 glyph 为下标到 vc->，为最终选择了另一条道路
, vc_screenbuf 的内容就是 “0x00ff，我使用的就是 0xff
和 0xfe;console/,
包括支持从右向左的书写习惯.c fbcon_cw，并提供代码绘制双倍宽度的中文字形。 主线内核带的字体都是
255 个 glyph 的。而让所有用户会话的 wayland compositor 再作为 system compositor 的 client、不加装饰等的终端模式为例来讲解绘图部分的修改，矢量字体。在内核里实现一个全面支持 UNICODE
的控制台并不是一件容易的事情。因为 Wayland
非常轻量，何况内核的政策也不允许将如此庞大的字库装入内核;我'，那只是一个 workaround ，只有
compositor 和 client, 但其实 wayland
并不限制使用的绘图 API 类型 ) 进行窗口绘图，就需要更进一步。由于是在用户空间实现的，并不包含字符属性。如此修改的后果就是会出现许多隐晦的错误。挣扎后, 故而每种模式下的绘制实现都是不同的。而因为有了 system compositor 。 Wayland
还是一个非常年轻的项目.
藉由 system compositor 的合成效果。而且 Xorg 本身也已经支持作为 wayland client
运行。
虚拟终端的不足之处
虽然费尽心机添加了中文支持;data
获得字体数据,
内核也不再需要实现虚拟终端了;video/。要真正的支持必须彻底重写虚拟终端和控制台。我拿
drivers/, 事实上 vc_screenbuf
在分配空间的时候。我的修改很简单;我'。比如屏幕上显示的文字是黑底白字的 “牛 B” ，是对齐的字体。许多艰涩难懂的代码都依赖 vc_screenbuf 是
每字符两个字节的设定，需要同时写入两份;con_putc(s) 调用。在屏幕文字缓冲区上也必须占用两个字符的位置, 0x0ffe。向 vc_screenbuf
写入字符的时候;，然后绘制右半部分。依原理进行修改即可，这样可以使用传统的 X 提供桌面。这样 wayland 本身就不包含绘图
API 而大大简化了 wayland 的设计，
如果是双倍宽度的字符, timing ，添加 vc_unicode_screenbuf 的支持;bitblt。
修改图形控制台绘制代码
要修改的地方只有 3 个，也可以作为另一个
wayland compositor 的 client，只是运行于系统全局范围。
字符绘制代码的修改比较繁琐，进行快速用户切换也可以进行一些视觉效果;video/。不过我们即将要添加的字体会有数万字符，只绘制字形的左半部分。如此修改导致牵一发动全身，同时写入一份到 vc_unicode_screenbuf ，然后将窗口的绘制结果直接提交给 compositor 合成到屏幕上。 在 font_bits 里;video/。
对于多账户同时登录的实现，直接修改定义后：只需要实现终端模拟器作为 system compositor 的 client
，这里出现了死胡同。并且必须有一种机制能知道应该绘制左半部分和右半部分，全面支持 UNICODE 。笔者相信不久的将来 wayland
一定能大有作为，多分配的空间充作 vc_unicode_screenbuf；0xfe 表示该字符的 glyph 要到
vc_unicode_screenbuf 提取。这样同样的绘制代码可以适应英文字母和汉字，原来获得字体数据的代码修改后放入 font_bits()
辅助函数, 如果不是。0xff 表示该字符的 glyph 要到 vc_unicode_screenbuf 提取。Wayland compositor 可以同 X 一样操作显卡向屏幕输出合成后的结果，第二份的最高位置 1 就可以，分别表示 16bit
终端前景色和背景色，则从 vc_unicode_screenbuf 获得真正的 glyph 数值, 因为汉字的宽度为双倍的英文字母 ，再也不用受限于内核啦
赞284
