Description of problem:
The console driver is not properly interpreting or using the alternate character
set mode, which causes all terminfo (Ncurses) applications which draw boxes to
display improperly. This problem does not occur on previous versions of RHEL or
versions of FedoraCore prior to 6. This does occur on FedoraCore6 and bugzilla
entry (217448) was submitted 11/27/06. The problem also does not occur when
using an xterm or native VT100 terminal.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot system to init level 3 (no Xwindows)
2. Make sure $TERM is set to "linux"
3. # echo -e "\033[11m\332\304\304\304\277\033[10m"
just a block displays on the screen. actually, it is multiple blocks that are
drawn upon each other.
cant show it to you here but it should have displayed the alternate character
set character for "upper-left corner", followed by 3 horizontal lines, followed
by "upper-right corner".
The following escape sequence is output by terminfo when TERM=linux and I turn
on the alternate character set, display a upper-left corner, three vertical
lines and an upper-right corner, then turn off the alternate character set mode:
# echo -e "\033[11m\332\304\304\304\277\033[10m"
("\033"=ESCAPE character, "["=left_bracket, "\"=backslash)
In this example:
"\033[11m" turns on alternate character set
"\332\304\304\304\277" draws UR corner, three vertical lines, UL corner
"\033[10m" turns off alternate character set
The command "tput smacs" also turns on alternate character set by sending the
escape sequence provided by terminfo to the screen, and "tput rmacs" will turn
the mode off. Using "tput smacs >/tmp/out" and "od -c /tmp/out" verifies that
the correct escape sequences are being sent to the display.
The same escape sequences sent to the console on any previous version of
FedoraCore or RHEL display the box characters properly, but on RHEL5 and
FedoraCore 6, the smacs/rmacs sequence is apparently ignored and the box
characters therefore display garbage on the console.
This is completely unrelated to the console-tools package. Reassigning to kernel.
Another test case:
echo -e "\e(0qqq\e(B"
Works correctly when console is in non-utf8 mode (echo -e "\e%@") but incorrectly displayed in utf8 mode (echo -e "\e%G").
This is because do_conn_write() in drivers/char/vt.c does not send c through the translate array when utf is non-zero. I'm not sure what the precise translation semantics should be in utf8 mode, but at the very least it should send characters <= 0x7f through the translate array.
The only other possible solution would be to have a separate terminfo entry for the utf8-mode console, with a different acsc property. I haven't looked to see if ncursesw handles multi-octet utf8 sequences in the acsc string; I suspect it doesn't. Even so, this would be an unwieldy solution.
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).