>On Wed, 30 Dec 1998, Stanislav V. Voronyi wrote:
>> But since the full translation never (or very rarely) needed
>In fact it will always contain no more than 256 characters.
But theoreticaly user may need more than 256 Unicode symbols.
>> But I prefer add one another TIOCLINUX ioctl for setting translation
>> table by user which will contain all Unicode symbols needed for him &
>> never switch it.
>You mean to list all the Unicodes that would be ever used? I can't see the
>purpose...
>BTW: It's very inconvenient that one can't easily check whether the
>console is in UTF-8 mode. The only method I know is to output some test
>characters and look how much did the cursor moved. It has disadvantages:
>ugly, alters the streen contents. and, most important, requires to flush
>the terminal input (to read the cursor position)! The same applies to
>checking which of the four maps is active (yes, I needed this in one
>tool). I would appreciate a better method - maybe some ioctl, as for
>reading the actual map contents. Still don't know what about xterms etc.
>- how should they tell if it's UTF-8 or that one can switch to UTF-8.
In experementations with console driver at home I add this possibility
as one aditional TIOCLINUX ioctl as well as reading of current translation.
>> The existing screen buffer contain not from screen glyphs only. It
>> also keep screen atributes. So the best way imho not using unicode
>> buffer instead of screen, but add Unicode buffer as additional to
>> existing one.
>Maybe. I'm not sure which would be easier.
>> In this case we have no troubles with existing /dev/vcs* interface,
>What to put into the Unicode buffer when someone writes into /dev/vcs*?
We have codeset to Unicode translation tables in current kernel.
So no additions not needed.
>> In case we have an unicode selection buffer we can add another
>> additional ioctl call that allow get/set to/from user space contain of
>> selection buffer. Using this ioctl cut/paste between textual console &
>> Xwindows screen will be also possible.
>Yes, I was surprised that gpm did't work this way (checked today). But
>with the current implementation gpm doesn't need to care about Unicode or
>other modes...
Yes, this is not gpm work. gpm use selection from kernel. And
paste in UTF mode possible in current kernel with very small patch. But
in current kernel you can print one UTF symbol, and paste from selection
another just because selection work from screen glyphs.
SY, Stanislav Voronyi.
-
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/