> Another way - add to console driver unsigned short
> unicode2codeset[3][65535] table.
(I have 2.0.36 now and I'm not sure if this is the same with pre-2.2.0.)
It could look exactly as uni_pagedir, only mapping to a different charset,
so it wouldn't take much space. Probably four such tables, like current
inverse_translations, if I correctly guess which charset do applications
expect as input - I think it should be the one selected with ^[( and
set_translate(), mostly ISO-8859-1 or user defined.
But it's not so obvious... If an application switches temporarily to
VC-100 or CP-437 to draw some frames, keys pressed that time should
probably still be translated according to ISO-8859-1 or user defined map.
There is a difference between temporary switching and permanent switching!
Maybe we should handle ISO-8859-1 and user defined map switches in one way
(using them for keyboard translation) and VT-100 and CP-437 the other way?
Or differentiate between ^[( ^[) ^O ^N (which would also set the map for
keyboard), and ^[[10m ^[[11m ^[[12m (which only temporarily switch the
app-to-Unicode mapping and would not affect the keyboard mapping)?
This would be the inverse mapping of translations[]. The current name
inverse_translations is confusing - it is the inverse of
translations[uni_pagedir[...]], not translations[...].
U+F000..U+F1FF should probably be treated specially here and translated
according to the map set by con_set_unipair. This is not important for the
keyboard mapping, as keymaps would probably not contain U+F0xx characters,
but it may be used for gpm - see below.
> Imho selection used screen glyphs now just because there is not
> correct Unicode to codeset translating in kernel. If it will be invented
> (in 2.3 may be ?) it will be very usefull both for keyboard & for selection.
IMHO a general charset translation is not needed here. If only screen
contents were stored in Unicode, inverse_translate() could take directly
those unicodes instead of looking at font positions first. The current
inverse_translations map would be not needed - instead the above described
inverse-of-the-current-translations[] would be used (in selection.c).
This is conceptually simpler than the present design, which combines both
translations in inverse_translate. It only requires another Unicode-to-
-something map; the current inverse_translate superposition is easier in
implementation, as it's only 8bit -> 8bit, jumping above the intermediate
Unicode form.
In the UTF-8 mode the screen contents copied by gpm should be converted
into UTF-8. And it would be better to store the saved contents in Unicode
and translate them during pasting instead of during copying. That way the
same text could be properly pasted into consoles using various charsets,
UTF-8 or not!
Let's assume that screen contents were stored in Unicode. As console
switching has to somehow copy stored screen contents onto the screen
memory, it would have to do the translation then (conv_uni_to_pc). This
would give the little nice feature that after font switching all the
existing characters on screen would be correct - even those not present in
the previous font, which were previously substitutied by approximations!
For compatibility, /dev/vcs* should behave the same way as now. So reading
it would translate characters according to conv_uni_to_pc, in the same way
as for displaying them on screen. Writing into it would require a new
translation, not needed otherwise, from font positions into Unicode. It
is not known what Unicode value to use if they are many to choose from -
this time the screen contents would get mangled when using a font which
shares glyphs, and somebody saves and then restores screen contents using
/dev/vcs*. It's unavoidable. But it does not loose anything more than
currently gets lost even without any screen saving/restoring. It would
only sometimes choose a different character from identically looking ones,
which would cause copying them with gpm to give wrong characters - which
we already have unconditionally now.
Instead of doing that fontpos -> Unicode translation here, it would
probably be simpler to store just U+F0xx as the restored screen contents
and rely on their interpretation in the new inverse-of-the-current-
-translations[]. Such contents would no longer automatically get fixed
along with font changes and they would be gpm-pasted incorrectly
if a different mapping is active during pasting than during screen
save/restore. But such translation after screen save/restore can't be
perfect anyway, if using current /dev/vcs* interface.
Probably a variant of /dev/vcs* should be designed, which would let read
and write direct Unicode instead of the above compatibility translation,
thus allowing exact screen save/restore.
I'm sorry if I misunderstood something here - I'm not sure whether all the
above is correct and if it still applies to pre-2.2.0.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://kki.net.pl/qrczak/
\__/ GCS/M d- s+:-- a21 C+++>+++$ UL++>++++$ P+++ L++>++++$ E->++
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/