Re: [PATCH 0/2] Enlarge the storage of chars in virtual terminal

[Frank Pan]

Greetings,

> I'm not an export on the issue but if I'm not mistaken it gets more
> complex than that.  It took quite some time to solve the problem
> properly even on full desktop envs.
Maybe the issue on full desktop envs comes from different frameworks?
(gtk, qt, etc...)
On tty, it's just a char device. It may have difficulties, but unknown before
totally implement it. AFAIK, it's easier than desktop envs.

> And other than yourself, how many would such users be?  What's your
> reason for not using X other than "console looks cooler"?  Even if you
> have some valid reason to not use X and absolutely have to have
> multilingual support, what prevents you from using fb based terminals
> like jfbterm which already works with input and all without
> introducing any i18n related complexities into kernel?  To me, it
> seems like low activiy on jfbterm seems to show the low demand for
> such feature.  So, just use X.
Not everyone likes X. Forcing one who think X is a huge thing using X
even when checking emails is... too bad. People may have their own
choice, I think.

A brief view of jfbterm tells me it's a good thing, and the source code
tells me that it does almost the same thing in vt: esc char handling,
terminal configuration, etc. Plus, pcf parsing and encoding identification.
That's why I think we are re-inventing the wheel. Kernel do esc char
handling, kernel do terminal configuration, kernel do utf-8 decoding,
kernel do dynamic font changing. Why don't we just enlarge the glyphs
a font can have, so all the things go well?

Thanks for reply.

-- 
Frank Pan

Computer Science and Technology
Tsinghua University
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/