linux.git/drivers/tty/vt/vt.c, branch v4.20

Merge tag 'tty-4.20-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2018-11-10T19:32:14+00:00

Pull tty/serial fixes from Greg KH:
 "Here are some small tty fixes for 4.20-rc2

  One of these missed the original 4.19-final release, I missed that I
  hadn't done a pull request for it as it was in linux-next and my
  branch for a long time, that's my fault.

  The others are small, fixing some reported issues and finally fixing
  the termios mess for alpha so that glibc has a chance to implement
  some missing functionality that has been pending for many years now.

  All of these have been in linux-next with no reported issues"

* tag 'tty-4.20-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  serial: sh-sci: Fix could not remove dev_attr_rx_fifo_timeout
  arch/alpha, termios: implement BOTHER, IBSHIFT and termios2
  termios, tty/tty_baudrate.c: fix buffer overrun
  vt: fix broken display when running aptitude
  serial: sh-sci: Fix receive on SCIFA/SCIFB variants with DMA

vt: fix broken display when running aptitude

2018-11-08T11:36:40+00:00

If you run aptitude on framebuffer console, the display is corrupted. The
corruption is caused by the commit d8ae7242. The patch adds "offset" to
"start" when calling scr_memsetw, but it forgets to do the same addition
on a subsequent call to do_update_region.

Signed-off-by: Mikulas Patocka 
Fixes: d8ae72427187 ("vt: preserve unicode values corresponding to screen characters")
Reviewed-by: Nicolas Pitre 
Cc: stable@vger.kernel.org	# 4.19
Signed-off-by: Greg Kroah-Hartman

vt: Remove vc_panic_force_write

2018-09-11T12:11:51+00:00

It was only used by the panic support in fbcon, which is now gone.
Remove this now dead code too.

Acked-by: Greg Kroah-Hartman 
Cc: Greg Kroah-Hartman 
Cc: Kees Cook 
Cc: Joe Perches 
Cc: Daniel Vetter 
Cc: Meng Xu 
Cc: Nicolas Pitre 
Cc: Thomas Meyer 
Cc: Mike Frysinger 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Hans de Goede 
Cc: Thierry Reding 
Cc: David Lechner 
Cc: Philippe Ombredanne 
Cc: Thomas Gleixner 
Cc: Kate Stewart 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20180822085405.10787-2-daniel.vetter@ffwll.ch

vt: avoid a VLA in the unicode screen scroll function

2018-07-21T07:19:46+00:00

The nr argument is typically small: most often nr == 1. However this
could be abused with a very large explicit scroll in a resized screen.
Make the code scroll lines by performing an array rotation operation to
avoid the need for a large temporary space.

Requested-by: Kees Cook 
Suggested-by: Adam Borowski 
Signed-off-by: Nicolas Pitre 
Signed-off-by: Greg Kroah-Hartman

vt: coherence validation code for the unicode screen buffer

2018-07-21T07:18:27+00:00

Make sure the unicode screen buffer matches the video screen content.
This is provided for debugging convenience and disabled by default.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Greg Kroah-Hartman

vt: selection: take screen contents from uniscr if available

2018-07-21T07:18:27+00:00

This preserves whatever was written even if we can't currently display the
given glyph.  Mouse paste won't corrupt any character of wcwidth() == 1
anymore.

Note that for now uniscr doesn't get allocated until something reads
/dev/vcsuN for that console, making this code dormant for most users.

Signed-off-by: Adam Borowski 
Acked-by: Nicolas Pitre 
Signed-off-by: Greg Kroah-Hartman

Merge 4.18-rc3 into tty-next

2018-07-02T06:23:43+00:00

We want ths tty core changes in here as well.

Signed-off-by: Greg Kroah-Hartman

vt: unicode fallback for scrollback

2018-06-28T12:38:12+00:00

There is currently no provision for scrollback content in the core code,
leaving that to backend video drivers where this can be highly optimized.
There is currently no common method for those drivers to tell the core
what part of the scrollback is actually displayed and what size the
scrollback buffer is either. Because of that, the unicode screen buffer
has no provision for any scrollback.

At least we can provide backtranslated glyph values when the scrollback
is active which should be plenty good enough for now.

Signed-off-by: Nicolas Pitre 
Tested-by: Dave Mielke 
Acked-by: Adam Borowski 
Signed-off-by: Greg Kroah-Hartman

vt: introduce unicode mode for /dev/vcs

2018-06-28T12:38:12+00:00

Now that the core vt code knows how to preserve unicode values for each
displayed character, it is then possible to let user space access it via
/dev/vcs*.

Unicode characters are presented as 32 bit values in native endianity
via the /dev/vcsu* devices, mimicking the simple /dev/vcs* devices.
Unicode with attributes (similarly to /dev/vcsa*) is not supported at
the moment.

Data is available only as long as the console is in UTF-8 mode. ENODATA
is returned otherwise.

This was tested with the latest development version (to become
version 5.7) of BRLTTY. Amongst other things, this allows ⠋⠕⠗ ⠞⠓⠊⠎
⠃⠗⠁⠊⠇⠇⠑⠀⠞⠑⠭⠞⠀to appear directly on braille displays regardless of the
console font being used.

Signed-off-by: Nicolas Pitre 
Tested-by: Dave Mielke 
Acked-by: Adam Borowski 
Signed-off-by: Greg Kroah-Hartman

vt: preserve unicode values corresponding to screen characters

2018-06-28T12:38:12+00:00

The vt code translates UTF-8 strings into glyph index values and stores
those glyph values directly in the screen buffer. Because there can only
be at most 512 glyphs, it is impossible to represent most unicode
characters, in which case a default glyph (often '?') is displayed
instead. The original unicode value is then lost.

This patch implements the basic screen buffer handling to preserve unicode
values alongside corresponding display glyphs.  It is not activated by
default, meaning that people not relying on that functionality won't get
the implied overhead.

Signed-off-by: Nicolas Pitre 
Tested-by: Dave Mielke 
Acked-by: Adam Borowski 
Signed-off-by: Greg Kroah-Hartman