change linux text console scrolling speed - without rebooting












1















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.










share|improve this question























  • 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















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.










share|improve this question























  • 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












1








1








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.










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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 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



















  • 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

















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










2 Answers
2






active

oldest

votes


















0















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.






share|improve this answer































    0














    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





    share|improve this answer

























      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
      });


      }
      });














      draft saved

      draft discarded


















      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









      0















      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.






      share|improve this answer




























        0















        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.






        share|improve this answer


























          0












          0








          0








          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.






          share|improve this answer














          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 27 '15 at 19:01









          JdeBPJdeBP

          35.3k470165




          35.3k470165

























              0














              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





              share|improve this answer






























                0














                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





                share|improve this answer




























                  0












                  0








                  0







                  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





                  share|improve this answer















                  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






                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Sep 16 '18 at 3:23

























                  answered Sep 16 '18 at 3:02









                  dlitzdlitz

                  1033




                  1033






























                      draft saved

                      draft discarded




















































                      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.




                      draft saved


                      draft discarded














                      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





















































                      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







                      Popular posts from this blog

                      How to make a Squid Proxy server?

                      Is this a new Fibonacci Identity?

                      19世紀