Messages in this thread |  | | | Date | Wed, 30 Dec 1998 11:12:48 +0100 (CET) | | From | "Marcin 'Qrczak' Kowalczyk" <> | | Subject | Re: small addition to keyboard driver propose with patch |
| |
On Tue, 29 Dec 1998, Stanislav V. Voronyi wrote:
> 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/
|  |