3

Is there any way to change to the text console scrolling speed without rebooting? Currently using Fedora, but non-distribution-specific answers appreciated.

https://www.kernel.org/doc/Documentation/fb/vesafb.txt

I'd like to use 'ywrap' in the above documented kernel parameters for vesafb without having to reboot the kernel to try it.

  • A change like that can only occur with a reboot, and I recommend the uvesafb driver. – eyoung100 Jan 24 '15 at 2:21
  • if you're on a computer made within the last few years you probably shouldn't be using {u,}vesafb - instead try to use the native efi framebuffer - which should come through as a native VGA fb anyway. To slow down scroll speed disable hard scrolling - try the kernel no-scroll parameter. In any case - focus more on the terminal emulator (probably the linux console) than the fb it writes to. You could also look at the stty speed parameters. – mikeserv Jan 24 '15 at 2:25
  • That makes better sense... my MB isn't EFI capable – eyoung100 Jan 24 '15 at 3:53
1

stty is irrelevant.

The hardware line speed set via the line discipline has no meaning for a virtual terminal if it is non-zero. It only has meaning for "terminals" that are formed with actual serial devices, because it controls the serial device line speed. There's no serial device involved in the kernel's built-in terminal emulator.

ywrap is not a panacea.

Display hardware mechanisms like the ones enabled by ywrap can only help a terminal emulator with (nearly-)whole-height full-line-width scrolling.

For obvious reasons, a terminal emulator cannot make use of such hardware mechanisms at all if it supports left and right margins, and thus scroll actions are not scrolling the full line width. The Linux kernel's built-in terminal emulator does not support the DECSLRM ("DEC Set Left and Right Margins") control sequence (or anything like it) in the first place, though, so partial-line scrolling is not a concern here.

But partial-height scrolling is. The Linux kernel's built-in terminal emulator does support the DECSTBM ("DEC Set Top and Bottom Margins") control sequence, which allows applications to set the first and last lines on the screen to involve in scrolling. And this control sequence is properly listed as the change_scroll_region capability in the linux terminfo entry. The use of such scrolling regions is indeed fairly common in full-screen TUI applications. vim uses them when scrolling full-width windows, for example.

The Linux kernel's fbcon driver only uses the ywrap mechanism if over three quarters of the entire screen image is being retained and moved by the scroll action. This is because partial-height scrolling using ywrap also involves some copying, so that the "unscrolled" parts of the screen appear to remain in the same place, even though the hardware has scrolled the entire screen. The smaller the scrolling region, the less useful ywrap is, because the greater the amount of copying that has to take place in order to present the illusion that some parts of the display were not scrolled.

The control sequences are not supported.

On real terminals, as opposed to virtual terminals, there are sometimes control sequences that allow one to select scrolling speeds. For example: The DEC VT family has a flag named DECSCLM ("DEC Scroll Mode", DEC private mode flag #4). If reset (via the ECMA-48 RM control sequence) the terminal scrolls as fast as it can. If set (via the ECMA-48 SM control sequence) the terminal scrolls more slowly, inserting delays as it scrolls.

If the Linux kernel's built-in terminal emulator were a full DEC VT emulation, this would be the way to control scrolling speed. But it isn't. Although some userspace terminal emulators like xterm implement this mode flag, I know of no kernel terminal emulator that does. The Linux kernel's built-in terminal emulator certainly does not.

1

You can remove a Linux kernel framebuffer driver module without rebooting if you tell the VT subsystem to stop using it (see Documentation/console/console.txt for details):

# tl;dr
reload_fb() {
  echo 0 > /sys/devices/virtual/vtconsole/vtcon1/bind
  rmmod uvesafb
  modprobe uvesafb scroll=ywrap
}
reload_fb

Caution: If vtcon0 is a dummy driver (e.g. on EFI) or if there are bugs (BIOS firmware tends to have bugs), this may leave you with no working console display until you reboot or load a working fb driver. Only the display stops working; you can still type commands, but you won't be able to see their output. X11 seems to be unaffected. Therefore, I recommend that you log in remotely over SSH, or via an X terminal on the same machine.

Note: If you're using the uvesafb driver (as suggested by eyoung100), you will also need to install the v86d package.

You can list all of the loaded console drivers:

[root@linflas ~]# cd /sys/devices/virtual/vtconsole
[root@linflas vtconsole]# grep -H "" vtcon*/[bn]*
vtcon0/bind:0
vtcon0/name:(S) dummy device
vtcon1/bind:1
vtcon1/name:(M) frame buffer device

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.