kernel/git/stable/linux-stable.git/drivers/char/vt.c, branch linux-2.6.22.y

console UTF-8 fixes (fix)

2007-06-24T15:59:10+00:00

Recently my console UTF-8 patch went mainline. Here is an additional patch that fixes two nasty issues and improves a third one, namely: 1. My patch changed the behavior if a glyph is not found in the Unicode mapping table. Previously for Unicode values less than 256 or 512 the kernel tried to display the glyph from that position of the glyph table, which could lead to a different accented letter being displayed. I removed this fallback possibility and changed it to display the replacement symbol. As Behdad pointed out, some fonts (e.g. sun12x22 from the kbd package) lack Unicode mapping information, hence all you get is lots of question marks. Though theoretically it's actually a user-space bug (the font should be fixed), Behdad and I both believe that it'd be good to work around in the kernel by re-introducing the fallback solution for ASCII characters only. This sounds a quite reasonable decision, since all fonts ship the ASCII characters in the first 128 positions. This way users won't be surprised by lots of question marks just because s/he issued a not-so-perfectly parameterized setfont command. As this fallback is only re-introduced for code points below 128, you still won't see an accented letter replaced by another, but at least you'll always get the English letters right. 2. My patch introduced "question mark with inverted color attributes" as a last resort fallback glyph. Though it perfectly works on VGA console, on framebuffer you may end up with question marks that are highlighed but shouldn't be, and normal characters that are accidentally highlighed. This is caused by missing FLUSHes when changing the color attribute. 3. I've updated the table of double-width character based on Markus's updated version. Only ten new code poings (one interval) is added. Signed-off-by: Egmont Koblinger Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

use mutex instead of semaphore in virtual console driver

2007-05-08T18:15:33+00:00

The virtual console driver uses a semaphore as mutex. Use the mutex API instead of the (binary) semaphore. Signed-off-by: Matthias Kaehlcke Cc: "Antonino A. Daplas" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

vt: expose system-wide UTF-8 default setting via sysfs

2007-05-08T18:15:28+00:00

Create a variable, default_utf8, that defines the system-wide default UTF-8 setting. This variable can be altered via sysfs. If the variable is properly set, this should mimimize breakage of UTF-8 encoded consoles when doing a reset or echo -e '\033c' and of newly opened/allocated consoles. This is based from patches by Jan Engelhardt and Paul LeoNerd Evans. Signed-off-by: Antonino Daplas Cc: Jan Engelhardt Cc: Paul LeoNerd Evans Cc: "H. Peter Anvin" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

vt: add color support to the "underline" and "italic" attributes

2007-05-08T18:15:27+00:00

Add color support to the "underline" and "italic" attributes as in OpenBSD/NetBSD-style (vt220) and xterm. Signed-off-by: Jan Engelhardt Acked-by: "Antonino A. Daplas" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

vt: allow for the palette to be exposed and changed via sysfs

2007-05-08T18:15:27+00:00

Allow for the palette to be exposed and changed via sysfs. A call to /usr/bin/reset will slurp the new definitions in for the current console. Already posted at http://lkml.org/lkml/2006/1/15/149 Signed-off-by: Jan Engelhardt Cc: "Antonino A. Daplas" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

console UTF-8 fixes

2007-05-08T18:15:12+00:00

The UTF-8 part of the vt driver suffers from the following issues which are addressed in my patch: 1) If there's no glyph found for a particular valid UTF-8 character, we try to display U+FFFD. However if this one is not found either, here's what the current kernel does: - First, if the Unicode value is less than the number of glyphs, use the glyph directly from that position of the glyph table. While it may be a good idea in the 8-bit world, it has absolutely no sense with Unicode in mind. For example, if a Latin-2 font is loaded and an application prints U+00FB ("u with circumflex", not present in Latin-2) then as a fallback solution the glyph from the 0xFB position of the Latin-2 fontset (which is an "u with double accent" - a different character) is displayed. - Second, if this fallback fails too, a simple ASCII question mark is printed, which is visually undistinguishable from a real question mark. I changed the code to skip the first step (except if in non-UTF-8 mode), and changed the second step to print the question mark with inverse color attributes, so it is visually clear that it's not a real question mark, and resembles more to the common glyph of U+FFFD. 2) The UTF-8 decoder is buggy in many ways: - Lone continuation bytes (section 3.1 of Markus Kuhn's UTF-8 stress test) are not caught, they are displayed as some "random" (taken directly form the font table, see above) glyphs instead the replacement character. - Incomplete sequences (sections 3.2 and 3.3 of the stress test) emit no replacement character, but rather cause the subsequent valid character to be displayed more times(!). - The decoder is not safe: overlong sequences are not caught currently, they are displayed as if these were valid representations. This may even have security impacts. - The decoder does not handle D800..DFFF and FFFE..FFFF specially, it just emits these code points and lets it be looked up in the glyph table. Since these are invalid code points, I replace them by U+FFFD and hence give no chance for them to be looked up in the glyph table. (Assuming no font ships glyphs for these code points, this change is not visible to the users since the glyph shown will be the same.) With my fixes to the decoder it now behaves exactly as Markus Kuhn's stress test recommends. 3) It has no concept of double-width (CJK) characters. It's way beyond the scope of my patch to try to display them, but at least I think it's important for the cursor to jump two positions when printing such characters, since this is what applications (such as text editors) expect. Currently the cursor only jumps one position, and hence applications suffer from displaying and refreshing problems, and editing some English letters that are preceded by some CJK characters in the same line is a nightmare. With my patch an additional space is inserted after the CJK character has been printed (which usually means a replacement symbol of course). (If U+FFFD isn't availble and hence an inverse question mark is displayed in the first cell, I keep the inverted state for the space in the 2nd column so it's quite easy to see that they are tied together.) 4) There is a small built-in table of zero-width spaces that are not to be printed but silently skipped. U+200A is included there, but it's not a zero-width character, so I remove it from there. Signed-off-by: Egmont Koblinger Cc: Jan Engelhardt Cc: Alan Cox Cc: "H. Peter Anvin" Cc: "Antonino A. Daplas" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Initialise SAK member for each virtual console to prevent oops

