Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
UTF-8 + console problems. Kernel accent tables.
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
obmun
n00b
n00b


Joined: 17 Jan 2004
Posts: 66
Location: Europe (Spain)

PostPosted: Sat Sep 11, 2004 5:19 pm    Post subject: UTF-8 + console problems. Kernel accent tables. Reply with quote

I'm a Spanish Gentoo user. I've been trying to localize properly my Gentoo system using as text codification UTF-8. X works perfectly (and so does Gnome). As far as I remember, the problem has always been the consoles.

I've looked for possible info and I've read and gone thru the things told in the gentoo localization guide as well as the various posts found in this forums about localization and UTF-8. But nothing has still worked.

In this post I'm trying to sum up all what I've done to see if someone finds the problem and can suggest a solution. Please, if you see error/s in the steps I've taken or in my reasonings tell me.

My actual problem is with compositions: keys dead_acute + "o" for example don't produce a "ó" in the console in UTF mode. In iso-latin-1 everything is fine.

With a high degree of abstraction, to make UTF-8 work in the console the following steps are basically required:
1.- LC_ALL and LC_LANG set to es_ES with UTF-8 ( es_ES.UTF-8 ).
2.- Font with Unicode mapping.
3.- After system login, call of the unicode_start script.

Just with this instructions Bash has problems deleting multibyte UTF-8 characters (for example the Spanish ntilde "ñ"). So my solution is a little more complex.

Complete solucion: UTF-8 in console.

1.- LC_ALL and LC_LANG both set to es_ES.UTF-8 (UTF-8 in uppercase not to have problems with X).

2.- Keymap "es" (with "euro2" also for € symbol) in rc.conf.
That keymap uses the symbolic kernel names for the keysims, which are already in UCS2 (we can see them doing a dumpkeys -l). Taking a look on es.map.gz show us that neither it nor its includes redefine the compose keys (kernel accent table).

3.- Choice: console font with a unicode translation map.
I tested lat9v-16 (after taking a look on usr/share/consolefonts/README.lat9). It only has 256 characters, but has the Unicode map. LatArCyrHeb-16 is another option (512 chars).

An analisys of unicode_start reveals the following actions being taken:
kbd_mode -u
THis puts the kernel keyboard driver in Unicode mode: passes UTF-8 coded Unicode characters, accepts unicode keysims defined in the keymap and when you introduces a character using the hexadecimal form (with the keypad and AltGr) it's interpreted as a 16 bits unicode value.

dumpkeys | loadkeys --unicode
Dumpkeys utility shows the current keymap in use (including the kernel compose table). With that order apparently we make loadkey to reload the current keymap but "translated" to unicode. loadkeys manpage page doesn't show any info about the

--unicode option.

"echo" comand to the consoles
echo -n -e '\033%G'
Sends a escape character and tells them to put in unicode mode. Program output is interpreted as unicode by consoles and passed to the kernel.

From this analysis continuing with the steps:
4.- Add the "-u" parameter at the beggining of the keymap variable in rc.conf.
This way the /etc/init.d/keymaps scripts dectects it and automatically executes the kbd_mode -u.

5.- "unicode" script.
Create a init.d script that executes the dumpkey | loadkey order and puts the existent consoles in unicode mode during boot.

I use a script created by other Gentoo user that I found in this forums. Here is the code:
Code:

#!/sbin/runscript
conf=/etc/env.d/02locale

# Using devfs?
if [ -e /dev/.devfsd ] || [ -e /dev/.udev -a -d /dev/vc ]; then
  device=/dev/vc/
else

  device=/dev/tty
fi

depend() {
        need localmount
        after keymaps
        before consolefont
}

