login
Search
Hi, I know there are most people speaking only English, and never meet non-ASCII characters on console. But, hey , what about others ? Then, some of you may come up with a idea than ,there is already fbterm than supports non-ASCII characters in user-space. But, what if you forgot to run fbterm ? And what about some program that must be run on native tty console ? Or I just want init script display fine Native Language? So, here is the solution: Making framebuffer console handle UNICODE font in kernel. The first thing I need to handle is that, currently there is no room for adding UNICODE font, only 8bit for characters, how can you do? Also , some characters are double-width. So the solution is make an backing store. 0xFE and 0xFF stands for character value store else where, and 0xFF means , left-half of the else where character, and 0xFE means right-half of the else where character. This is a basic solution, the best is that making vc->vc_screenbuf store full UNICODE/attribute value, But changing it may break some drivers, so , currently I won't try that way. The UNICODE font just too large to be included in e-mail, please follow http://minilab.tk/0002-add-cjk-font-that-has-65536-chars.patch to get that. This font is copyrighted by youbest@sina.com, also he is the original author of this patch. I don't have a chance to reach him. If there be any license issue, just re-generated from WenWuanYi(http://wenq.org/) open-source font. So , this should not be a big deal. In future, we don't have to compile that big font into kernel, we should use setfont to load UNICODE font. But, .psf does not support that much charcount (or maybe yes, and I need some search? ), new font format need to be discussed, or make setfont using .pcf font that come with X11 So, here is the patch that add UNICODE font handling functionary. know bugs: compile in UNICODE font , then never use setfont unless setfont updated to use PCF font. And also this patch updated to ...
Hello, Well, you can't deny that there _is_ some support for non-ASCII. But I'd much prefer the full unicode way, however. Trying to hack around with 0xFE/0xFF will just bring hard-to-fix bugs, while it's quite easy to make sure we capture not-up-to-date drivers by changing field names for instance. I'd say we should first do that, and then it'll be easy to move the old vgaposition/glyph translation cruft into the few drivers that need it. Yes, this seems to be the hard way. But that's the short-term hard then mid-term easy way, which is way easier to accept than the short-term easy then mid/long-term tedious way that you That's just a matter of fixing tools: the newer version of the psf I've just had a quick glance over it, and there are quite a few things That is the kind of hack that really shows your current approach will ?! With a proper switch to a "unicode character" type, this would rather be "* sizeof(something)", so that choosing between 16bit unicode and 32bit unicode would even be trivial. Samuel --
Then 15bit for attribute, so few. I'm working on it now. making it 64bit width, 32bit for char and 32bit for attributes. Indeed, 31bit for char, 1 bit for double/single width So, new psf file format is just fine. I'll search(wirte if not exist) Yeah, First I just want it works .. ASAP. Then , adjust it, use the painful way. I must sure that kernel guys like the idea , or , I don't want to wast my time. So the hard works begins right after ugly hack work. ---- BTW， this patch only works on tty1 , I just happen to forget font.charcont in the copy_font stuff . so font_bits() will always think current font is not UNICODE. here is the patch. From db2e58c1e304d53a8bfc97fdf58e1e14a89c0fcd Mon Sep 17 00:00:00 2001 From: microcai <microcaicai@gmail.com> Date: Sat, 27 Nov 2010 16:13:19 +0800 Subject: [PATCH] fix "CJK only works on tty1" Signed-off-by: microcai <microcaicai@gmail.com> --- drivers/video/console/fbcon.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index 04c60f4..9959a10 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -1061,6 +1061,7 @@ static void fbcon_init(struct vc_data *vc, int init) fvc->vc_font.data); vc->vc_font.width = fvc->vc_font.width; vc->vc_font.height = fvc->vc_font.height; + vc->vc_font.charcount = fvc->vc_font.charcount; p->userfont = t->userfont; if (p->userfont) @@ -1351,6 +1352,7 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var, vc->vc_font.data = (void *)(p->fontdata = t->fontdata); vc->vc_font.width = (*default_mode)->vc_font.width; vc->vc_font.height = (*default_mode)->vc_font.height; + vc->vc_font.charcount = (*default_mode)->vc_font.charcount; p->userfont = t->userfont; if (p->userfont) REFCOUNT(p->fontdata)++; -- 1.7.3.1 --
There's at least bdf2psf from the console-setup Debian package. Samuel --
I did more work,and found that , VGA console (non framebuffer) realy need 8bit/8bit attrib/char , because that's how text mode VGA cards interpreter them. changing to full type will break VGA drivers. So, I add an u32 * unichars to con_putcs() parameter list, VGA drivers just ignore that parameter , but fbcon can use it instead of unsigned short *s as real char value. And allocate an backing store buffer to store full UNICODE characters. Also , I delete vc_hi_font_mask, VGA hardware that support 512 font chars turn to use u32*unichars passed to con_putcs() Will that acceptable ? --
Well, on VGA you could use the 512 glyphs available (9 bit character, 7 bit attribute) and dynamically change the font in the video memory to always contain the characters that you need on the screen. Chances are that you won't need all 512 at any single time. The screen isn't that large in classic VGA mode. But since VGA is mostly dead these days anyway, it'd be a neat hack, but -- Vojtech Pavlik Director SuSE Labs --
That's what the Hurd console does indeed, and that's indeed enough to be able to display all Debian Installer's dialog boxes in chinese without Agreed, considering how bug prone it'd be. Samuel --
Can't do that. That's too tricky, and some times we *DO* need more than 512 different glyphs. --
BTW the console developement branch is at git://git.infradead.org/‾jsimmons/public_git/linuxconsole-2.6.git I have managed to do massive cleanup to the console layer but its not quite ready for general testing. Its mostly working but there are still some major bugs. As for the VC screen buffers the issue is that the default screen buffers where based on the VGA text mode. In fact the visible VC for vgacon is the actually vga video buffer. When we do a VT switch it copys the video buffer to a software buffer and then loads the vga video buffer with the VCs software buffer we switched to. This is nice and neat for vgacon but it doesn't flow so nicely with graphical consoles or text LCDs. What I like to see is the attribute buffer be split from the vc_screenbuf. The bonus is in embbeded systems we could arrange the code so we could have a light weight printk VT without the extra junk of the VC. Do we really need a attribute buffer for printk? I believe that would be the first step in the right direction.
That's exactly what I suggested privately to Microcai. Increasing the number of supported glyphs should then becomes way simpler, and double-width not so far. Samuel --
The challenge would be the scrolling code. I cc'ed the LCD group to voice there needs as well.
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann |