Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 03 1月, 2009 1 次提交
    • J
      n_tty: Fix loss of echoed characters and remove bkl from n_tty · a88a69c9
      由 Joe Peterson 提交于 
      Fixes the loss of echoed (and other ldisc-generated characters) when
the tty is stopped or when the driver output buffer is full (happens
frequently for input during continuous program output, such as ^C)
and removes the Big Kernel Lock from the N_TTY line discipline.

Adds an "echo buffer" to the N_TTY line discipline that handles all
ldisc-generated output (including echoed characters).  Along with the
loss of characters, this also fixes the associated loss of sync between
tty output and the ldisc state when characters cannot be immediately
written to the tty driver.

The echo buffer stores (in addition to characters) state operations that need
to be done at the time of character output (like management of the column
position).  This allows echo to cooperate correctly with program output,
since the ldisc state remains consistent with actual characters written.

Since the echo buffer code now isolates the tty column state code
to the process_out* and process_echoes functions, we can remove the
Big Kernel Lock (BKL) and replace it with mutex locks.

Highlights are:

* Handles echo (and other ldisc output) when tty driver buffer is full
  - continuous program output can block echo
* Saves echo when tty is in stopped state (e.g. ^S)
  - (e.g.: ^Q will correctly cause held characters to be released for output)
* Control character pairs (e.g. "^C") are treated atomically and not
  split up by interleaved program output
* Line discipline state is kept consistent with characters sent to
  the tty driver
* Remove the big kernel lock (BKL) from N_TTY line discipline
Signed-off-by: NJoe Peterson <joe@skyrush.com>
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a88a69c9
  3. 14 12月, 2008 1 次提交
    • I
      console ASCII glyph 1:1 mapping · 1c55f187
      由 Ingo Brueckl 提交于 
      For the console, there is a 1:1 mapping of glyphs which cannot be found
in the current font.  This seems to be meant as a kind of 'emergency
fallback' for fonts without unicode mapping which otherwise would
display nothing readable on the screen.

At the moment it affects all chars for which no substitution character
is defined.  In particular this means that for all chars (>= 128) where
there is no iso88591-1/unicode character (e.g.  control character area)
you'll get the very strange 1:1 mapping of the (cp437) graphics card
glyphs.

I'm pretty sure that the 1:1 mapping should only affect strict ASCII
code characters, i.e.  chars < 128.

The patch limits the mapping as it probably was meant anyway.
Signed-off-by: NIngo Brueckl <ib@wupperonline.de>
Acked-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Egmont Koblinger <egmont@uhulinux.hu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1c55f187
  5. 07 11月, 2008 1 次提交
  7. 17 10月, 2008 1 次提交
  9. 15 10月, 2008 1 次提交
  11. 14 10月, 2008 4 次提交
  13. 16 8月, 2008 1 次提交
  15. 05 8月, 2008 1 次提交
    • A
      vt: Deadlock workaround · d5cae364
      由 Alan Cox 提交于 
      2.6.26 corrected the mutex locking on tty resizing to fix the case where
you could get the tty/vt sizing out of sync. That turns out to have a
deadlock.

The actual fix is really major and I've got it lined up as part of the ops
changes for 2.6.28 so for 2.6.26/2.6.27 it is safer to reintroduce this
ages old minor bug.
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d5cae364
  17. 25 7月, 2008 2 次提交
  19. 22 7月, 2008 1 次提交
  21. 07 6月, 2008 2 次提交
  23. 04 6月, 2008 1 次提交
  25. 09 5月, 2008 1 次提交
  27. 30 4月, 2008 4 次提交
  29. 29 4月, 2008 1 次提交
    • J
      vt: fix background color on line feed · c9e587ab
      由 Jan Engelhardt 提交于 
      A command that causes a line feed while a background color is active,
such as

	perl -e 'print "x" x 60, "\e[44m", "x" x 40, "\e[0m\n"'
and
	perl -e 'print "x" x 40, "\e[44m\n", "x" x 40, "\e[0m\n"'

causes the line that was started as a result of the line feed to be completely
filled with the currently active background color instead of the default
color.

When scrolling, part of the current screen is memcpy'd/memmove'd to the new
region, and the new line(s) that will appear as a result are cleared using
memset.  However, the lines are cleared with vc->vc_video_erase_char, causing
them to be colored with the currently active background color.  This is
different from X11 terminal emulators which always paint the new lines with
the default background color (e.g.  `xterm -bg black`).

The clear operation (\e[1J and \e[2J) also use vc_video_erase_char, so a new
vc->vc_scrl_erase_char is introduced with contains the erase character used
for scrolling, which is built from vc->vc_def_color instead of vc->vc_color.
Signed-off-by: NJan Engelhardt <jengelh@computergmbh.de>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c9e587ab
  31. 28 4月, 2008 1 次提交
  33. 05 3月, 2008 1 次提交
  35. 07 2月, 2008 1 次提交
  37. 20 10月, 2007 1 次提交
  39. 19 10月, 2007 1 次提交
  41. 17 10月, 2007 2 次提交
    • B
      add CONFIG_VT_UNICODE · 2e8ecb9d
      由 Bill Nottingham 提交于 
      As of now, the kernel defaults to non-unicode and XLATE for the keyboard.
We've been changing this in Fedora, but that requires patching the defaults
in the kernel.

The attached introduces CONFIG_VT_UNICODE, which sets the console in
unicode mode by default on boot, including both the virtual terminal and
the keyboard driver.
Signed-off-by: NBill Nottingham <notting@redhat.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2e8ecb9d
    • A
      vt/vgacon: Check if screen resize request comes from userspace · e400b6ec
      由 Antonino A. Daplas 提交于 
      Various console drivers are able to resize the screen via the con_resize()
hook.  This hook is also visible in userspace via the TIOCWINSZ, VT_RESIZE and
VT_RESIZEX ioctl's.  One particular utility, SVGATextMode, expects that
con_resize() of the VGA console will always return success even if the
resulting screen is not compatible with the hardware.  However, this
particular behavior of the VGA console, as reported in Kernel Bugzilla Bug
7513, can cause undefined behavior if the user starts with a console size
larger than 80x25.

To work around this problem, add an extra parameter to con_resize().  This
parameter is ignored by drivers except for vgacon.  If this parameter is
non-zero, then the resize request came from a VT_RESIZE or VT_RESIZEX ioctl
and vgacon will always return success.  If this parameter is zero, vgacon will
return -EINVAL if the requested size is not compatible with the hardware.  The
latter is the more correct behavior.

With this change, SVGATextMode should still work correctly while in-kernel and
stty resize calls can expect correct behavior from vgacon.
Signed-off-by: NAntonino Daplas <adaplas@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e400b6ec
  43. 18 7月, 2007 5 次提交
  45. 24 6月, 2007 1 次提交
    • E
      console UTF-8 fixes (fix) · 1ed8a2b3
      由 Egmont Koblinger 提交于 
      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: NEgmont Koblinger <egmont@uhulinux.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1ed8a2b3
  47. 09 5月, 2007 4 次提交