# slow virtual consoles with KMS

## cyberjun

Hi,

        I am running gentoo-sources-2.6.33-r1 on a dell D510 laptop with intel graphics. I have enabled KMS and thus framebuffer. Everything is working fine except the VCs. The switch from X to VC or vice versa is fast (as promised by KMS). However the VCs are slow in rendering text.

From gnome-terminal:

 *Quote:*   

> localhost ~$ time ls -lrt /usr/bin
> 
> .......
> 
> <snip snip>
> ...

 

I am running xf86-video-intel-2.10.0-r1 and xorg-server-1.7.6. Is KMS framebuffer inherently slower than gnome-terminal's rendering?

--cyberjun

----------

## Ant P.

Unless someone decides to push X's 2D accel code into the kernel, it's always going to be slower.

----------

## dmpogo

It is not KMS per se.   I use vesafb with high-rez mode and no KMS,   and my numbers are almost identical to yours. Lack of acceleration shows.  (I think I remember intelfb had some 2D acceleration, but it got rusted away)

----------

## M

vesafb is not accelerated, fb drivers for specific cards are, but it seems like those are not touched for years. But I tried nouveau many times and lately with kms, I didn't time it but fb seems much much faster then vesafb and mplayer works really good, I think kms should be accelerated. My guess is that something is wrong with intel drivers.

I remember how good it was when I used matrox video card with fb driver and kernel driver for mplayer (one of main devs had matrox card  :Wink:  ) , I think that analog tv with mplayer in framebuffer had better quality compared to X. I now have old t20 with savage card and it surprises me how fast it is when switching VC, I also saw huge difference between savagefb and vesafb (savagefb is faster but not so usable).

----------

## Rexilion

The threadstarter has an accelerated framebuffer, I'm sure of that. I mean, if you used a standard VGA terminal it could have taken minutes for that action to complete. I think that userspace terminals like xterm, gnome-terminal et all also skip large chunks of text: they just display it once and then move over to the next. The VC slides no matter how much you put in it which causes it to take a little longer...

----------

## M

Maybe disabling the VGACON_SOFT_SCROLLBACK can help a little bit, this option uses system ram instead of vga ram but slows down console.

----------

## Rexilion

 *M wrote:*   

> Maybe disabling the VGACON_SOFT_SCROLLBACK can help a little bit, this option uses system ram instead of vga ram but slows down console.

 

It slows down the console for more scrollback buffer, it won't speed it up I guess.

----------