checkconfig() {

  if [ -r ${conf} ]; then
          . ${conf}
          encoding=
          [ -n "${LC_ALL}" ]      && encoding=${LC_ALL#*.}   && return 0
          [ -n "${LC_MESSAGES}" ] && encoding=${LC_MESSAGES#*. } && return 0
          [ -n "${LANG}" ]        && encoding=${LANG#*.}   && return 0
  fi
  eend 1 "Locale is not configured, Please fix ${conf}"
  return 1
}

start() {
        ebegin "setting consoles to UTF-8"
        checkconfig
        if [ "${encoding}" = "UTF-8" -o "${encoding}" = "utf-8 " ]; then
                dumpkeys | loadkeys --unicode
                for ((i=1; i <= "${RC_TTY_NUMBER}"; i++)); do
                        echo -ne "\033%G" > ${device}${i}
                done
                eend 0
        else
                eend 1 "UTF-8 is not required"
        fi
}

As u can see this script does exactly what the unicode_start script does. It checks the existence of the /etc/env.d/02locale file and checks it to make sure that the selected coding is utf-8. If it's not obviously the script's actions are not required. We have to add this script to boot level with an rc-update.

After 4.- y 5.- we achieve the same effect during system boot as a unicode_start call in a console

6.- "Repair" bash.
The bash problems deleting characters like Spanish "ñ" need to be solved. An xterm bash in a graphical environment works well. It understands utf-8 characters properly. Why console bash doesn't delete multibytes properly? I think this is the explanation:

When we boot the system (suposing we don't have a graphical login like xdm) the program chain is:

kernel -> init -> getty (or agetty) -> login -> bash

Kernel calls init which in turn initializes getty for all the consoles. Getty shows in console /etc/issue contents (the famous "This is hostname.dnsdomainname ..." message) and waits till you enter your username. When you push the enter key calls login with the previous username. Login ask us our password and checks it with PAM login us if it was correct. Login sets certain env variables (the ones in /etc/passwd and other default values) and executes the login shell defined in /etc/passwd. The problem is: when "we" (login executable) call bash during this process THE LOCALES are not yet set because it's bash who reads and executes /etc/profile (and the profile.env include with the enviroment variables definitions from env.d) and ~/.bash_profile. Bash uses the readline library for command line reading. When the library is initializated checks the system locales and as they're still not defined readline doesn't load in utf-8, causing that when we delete multibyte chars in command line (like an ñ) each byte is interpreted as a different char.

To solve this problem is necesary to call bash again after being logged, changing the original bash with this new one using an "exec" call (we don't want two bash procesess to be shown by a ps command). This new bash will found the coding set to UTF-8, and the readline library will be able to read and delete multibyte chars. Solution: we need two bashrc scripts in ~/, created from the same bashrc original.

.bashrc
Code:

[... previous content cut]
                PROMPT_COMMAND='echo -ne "\033_${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\033\\"'
                ;;
esac
                                                                                 
##uncomment the following to activate bash-completion:
#[ -f /etc/profile.d/bash-completion ] && source /etc/profile.d/bash-completion

mv ~/.bashrc ~/.bashrc_1st
mv ~/.bashrc_2nd ~/.bashrc
exec bash --login


.bashrc_2nd
Code:

[... previous content cut]
                PROMPT_COMMAND='echo -ne "\033_${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\033\\"'
                ;;
esac
                                                                                 
##uncomment the following to activate bash-completion:
#[ -f /etc/profile.d/bash-completion ] && source /etc/profile.d/bash-completion

mv ~/.bashrc ~/.bashrc_2nd
mv ~/.bashrc_1st ~/.bashrc


This is needed because we still want bash to execute the ~/.bash_logout script when we enter a logout in console. I mean: the new bash must work exactly as the original one (an interactive login bash) and we want the alias in .bashrc to be available in the new one (so combinations of --noprofile or --norc with --login or --interactive won't work). And we don't want an infinite recursion. Yes, I know it's not a good form of solving it but ... it works :). Sugestions are welcomed.

Result
This doesn't work.

During system boot everything is OK. When you log and write "ñ"s you can delete it without problems (this shows that bash loaded properly with utf-8 support in the readline library). If you do an "ls" in a directory with UTF-8 file names, vocals with tilde or diaeresis are showed properly (for example, creating a file from Nautilus with the name "cigüeñà-â" and listing it from a console works). If a "less" is done in that file to show its contents OBTAINING ITs name with c+TAB (using bash name autocompletition) the name completed by bash is correctly shown in the prompt and the characters written by bash can be perfectly deleted (you don't continue deleting the prompt). I use autocompletition because I cannot write the file name as key compose doesn't work for me (I cannot write a vowel with tilde).

However if I try to write a character with a tilde (for example: á) it doesn't work. Is like if all composings (tilde + vowel or diaeresis + vowel) weren't working. Bash starts doing weird thins: changed direction writing (from right to left, like in arabic language), no gliph drawing, ...
So symbols can be perfectly displayed but not writen. Here comes the main question: Why?

Problem analysis.
A "dumpkeys --compose-only" show the current kernel accent list (compose list). After the system boot with all the steps before, the keysims resultant in the accent list are NOT VISIBLE in the console in unicode mode. They are showed in ISO-LATIN-1!. I checked this saving the dumpkey command output to a file and reading it with an hex editor. The chars weren't in utf-8.

If one user without unicode activated (no utf-8, no console unicode soport) executes a dumpkeys --compose-only sees perfectly the output chars, corroborating that they're in iso-latin-1 (better would be to say that they're in a one byte charset).

But if we think about it one second and we ask ourselves: can be this related to the problem I found trying to write tildes? I think the answer is no. One could think: if the keysims are in iso-latin-1, how is supposed the kernel to understand them when the keyb driver sends them to the kernel? Internally kernel works with UCS2 coding (another different Unicode encoding of 16 bits) and UCS2 coding of bytes is the same as the iso-latin-1 for those chars. Reading the keymaps(5) manpage, if someone want to define the keysims of a keymap in utf-8 he must use the U+xxxx syntax. Then it's logical that dumpkeys is returning the keysims not using symbolic names (remember: in the "es" keymap compose keys are not defined at all, so we are using the kernel standard ones) with that coding. But the next question will be: why not use a U+sintax instead of printing the char? And why not printing two bytes (I'm supposing it's in UCS2; but the file dump of the dumpkey output shows that only one byte per char is being used)?

This is part of a dumpkeys --compose-only output:
Quote:

compose 's' 's' to 'ß'
compose '"' 'y' to 'ÿ'
compose 's' 'z' to 'ß'
compose 'i' 'j' to 'ÿ'

The keysims are the chars following the "to" keyword. That chars as I've just said are in one byte format.

The next important question is: How does kernel work with key composing? The loadkeys manpage suggests that an special <ComposeKey> is needed to do key composition. I didn't know that.
Quote:


compose ',' 'c' to ccedilla

means that <ComposeKey><,><c> must be combined to <ccedilla>. The cur-
rent content of this table can be see using `dumpkeys --compose-only'.

But in the Spanish keyboard layout we already have an special key that includes non isolated displayable symbols (tilde, diaeresis). Is a key near the enter key. That key has the 40 keycode (obtained with showkey command). How does kernel to compose this kind of keys? In a natural way nothing is shown if I only press that key once. It's expected a second key following.

If we delete de kernel accent table (for example, adding only a compose definition in the es map; the rest will not be defined) trying to write a "´"+"o" (ó) produces a "´o" (pressing the 40 key automatically generates a "´" symbol; a second key is not needed)!!! In Unicode mode this will usually make Bash to drive himself crazy. So, although loadkeys manpage says a ComposeKey is needed I have shown that the accent table affects the ntilde or diaeresis + vowel writing using the key with the dead_acute symbol in my keyboard. Is that one the composekey?

I need info. Does somebody know HOW the kernel composes? The best part of all this is that the syntax of the compose orders in the keymaps doesn't use the "´" or "¨" symbols at all!! They replace diaeresis with a " (quotation mark) and the tilde with an ' (simple quotation mark). An example:
Code:

compose '\'' 'E' to Eacute
compose '\'' 'e' to eacute
compose '^' 'E' to Ecircumflex
compose '^' 'e' to ecircumfle
compose '"' 'E' to Ediaeresis
compose '"' 'e' to ediaeresis


Could somebody explain me how all this works?

Last comment.
If you've endured reading the full post, congratulations. :) I recognize it's long. If you have the answer for some of what I've asked here, PLEASE tell me. I've spent the last two days trying to make the console to get on well with UTF-8. And please DON'T TELL me to use X term and to forget about console terms, because when I won't. :wink:

Thank you for your time.

(edit: minor change in subject)
Back to top
View user's profile Send private message
Leo Lausren
Apprentice
Apprentice


Joined: 24 Feb 2004
Posts: 198
Location: Denmark

PostPosted: Sat Sep 11, 2004 8:36 pm    Post subject: Reply with quote

This is an impressive account. I cannot answer your questions; but perhaps it would help to configure the default charset in the kernel.
Code:
File systems
Native Language Support
Default NLS Option

Here i choose utf8 and configure NLS UTF8 = y
_________________
Blog: common sense – nonsense
Back to top
View user's profile Send private message
obmun
n00b
n00b


Joined: 17 Jan 2004
Posts: 66
Location: Europe (Spain)

PostPosted: Mon Sep 13, 2004 9:43 am    Post subject: Reply with quote

Hello, Leo. Thank you for your suggestion. I've already that option set to UTF-8 in the kernel. As it only changes the coding the kernel uses to interpret the file names in filesystems, I think it won't solve my problem with compose chars.
Back to top
View user's profile Send private message
talon
n00b
n00b


Joined: 11 Jun 2003
Posts: 13

PostPosted: Tue Sep 14, 2004 7:32 am    Post subject: Reply with quote

Here is a Snippet from /usr/share/consolefonts/README.lat9

Code:

      |  Iso encoding | Unicode map |     Single    |      Cross
      |  within font  |  included   | compatibility | compatibility
-------------------------------------------------------------------
lat9  |      y        |      n      |       n       |   lat1 + lat9
-------------------------------------------------------------------
lat9u |      n        |      y      |       n       |   lat1 + lat9
-------------------------------------------------------------------
lat9v |      y        |      y      |   unicode     |       n 
-------------------------------------------------------------------
lat9w |      y        |      y      |       n       |   lat1 + lat9
      |               |             |               |    + unicode
-------------------------------------------------------------------


Maybe you should use the lat9w font.
My rc.conf reads:

Code:


# Use KEYMAP to specify the default console keymap.  There is a complete tree
# of keymaps in /usr/share/keymaps to choose from.  This setting is used by the
# /etc/init.d/keymaps script.

KEYMAP="de-latin1-nodeadkeys"

# Should we first load the 'windowkeys' console keymap?  Most x86 users will
# say "yes" here.  Note that non-x86 users should leave it as "no".

SET_WINDOWKEYS="yes"

# The maps to load for extended keyboards.  Most users will leave this as is.


#EXTENDED_KEYMAPS="backspace keypad"

# CONSOLEFONT specifies the default font that you'd like Linux to use on the
# console.  You can find a good selection of fonts in /usr/share/consolefonts;
# you shouldn't specify the trailing ".psf.gz", just the font name below.
# To use the default console font, comment out the CONSOLEFONT setting below.
# This setting is used by the /etc/init.d/consolefont script (NOTE: if you do
# not want to use it, run "rc-update del consolefont" as root).

CONSOLEFONT="lat9w-16"


and my grub.conf:

Code:

CONSOLEFONT="lat9w-16"


Hope it will solve the problem.
Back to top
View user's profile Send private message
Leo Lausren
Apprentice
Apprentice


Joined: 24 Feb 2004
Posts: 198
Location: Denmark

PostPosted: Wed Sep 15, 2004 6:22 am    Post subject: Reply with quote

Now I see the problem. I am danish so I rarely use composed characters. As a curious litle detail I can tell you, that it works in vim, but you need to type ~n<cr><cr><cr> to get 1 ñ.
_________________
Blog: common sense – nonsense
Back to top
View user's profile Send private message
lanius
Retired Dev
Retired Dev


Joined: 08 Dec 2002
Posts: 160

PostPosted: Tue Sep 21, 2004 5:42 pm    Post subject: Reply with quote

maybe this is related: http://mail.nl.linux.org/linux-utf8/2002-10/msg00057.html
Back to top
View user's profile Send private message
obmun
n00b
n00b


Joined: 17 Jan 2004
Posts: 66
Location: Europe (Spain)

PostPosted: Tue Sep 21, 2004 8:12 pm    Post subject: Reply with quote

Thanks lanius for your link. Mmm... interesting. I had already found another related topic in the kernel list. See this one. Theorically it's a patch at least solving the kernel part. It was posted on May 2004 ... This week I will have some free time so probably I'll take a look on the kdb package documentation to see if the todo entry is still there and in the kernel to see if the patch was finally included.
Back to top
View user's profile Send private message
obmun
n00b
n00b


Joined: 17 Jan 2004
Posts: 66
Location: Europe (Spain)

PostPosted: Tue Sep 21, 2004 11:12 pm    Post subject: Reply with quote

Ok. Status update: IT'S A KERNEL PROBLEM. Currently (2.6.9-rc2) still NOT FIXED.

What a pity. Since the beggining I was right :cry:. Kernel accent tables are in ASCII, not in UTF-8. A look in the last stable release (2.6.8.1) shows this:

drivers/char/keyboard.c:
Code:

...
unsigned char handle_diacr(struct vc_data *vc, unsigned char ch)
...

This function is the one looking in the accent table and returning the keysim for the composition. As you see it is returning a single byte char.

Vojtech Pavlik from Suse is one of the programmers working in this driver (he has done the last changes). In May he proposed a patch solving this. One month later (June) added a comment still asking how to solve muti diacritics composition (needed for example in Vietnamese). Taking a look in the bitkeeper linux 2.6 tree, the last version of keyboard.c continues to use ASCII key composing.

A patch for loadkeys is also needed.

TO SUM UP: We'll have to wait.
Back to top
View user's profile Send private message
obmun
n00b
n00b


Joined: 17 Jan 2004
Posts: 66
Location: Europe (Spain)

PostPosted: Sat Dec 18, 2004 11:20 am    Post subject: Reply with quote

I have solved the problem with a kernel patch posted to the kernel mailing list one week ago. It's not a final solution for the compose keys table problems and so it's not gonna be included in any kernel release soon. It's not final because "is not a full solution that covers all the cases..." (quoting the kernel list post). I cannot be more specific :)

You can find the patch here: http://chris.heathens.co.nz/linux/utf8.html
Last time I checked it was a diff against 2.6.4. I have to inserted it manually in a 2.6.10-rc3. So if you can wait I will post here the diff against the 2.6.10-rc3 tree.
Back to top
View user's profile Send private message
MaxDamage
l33t
l33t


Joined: 03 Jan 2004
Posts: 650
Location: Oviedo, Spain

PostPosted: Tue Feb 08, 2005 9:22 pm    Post subject: Reply with quote

Did you do any advance? I'm also trying to make UTF8 work 100% on my PC.
_________________
La PDA de tungsteno
Back to top
View user's profile Send private message
noup
l33t
l33t


Joined: 21 Mar 2003
Posts: 917

PostPosted: Sat Apr 16, 2005 12:16 am    Post subject: Reply with quote

As a portuguese, i'm also having problems with accented characters under the console. All of th keyboard's chars and symbols are working, except for á,à,é,ó,etc.. for example.
I'm using gentoo-sources-2.6.11-r6, so it looks like this hasn't been fixed yet.
Anyone has news on this?
_________________
noup.
Back to top
View user's profile Send private message
Kanniball
Apprentice
Apprentice


Joined: 23 Jan 2004
Posts: 208
Location: Portugal

PostPosted: Sun May 08, 2005 4:13 pm    Post subject: Reply with quote

some tips:

USE="unicode"
in LC stuff use UTF-8 instead of utf-8
make sure your glibc and X have UTF-8 build
make sure your font supports unicode
and use unicode ready apps... GTK1 don't have it...
Back to top
View user's profile Send private message
Flammie
Developer
Developer


Joined: 02 Jun 2003
Posts: 633
Location: Dublin, Ireland

PostPosted: Sun May 08, 2005 9:17 pm    Post subject: Reply with quote

Kanniball wrote:
and use unicode ready apps... GTK1 don't have it...


Yes it does. It just needs a bit of tweaking in the settings, like forcing utf-8 fontspec everywhere, which will generally suck anyways.
Back to top
View user's profile Send private message
gakrivas
n00b
n00b


Joined: 17 May 2005
Posts: 3

PostPosted: Fri Jun 03, 2005 5:09 pm    Post subject: deadkeys (Greek) working on current gentoo-sources Reply with quote

Hi

I would like to report that deadkeys for the Greek language are working on my gentoo system, which uses the current gentoo-sources. They used to work in KDE too, but I have managed to break it and I can't fix it :cry:

Anyway this must mean that there is no problem with the current kernel.
Back to top
View user's profile Send private message
rofro
Apprentice
Apprentice


Joined: 21 Jun 2004
Posts: 234
Location: Piaseczno, Poland

PostPosted: Wed Sep 28, 2005 5:09 pm    Post subject: Reply with quote

Try this http://forums.gentoo.org/viewtopic-p-2754993.html#2754993
_________________
Linux #358594
gentoo bug comment 175808#c26
You either must have patience or contribute to open source. There is only one guaranteed way to have open source do what you want it to do, and that's write it yourself.
Back to top
View user's profile Send private message
devil_ua
Tux's lil' helper
Tux's lil' helper


Joined: 23 Jun 2004
Posts: 128
Location: Kiev, Ukraine

PostPosted: Thu Nov 17, 2005 8:37 pm    Post subject: Reply with quote

Flammie wrote:
Kanniball wrote:
and use unicode ready apps... GTK1 don't have it...


Yes it does. It just needs a bit of tweaking in the settings, like forcing utf-8 fontspec everywhere, which will generally suck anyways.

It's broken freetype and freetype integration in Xorg-x11 after 6.8.0 :(
_________________
Web developer & High-load application deployer
Web Site: http://simonov.me
E-Mail: alex@simonov.me
Back to top
View user's profile Send private message
obmun
n00b
n00b


Joined: 17 Jan 2004
Posts: 66
Location: Europe (Spain)

PostPosted: Sun May 21, 2006 7:11 pm    Post subject: Reply with quote

Good news for all of us who need "composed keys" found in ISO-Latin-1 UTF-8 space (first byte of UCS encoding) [e.g á, é, í, ó, û, ...]

More than one year has passed since I discovered the console problem lied in the kernel. Now linux 2.6.17-rcX includes a patch that does a translation of the kernel accent table (still an unsigned char) to utf-8 before sending the key (as can be test doing a dumpkeys --compose-only).

So no more kernel patching is needed.

Jan Engelhardt and Alexander Patrakov are still working on a real solution (non ISO-Latin-1 composed keys like those in Latin-2 don't work with current workaround). Last talk on this front dates 10 of may (see it here)

So start emerging vanilla-sources and see if your console compositing works (it should!).
Back to top
View user's profile Send private message
ecatmur
Advocate
Advocate


Joined: 20 Oct 2003
Posts: 3595
Location: Edinburgh

PostPosted: Sun May 21, 2006 9:00 pm    Post subject: Reply with quote

Hey, good work! I recently completed transitioning to UTF-8 and it really is annoying that compose keys don't work properly. I'm using a very basic version of that patch, so the first-byte compose sequences work for me now, but it really is appalling that the Linux console is so behind everything else. You'd have thought with Linus being a Finland-Swede there'd be a reasonable effort to get Unicode working...
_________________
No more cruft
dep: Revdeps that work
Using command-line ACCEPT_KEYWORDS?
Back to top
View user's profile Send private message
obmun
n00b
n00b


Joined: 17 Jan 2004
Posts: 66
Location: Europe (Spain)

PostPosted: Sun May 21, 2006 10:47 pm    Post subject: Reply with quote

Ecatmur, I think it's not so strange console has supported "partial" UTF composing with external patches till now; and I can perfectly understand it. How many of us still start their systems with console login? I don't directly know many distributions (I only used Suse many years ago, Fedora a few hours every year and my beloved Gentoo) but most of them [if I'm not mistaken] use xdm. Few of us are still working on pure console, and I bet that those of us using console are the same who don't touch the mouse and love Emacs or Vim, use almost exclusively English and therefore sporadically need to write non ASCII characters. So it's not a priority [I can tell you that despite my huge post, just a few times during this whole period needed non 1 byte UTF-8 character composition]. At least for more than one year patches existed that allowed us to overcome this small limitation of such a wonderfull beast that is linux kernel.
Back to top
View user's profile Send private message
ashtophet
Guru
Guru


Joined: 08 Aug 2004
Posts: 396
Location: Galiza

PostPosted: Sat May 27, 2006 8:48 pm    Post subject: Reply with quote

obmun wrote:
Good news for all of us who need "composed keys" found in ISO-Latin-1 UTF-8 space (first byte of UCS encoding) [e.g , , , , , ...]

More than one year has passed since I discovered the console problem lied in the kernel. Now linux 2.6.17-rcX includes a patch that does a translation of the kernel accent table (still an unsigned char) to utf-8 before sending the key (as can be test doing a dumpkeys --compose-only).

So no more kernel patching is needed.

Jan Engelhardt and Alexander Patrakov are still working on a real solution (non ISO-Latin-1 composed keys like those in Latin-2 don't work with current workaround). Last talk on this front dates 10 of may (see it here)

So start emerging vanilla-sources and see if your console compositing works (it should!).


Oh, smooth... Here (galician-portuguese language) it works flawlessly...

What a great feeling being in vc1 doing LaTeX stuff with emacs...
_________________
O coração, se pudesse pensar, pararia. Fernando Pessoa
If heart could think, it would stop
Back to top
View user's profile Send private message
ashtophet
Guru
Guru


Joined: 08 Aug 2004
Posts: 396
Location: Galiza

PostPosted: Sun May 28, 2006 3:44 pm    Post subject: Reply with quote

Currently it only works here on vc1... That's my system's bad configuration or a common behaviour?

thanks
_________________
O coração, se pudesse pensar, pararia. Fernando Pessoa
If heart could think, it would stop
Back to top
View user's profile Send private message
dariohy
n00b
n00b


Joined: 04 Jun 2006
Posts: 29

PostPosted: Mon Jun 05, 2006 12:07 am    Post subject: Re: UTF-8 + console problems. Kernel accent tables. Reply with quote

Geez, I thought it wasn't as complicated as a kernel problem... now that I get a hand over the sources I understand that a whole type-migration issue is present.

So... I've first got concerned by this beacause of an Oppen Office uncapability to write composed characters whithout having to set the whole ALL_LANG var to my current language (Spanish, for all of those who are wondering)... After this, I guess there's no choice but to keep using the same ol' song... em, office suite....

Do I really need to let it go? or is anybody there knowing the accurate solutions to the "little problem"...

So Leo, what is it that you want to type in the composed character using a console anyway?... besides de 100% migration... I'm just curious...
Back to top
View user's profile Send private message
dariohy
n00b
n00b


Joined: 04 Jun 2006
Posts: 29

PostPosted: Sat Jun 17, 2006 3:31 pm    Post subject: Reply with quote

About the Oppen-Office lang problem... Well Yes, there is a way which I managed to get composed characters to work, that is... compiling the whole suite! I've forgot that the bin/precompiled packages weren't compiled using full language support... so yes, using the appropiate locales will do...
Looking forward to the console compatibility, I've read somewhere within this forum that there is a project that is actually working on it... guess it's also mentioned here arround... thought, it's not being finished 'till next year I believe...
Back to top
View user's profile Send private message
urcindalo
Guru
Guru


Joined: 08 Feb 2005
Posts: 553
Location: Almeria, Spain

PostPosted: Sat Jun 17, 2006 7:55 pm    Post subject: Reply with quote

dariohy wrote:
About the Oppen-Office lang problem... Well Yes, there is a way which I managed to get composed characters to work, that is... compiling the whole suite! I've forgot that the bin/precompiled packages weren't compiled using full language support... so yes, using the appropiate locales will do...


Well, I use AMD64, and as you know OO can't be compiled using 64 bits, yet, so I'm forced to use the 32-bits precompiled binaries. The same is also true for StarOffice, for obvious reasons.

However I get full Spanish support (accented characters and other ones) in both OO and StarOffice since I converted my system to UTF-8 some months ago. Before doing that I couldn't type stuff like á, ñ and the like.
Back to top
View user's profile Send private message
ashtophet
Guru
Guru


Joined: 08 Aug 2004
Posts: 396
Location: Galiza

PostPosted: Sun Jun 18, 2006 12:12 pm    Post subject: Reply with quote

ashtophet wrote:
Currently it only works here on vc1... That's my system's bad configuration or a common behaviour?

thanks


Code:
unicode_start

_________________
O coração, se pudesse pensar, pararia. Fernando Pessoa
If heart could think, it would stop
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum