UTF-8 still N/U on FreeBSD 9.0-RELEASE console

Folks, I'm a friend of console. I do not talk about blinky GUI here. My work has to be done on console and terminals and yes, I have to use a keyboard.

For some reason frequency increases on getting ugly characters on my screen, when working with others. These ugly eyecatchers has clearly been identified as Unicode characters. As frequency reached the nasty level I changed locale to UTF-8. For some good reason I expected that this would work out, as we have year 2012 and Unicode was invented before 1990.

FreeBSD Handbook is surprisingly silent about UTF-8. The most enlightning result of searching the internet is this from http://lists.freebsd.org/pipermail/freebsd-current/2010-November/021084.html

This is a known issue, since there is no translation from Unicode code points to UTF-8 sequences. In other words, if you press ë, the keyboard layer will properly send a 235 to Syscons, but instead of encoding it as 0xC3 0xA9, will just emit a single byte, having value 0xE9.

Maybe a patch like this could already get that working, but it's just a quick hack.

http://80386.nl/pub/syscons-utf8.txt

This link gives an elaborate 404. Still wondering that "no translation from Unicode code points to UTF-8 sequences" made it to the devels which are known to be the last friends of console hacking.

Any light behind horizon as two more years passed?
 
freemason said:
Oh, you know, BSDs don't like Unicode...

FreeBSD doesn't handle Unicode characters on local virtual consoles. You can connect with an UTF-8 remote shell (PuTTY and Co.) or install X server and run xterm as shown here. There also are other solutions like sysutils/jfbterm, or your own program/driver for custom/embedded hardware devices, but in general, the first two solutions cover all cases.
 
UTF8 works fine on my console for the most part. I suspect there is a bit that you've missed. Make sure you have these in your kernel configuration, I'm guessing you are missing the TEKEN line.

Code:
options VESA
device sc
options SC_PIXEL_MODE
options TEKEN_UTF8

And also in /etc/login.conf I have the following tagged on the end of the default section:

Code:
:charset=UTF-8:\
:lang=en_GB.UTF-8:

And make sure you have xterm rather than cons25 in /etc/ttys.
 
freethread said:
There also are other solutions like sysutils/jfbterm, ...

Hi freethread,

sysutils/jfbterm is a nice hint cause it can enhance console resolution to 1024x768x16, which is better than vidcontrol offers. But closing jfbterm scrumbles graphics completly when back to standard resolution.
 
Erratus said:
Hi freethread,

sysutils/jfbterm is a nice hint cause it can enhance console resolution to 1024x768x16, which is better than vidcontrol offers.

I use PC hardware, vidcontrol offers higher resolution than 1024x768 with VESA driver, also on my actual Intel GMA device. SC_PIXEL_MODE kernel option and VESA driver are required, anyway.

Erratus said:
But closing jfbterm scrumbles graphics completly when back to standard resolution.

I used jfbterm for a short period few years ago when I was not used to Unix and FreeBSD but I don't remember that, perhaps it depend on graphics card brand/model. Throw an eye [Take a look] at jfbterm man page and the porter's home page.

However, I'm not an experienced FreeBSD user, I found my way on using console: in a GUI, remotely or locally. I rarely forced to use local virtual consoles when the system fail to start, but in that case Unicode is the least of my worries.
 
Now with new kernel:

Code:
options         VESA
options         SC_PIXEL_MODE
options         TEKEN_UTF8

still no UTF characters can be punched from keyboard.
There are some people on the internet who say that they got UTF-8 working on FreeBSD, but they are likely not using console.

I'm just wondering, why this cannot be resolved for console?
 
remember, in OpenSource world no one owe or guarantee you anything.
often developers do all this on spare time and just for fun, and may have already abandoned it (grown up, got a life, forgot, arrested, dead, or anything). if you want to continue their work - you're welcome, as long as you find and modify sources.
 
If you want to pursue Unicode in the console, one of the mailing lists, like freebsd-current, is a place with more developers. It could even be that something has been done but the wiki page has just not been updated.
 
Back
Top