linux-kernel - Re: [PATCH] UTF-8 input: composing non-latin1 characters, and copy-paste

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:	Mon, 07 Aug 2006 13:18:38 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Alexander E. Patrakov" <patrakov@....usu.ru>
Cc:	LKML <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH] UTF-8 input: composing non-latin1 characters, and
	copy-paste

Ar Llu, 2006-08-07 am 16:55 +0600, ysgrifennodd Alexander E. Patrakov:
> * CAPS LOCK does not work (silently ignored) for non-ASCII.

Capslock is indeed hard.

> argument. This means that only characters present in Latin-1 (i.e., with 
> codes <256) can be produced by composing while the keyboard is in 
> Unicode mode. This is certainly unacceptable for Eastern Europe (i.e., 
> former ISO-8859-2 users) who need to get ^+ Z = Ž.

Its not useful for most of Western europe either nowdays.

> While the proper way to get the later two issues resolved is definitely 
> to extend struct kbdiacr to produce a Unicode value, not a byte, as the 

This IMHO is the right thing to do

> result, this would require making incompatible changes to kbd. Instead, 

Absolutely.

> Copy-and-paste is handled by guessing which Unicode character most 
> likely corresponds to the glyph on the screen. Guesswork is needed 
> because many characters can map to the same glyph.

Is there a reason for not biting the bullet here and storing the
unmapped symbol then mapping it to the glyph when rendering. The days
where we had to worry about 8K more memory for the scrollback buffer are
dead and gone.

Basically I'd rather see us:
- Expand the kbd code to support the full set of behaviour (within
reason). It looks like the old behaviour can be expressed by keeping the
old format and allowing a new format (or mapping the old to the new when
the ioctl loads it)
- Expand the kbd code to allow caps/shift mapping by loaded table
- Store the true symbol not the glyph so we can cut/paste right
- Do the render mapping of symbols when needed when we actually render

That also means we get the right results if you move a live console from
text mode to graphical mode, or load different fonts and refresh.

Alan

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