Committed to Jaunty (target Ubuntu-2.6.28-12.43) ** Description changed:
+ SRU justification: + + Impact: The use of 512 character fonts on a vga console is broken since + seemingly ever until now somebody noticed. While not being a panic spreading + issue it can simply be fixed. + + Fix: Let the get_font function return the complete character set and not + only the first 256 characters, while pretending to have done all. Fix + sent to upstream (accepted into -mm) + + Testcase: Call showconsolefont after loading a 512 character font and do not + panic (seems to be another bug in there), switch console and back and the + second half of the font is corrupted. + + --- + This issue has been reported several times before in various forms. Typically about one national character missing. I try to summarize all information I have collected in this new general report and mark the earlier reports about special cases as duplicates. Several non-ASCII characters get corrupted in the framebuffer console. (see attached photos) This happens when returning from X back to the console using Ctrl-Alt-F1 ... Ctrl-Alt-F6. The characters are are displayed correctly when booting into single user mode and not starting X. (see attached intrepid-single-user-OK.jpg) So the problem is not incomplete font implementation or some locale issue. This is why I report the bug to the kernel instead of to console-setup, if feels that console-setup should not cause random pixel "characters" (But of course the bug could really be somewhere else. I'm far from understanding completely how this all works.) I also attach my /etc/defaults/console-setup Actually the problem is described in /usr/share/doc/console-setup/FAQ.gz However, it says that this happens only in text mode, not in framebuffer mode. So how can I find out in which mode my console is actually running? I believe that my console should be in framebuffer mode, because: $ lsmod | grep fb fbcon 47648 0 tileblit 10880 1 fbcon font 16512 1 fbcon bitblit 13824 1 fbcon However there is a file /etc/modprobe.d/blacklist-framebuffer and it says # Framebuffer drivers are generally buggy and poorly-supported, and cause # suspend failures, kernel panics and general mayhem. For this reason we # never load them automatically. So do we use fbcon, but not the underlaying framebuffer??? Some documentation is here http://www.mjmwired.net/kernel/Documentation/fb/fbcon.txt, but I'm still confused. The problem is not specifc to the reported kernel version. I see it also with the current Hardy kernel and the Jaunty Beta LiveCD (see jaunty-liveCD.jpg). The problem is not specific to the reported grahics card. I see it also on Nvidia, on Radeon, and also on the virtualized card created by VMware. The previously reported bugs (now linked as duplicates) cover also various hardware and software configurations. I have tested the range Unicode U+00A0 ... U+00FF, my console coding is UTF-8. http://www.utf8-chartable.de/ can be used for referece. (From the previousily reported national character issues I conclude that also characters outside this range are affected) You can easily test yourself using the attached file $ cat sampletable.txt The character corruption comes in 2 different forms: - Random pixel character range: All characters between and including U+00E9 and U+00FF are corrupted. Often the pixels are completely random (See attached intrepid-random-pixel-range.jpg) and they are different on each console tty1, tty2, ... Sometimes they are just all white or black. The somehow weird thing is that the U+00E8 (e grave) is always the last character displayed correctly, whereas U+00E9 (e acute) is always the first corrupted character. - missing accents. There is no random corruption in this case, but accents are missing from capital letters. It looks more like an intentional low-grade variant of the font. Accents are present on lowercase letters. A couple of very rare characters (e.g. thorn) are displayed as white blocks. (see attached intrepid-no-accents.jpg) I guess this variant of the problem may lead to the belief that a certain configuration is not affected, if you just test a couple of lowercase characters. The same kernel on the same machine can sometimes show "random pixel character range" and sometimes "missing accents". E.g. when boot first into single user mode and start your X later in contrast of starting everything the standard way. (intrepid-random-pixel-range.jpg and intrepid-no-accents.jpg are from the same machine using the same kernel) P.S. Not sure how important this problem really is. I started to dig when investigating some serious display corruption (affecting also X on framebuffer 7) So originally I thought if even the console gets corrupted things are really bad. But in the meantime I have come to the conclusion that this character corruption is most likely a completely different issue from my original problem. For me personally non-ASCII characters on the console are of minor importance. On the other side according to Ubunutu philosophy software should be available in the user's local language. This of course requires that national characters work, if somebody works on the console. ProblemType: Bug Architecture: i386 DistroRelease: Ubuntu 8.10 Package: linux-image-2.6.27-14-generic 2.6.27-14.30 ProcCmdLine: root=UUID=f6bf9b65-0cad-45bd-b3a0-a7353a3900af ro quiet splash ProcEnviron: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LANG=fi_FI.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.27-14.30-generic SourcePackage: linux -- Non-ASCII characters get corrupted in framebuffer console https://bugs.launchpad.net/bugs/355057 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