2007-03-17T02:25:06+00:00

Initialise the SAK member of the vc_cons variable on all virtual terminals, not only the first one. This prevents an oops when trying Sysrq-C on e.g. the second virtual terminal: kernel BUG at kernel/workqueue.c:212! invalid opcode: 0000 [1] SMP CPU 0 Modules linked in: i915 drm deflate zlib_deflate twofish twofish_common serpent blowfish des ce Pid: 0, comm: swapper Not tainted 2.6.21-rc3-default #15 RIP: 0010:[] [] queue_work+0x32/0x51 RSP: 0018:ffffffff805fada8 EFLAGS: 00010013 RAX: ffffffff80683f38 RBX: ffffffff804ae700 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff80683f30 RDI: ffff81000134a840 RBP: 0000000000000001 R08: 0000000000000005 R09: 0000000000000002 R10: ffffffff805990e0 R11: ffff810037f4c0f0 R12: 000000000000006b R13: ffff81007aa23000 R14: 0000000000000001 R15: 0000000000000096 FS: 0000000000000000(0000) GS:ffffffff804d8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00002b72026e9000 CR3: 0000000079175000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffffffff8059e000, task ffffffff80490840) Stack: 0000000000000096 ffffffff803635db ffffffff805fadf8 0000000000000001 ffff8100013c2e40 0000000000000025 ffff81007c931c00 ffff81007aa23000 0000000000000001 ffffffff8035e3ee 0000000000000092 ffff810037cc8000 Call Trace: [] __handle_sysrq+0x98/0x129 [] kbd_event+0x32e/0x56a [] input_event+0x422/0x44a [] atkbd_interrupt+0x449/0x503 [] serio_interrupt+0x37/0x6f [] i8042_interrupt+0x1f4/0x20a [] smp_send_timer_broadcast_ipi+0x2d/0x4e [] handle_IRQ_event+0x25/0x53 [] handle_edge_irq+0xe4/0x128 [] call_softirq+0x1c/0x28 [] do_IRQ+0x6c/0xd3 [] mwait_idle+0x0/0x45 [] ret_from_intr+0x0/0xa [] datagram_poll+0x0/0xc8 [] mwait_idle+0x42/0x45 [] cpu_idle+0x8b/0xae [] start_kernel+0x2b9/0x2c5 [] _sinittext+0x15e/0x162 Code: 0f 0b eb fe 48 8b 07 48 63 d2 48 f7 d0 48 8b 3c d0 e8 13 ff RIP [] queue_work+0x32/0x51 RSP Kernel panic - not syncing: Aiee, killing interrupt handler! Signed-off-by: Bernhard Walle Acked-by: Eric Biederman Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] swsusp: fix suspend when console is in VT_AUTO+KD_GRAPHICS mode

2007-03-17T02:25:05+00:00

When the console is in VT_AUTO+KD_GRAPHICS mode, switching to the SUSPEND_CONSOLE fails, resulting in vt_waitactive() waiting indefinitely or until the task is interrupted. This patch tests if a console switch can occur in set_console() and returns early if a console switch is not possible. [akpm@linux-foundation.org: cleanup] Signed-off-by: Andrew Johnson Acked-by: Pavel Machek Cc: "Antonino A. Daplas" Cc: "Rafael J. Wysocki" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Fix SAK_work workqueue initialization.

2007-02-14T00:07:36+00:00

Somewhere in the rewrite of the work queues my cleanup of SAK handling got broken. Maybe I didn't retest it properly or possibly the API was changing so fast I missed something. Regardless currently triggering a SAK now generates an ugly BUG_ON and kills the kernel. Thanks to Alexey Dobriyan for spotting this. This modifies the use of SAK_work to initialize it when the data structure it resides in is initialized, and to simply call schedule_work when we need to generate a SAK. I update both data structures that have a SAK_work member for consistency. All of the old PREPARE_WORK calls that are now gone. If we call schedule_work again before it has processed it has generated the first SAK it will simply ignore the duplicate schedule_work request. Signed-off-by: Eric W. Biederman Signed-off-by: Linus Torvalds

[PATCH] tty: update the tty layer to work with struct pid

2007-02-12T17:48:32+00:00

Of kernel subsystems that work with pids the tty layer is probably the largest consumer. But it has the nice virtue that the assiation with a session only lasts until the session leader exits. Which means that no reference counting is required. So using struct pid winds up being a simple optimization to avoid hash table lookups. In the long term the use of pid_nr also ensures that when we have multiple pid spaces mixed everything will work correctly. Signed-off-by: Eric W. Biederman Cc: Alan Cox Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds