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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 27 May 2010 20:53:37 +0800
From:	Frank Pan <frankpzh@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Alan Cox <alan@...ux.intel.com>,
	Gerardo Exequiel Pozzi <vmlinuz386@...oo.com.ar>,
	Kay Sievers <kay.sievers@...y.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Catalin Marinas <catalin.marinas@....com>,
	Daniel Mack <daniel@...aq.de>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>,
	Jochen Hein <jochen@...hen.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Dave Airlie <airlied@...hat.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] Enlarge the storage of chars in virtual terminal

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/