Re: [PATCH] Kernel fbcon UNICODE font support

[microcai]

2010/11/27 Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>:
> Hello,
>
> Microcai, le Fri 26 Nov 2010 13:53:45 +0800, a Ãcrit :
>> ÂI know there are most people speaking only English, and never meet
>> non-ASCII characters on console. But, hey , what about others ?
>
> Well, you can't deny that there _is_ some support for non-ASCII. But
> just at most 512 glyphs and single width, indeed.
>
>> Â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?
>
> (or 9bit, but no more indeed)
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
select.

>
>> Â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.
>
> 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
> propose.
>
>> The UNICODE font just too large to be included in e-mail, please follow
>
> There is no way we want to include a big unicode font in the kernel :)
>
>> In future, we don't have to compile Âthat big font into kernel, we
>> should use setfont to load UNICODE font.
>
> Yes.
>
>> But, .psf does not support that much charcount (or maybe yes, and ÂI
>> need some search? )
>
> That's just a matter of fixing tools: the newer version of the psf
> format already supports 2^16 glyphs.

So, new psf file format is just fine. I'll search(wirte if not exist)
some tools to generate PSF unicode font file. ^_^

>
>> So, here is the patch that add UNICODE font handling functionary.
>
> I've just had a quick glance over it, and there are quite a few things
> that bother me, including:
>
>> @@ -296,6 +295,8 @@ int set_selection(const struct tiocl_selection
>> __user *sel, struct tty_struct *t
>> Â Â Â Â Â Â Â Â Â Â Â }
>> Â Â Â Â Â Â Â Â Â Â Â obp = bp;
>> Â Â Â Â Â Â Â }
>> + Â Â Â Â Â Â if (c > 0x80)
>> + Â Â Â Â Â Â Â Â Â Â i += 2;
>> Â Â Â }
>> Â Â Â sel_buffer_lth = bp - sel_buffer;
>> Â Â Â return 0;
>
> That is the kind of hack that really shows your current approach will
> most probably just bring us bugs.
>
>> @@ -2171,6 +2205,8 @@ static int do_con_write(struct tty_struct *tty,
>> const unsigned char *buf, int co
>> Â Â Â Â Â Â Â rescan = 0;
>> Â Â Â Â Â Â Â inverse = 0;
>> Â Â Â Â Â Â Â width = 1;
>> + Â Â Â Â Â Â vc->vc_utf = 1;
>
> ?!
> There is now way we can accept to systematically switch to utf-8.
>
>> - Â Â Â Â Â Â vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_NOWAIT);
>> + Â Â Â Â Â Â vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size * 2, GFP_NOWAIT);
>

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.
(Think about TuxOnIce ? another topic ;) )

> 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.
>

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.