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 for Android: free password hash cracker in your pocket

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

Message-ID: <4BFE3BB8.1030503@kernel.org>
Date:	Thu, 27 May 2010 11:30:32 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Frank Pan <frankpzh@...il.com>
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

Hello,

On 05/27/2010 10:59 AM, Frank Pan wrote:
> You are right, I've missed a big count of languages.
> Nonetheless, the vt already identified several ranges in the unicode
> space, and made them 2 times wide as ASCII chars.
> My idea depends on this.

Hmmm... I see.

>> And then, if you think about multilingual terminal, output is only one
>> half of the story.  You gotta be able to input something too and in
>> many scripts, input handling needs to interact constantly with
>> rendering, which means that the kernel will also need to supply input
>> framework, at which point I start to wonder whether the whole thing is
>> just too complicated.
> 
> Agree. Input method is much complex than a data structure expanding.
> 
> I don't know about other languages, but I bet the thing goes like:
> one press one or more keys, (choose the char he/she really want to, )?
> and commit an input.
> We need not to implement the whole thing inside kernel, a user space
> app can catch keyboard inputs and push unicode chars into the tty.
> The only change should be done in kernel is reserve a space on screen
> for the potential char choosing, which is really easy to do in any
> console drivers(report a smaller height/width).

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.

>> What's the use case other than "I just want to use console"?
> 
> Many times I type startx is just for checking time of a meeting
> (in a CJK web page, etc).
> Many times I've found emails in mutt with question marks, I must
> open a X and a terminal in X, and mutt in terminal in X.

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.

> Is there anything worse?

Sure, there are plenty of worse things.  :-)

Thanks.

-- 
tejun
--
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/