change linux text console scrolling speed - without rebooting
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.
linux console text framebuffer
add a comment |
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.
linux console text framebuffer
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 kernelno-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 thestty
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
add a comment |
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.
linux console text framebuffer
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.
linux console text framebuffer
linux console text framebuffer
asked Jan 24 '15 at 2:12
JuanJuan
44759
44759
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 kernelno-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 thestty
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
add a comment |
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 kernelno-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 thestty
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
A change like that can only occur with a reboot, and I recommend the uvesafb driver.
– eyoung100
Jan 24 '15 at 2:21
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
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
That makes better sense... my MB isn't EFI capable
– eyoung100
Jan 24 '15 at 3:53
add a comment |
2 Answers
2
active
oldest
votes
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.
add a comment |
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
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f180769%2fchange-linux-text-console-scrolling-speed-without-rebooting%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
add a comment |
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.
add a comment |
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.
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.
answered Jan 27 '15 at 19:01
JdeBPJdeBP
35.3k470165
35.3k470165
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
edited Sep 16 '18 at 3:23
answered Sep 16 '18 at 3:02
dlitzdlitz
1033
1033
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f180769%2fchange-linux-text-console-scrolling-speed-without-rebooting%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 thestty
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