Output in a virtual console (tty1) ridiculously slow; possible graphics acceleration issue

5

2

Some time ago on an older computer running Ubuntu I noticed the output on a virtual console (e.g. tty1) is slow. It wasn't an issue there and barely even noticeable.

But now on my new laptop with Manjaro Linux (derived from Arch) it's sometimes ridiculously slow. I think it's different than the situation described and explained here, therefore my question is not a duplicate. I suspect graphics acceleration issue.

I found out that the issue is heavily affected by the processor clock speed. This video shows how it looks like at 800 MHz.

Possibly relevant info from dmesg:

[    0.474770] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.478826] vesafb: mode is 1920x1080x32, linelength=7680, pages=0
[    0.478827] vesafb: scrolling: redraw
[    0.478828] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.478843] vesafb: framebuffer at 0xa0000000, mapped to 0xffffc90001000000, using 8128k, total 8128k
[    0.661095] Console: switching to colour frame buffer device 240x67
[    0.842325] fb0: VESA VGA frame buffer device
[    2.301199] fb: switching to inteldrmfb from VESA VGA
[    2.363655] fbcon: inteldrmfb (fb0) is primary device
[    2.363698] Console: switching to colour frame buffer device 240x67
[    2.363705] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

The scrolling: redraw part looks interesting, though I'm not sure it means anything, since it says switching to inteldrmfb from VESA VGA.

Output of fbset -i:

mode "1920x1080" 
    geometry 1920 1080 1920 1080 32 
    timings 0 0 0 0 0 0 0 
    accel true 
    rgba 8/16,8/8,8/0,0/0 
endmode 

Frame buffer device information: 
    Name : inteldrmfb 
    Address : 0xa0000000 
    Size : 8294400 
    Type : PACKED PIXELS 
    Visual : TRUECOLOR 
    XPanStep : 1 
    YPanStep : 1 
    YWrapStep : 0 
    LineLength : 7680 
    Accelerator : No

Some additional tests to document the difference:

  • time python -c "for i in range(100): print(\"hi\")"
    shows me 0.03s on xfce4-terminal and 0.23s on a virtual console.

  • time echo -e "\033c"
    0s on xfce4-terminal and 0.14s-0.16s on a virtual console.

  • time man gpm (and pressing Q while it opens up)
    instantly on xfce4-terminal, 3s-4s on a virtual console.

This is especially frustrating while scrolling through man pages. Interestingly nano doesn't seem to be affected by this.

How to make my virtual consoles render text with decent speed?

Mealynn

Posted 2017-02-13T20:19:13.347

Reputation: 51

It's not a duplicate: as can be seen in the video, the problem is definitely unaccelerated scrolling, not that "gnome terminal handles data in bursts, while the virtual console doesn't" as suggested in th elinked answer. – dirkt – 2017-02-16T15:18:58.380

I'm the one who first marked your question as a duplicate. I wouldn't do this now, since you added the video etc. I have tidied your question and emphasized possible graphics acceleration issue. I'm voting to reopen the question. – Kamil Maciorowski – 2017-02-16T16:18:28.223

Answers

2

BTW, tty means any "teletype" device (serial line, pseudo terminal, ...). What you are talking about is the Linux virtual console. And scrolling on that is ridiculously slow, because recent versions of Linux use graphics mode in a framebuffer instead of text mode, but sometimes not graphics acceleration.

So check your framebuffer settings and see if you can't get it to use acceleration by using the right driver etc.

Edit: As one can see in the video, the problem is definitely unaccelerated scrolling by redrawing everything, one can see the "waves" as the content moves.

I'm also confused why first you seem to be using vesafb (which does slow unaccelerated scrolling) and then 2 seconds later inteldrmfb (which should do accelerated scrolling). Possible the problem is related to the switch. Please provide full dmesg output after boot, put it in a pastebin etc., and edit question with the link.

dirkt

Posted 2017-02-13T20:19:13.347

Reputation: 11 627

Thanks for the reply. I looked into that. Unfortunately I didn't find a way to change anything for the console, but "fbset" tells me acceleration is activated for /dev/fb0. – Mealynn – 2017-02-14T16:47:44.360

Hm. Please edit question with output of fbset -i. Is the problem scrolling, or is the output so slow that you can see the characters appearing in sequence? Any possibly related messages in dmesg or syslog? – dirkt – 2017-02-14T17:10:56.533

As far as I can tell lines appear at once. And I don't seem to have a syslog – Mealynn – 2017-02-14T19:18:13.427

So if man gpm takes 4 seconds, where is the delay? Between lines? Because of scrolling? (I'm trying to narrow down the cause of the problem). And under systemd, you access the syslog via journalctl. I am pretty sure you have one. :-) – dirkt – 2017-02-15T10:12:53.747

I couldn't find anything usefull in journalctl, that didn't already show up in dmesg. And yes, I guess the delay is between the lines. Also, I added a short video to the post. I have a hard time explaining exactly what I see because I'm not native english. – Mealynn – 2017-02-16T14:50:25.373