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 14:00:23 +0800
From:	Frank Pan <frankpzh@...il.com>
To:	Alan Cox <alan@...ux.intel.com>
Cc:	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>, Tejun Heo <tj@...nel.org>,
	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

Thanks for reply.

> This has been suggested a couple of times but unfortunately it's not
> enough to use bigger fonts. Rendering many non western languages is far
> far more complex. In addition the text mode vt driver is limited to 512
> symbols by the hardware.
Why is it complex? IMHO Rendering non-western languages is nothing more than
rendering 2 ASCII chars. The current mainline kernel already rendered these
chars with right width(but with 0xfffd glyph), and also has unicode mapping
support. Without fixing other drivers, the work on fbcon is merely breaking
the 512 limit.

The hardware limitation can be done in vgacon/mgacon/... drivers. They set
the fonts, they have right to refuse fonts with more than 512 chars.
Breaking lower level limitations won't impact them.

> Doing it right means putting the entirity of Pango into the kernel. I'd
> rather not do that when the job can be done better via a user space
> application and pty/tty pair.
IMHO A user space application doing such thing is just re-implementation of
virtual terminal support, without the 512 limitation. Why does we keeping
re-inventing the wheel?

I've already done the rendering, with this patch, removing several font size
limitations, and a user space font loader using PIO_FONTX ioctl.
It's much easier than pango, because the font is fixed on width and height.

Just an enlargement on a data structure can provide such a good feature
(important to console lovers like me), why not?

-- 
Frank Pan

Computer Science and Technology
Tsinghua University

Download attachment "Screenshot.png" of type "image/png" (49787 bytes)