lkml.org 
[lkml]   [2010]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Kernel fbcon UNICODE font support
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)

> 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, 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);

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-11-27 14:01    [W:0.082 / U:1.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site