Dear Maintainer,

thank you all for creating Debian!


After the upgrade to wheezy I noticed the following regession:

Scrolling in an x-term is much slower than before (it is clearly
noticeable by eye).

Investigation shows, that scrolling is about 5 times slower when KMS is on.

A "time seq 100000" takes about 12 seconds with
"options radeon modeset=1" in /etc/modprobe.d/radeon-kms.conf.

A "time seq 100000" takes about 2-3 seconds with
"options radeon modeset=0" in /etc/modprobe.d/radeon-kms.conf.

xterm and rxvt show the same effect.


When I remove the file /etc/X11/xorg.conf entirely, the fbdev driver
gets loaded and then the scrolling in a x-term is even faster (about 1
second).

Installed xserver packages:

% aptitude search "~ixserver"
i A x11-xserver-utils
i A xserver-common
i   xserver-xorg
i   xserver-xorg-core
i A xserver-xorg-input-all
i A xserver-xorg-input-evdev
i A xserver-xorg-input-kbd
i A xserver-xorg-input-mouse
i A xserver-xorg-input-synaptics
i   xserver-xorg-video-fbdev
i A xserver-xorg-video-radeon


Thanks a lot!

Tilo

[...]

Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=34486

On Wed, 09 Jan 2013 13:06:36 +0100, Michel Dänzer <daenzer@debian.org> wrote:

thank you for the reply:

Indeed, using

% grep ColorTiling /etc/X11/xorg.conf
         Option          "ColorTiling"   "off"

the scrolling is twice as fast as without this option (from 12sec down to
6sec). That is still almost three times slower than without KMS, but
already much more usable!

What worries me is, that now I get the following error messages, whenever
I switch tags (using awesome WM, tags are like virtual desktops):

r300: I got a pre-allocated buffer to use it as a texture storage, but the
buffer is too small. I'll use the buffer anyway, because I can't crash
here, but it's dangerous. This can be a DDX bug. Got: 7114752B, Need:
7119360B, Info:
r300: texture_desc_init: Macro:  NO, Micro: YES, Pitch: 1728, Dim:
1678x1029x1, LastLevel: 0, Size: 7119360, Format: s8_uint_z24_unorm
r300: I got a pre-allocated buffer to use it as a texture storage, but the
buffer is too small. I'll use the buffer anyway, because I can't crash
here, but it's dangerous. This can be a DDX bug. Got: 176128B, Need:
179712B, Info:
r300: texture_desc_init: Macro:  NO, Micro: YES, Pitch: 1728, Dim:
1678x25x1, LastLevel: 0, Size: 179712, Format: s8_uint_z24_unorm
r300: I got a pre-allocated buffer to use it as a texture storage, but the
buffer is too small. I'll use the buffer anyway, because I can't crash
here, but it's dangerous. This can be a DDX bug. Got: 7114752B, Need:
7119360B, Info:
r300: texture_desc_init: Macro:  NO, Micro: YES, Pitch: 1728, Dim:
1678x1029x1, LastLevel: 0, Size: 7119360, Format: s8_uint_z24_unorm
r300: I got a pre-allocated buffer to use it as a texture storage, but the
buffer is too small. I'll use the buffer anyway, because I can't crash
here, but it's dangerous. This can be a DDX bug. Got: 176128B, Need:
179712B, Info:
r300: texture_desc_init: Macro:  NO, Micro: YES, Pitch: 1728, Dim:
1678x25x1, LastLevel: 0, Size: 179712, Format: s8_uint_z24_unorm
r300: I got a pre-allocated buffer to use it as a texture storage, but the
buffer is too small. I'll use the buffer anyway, because I can't crash
here, but it's dangerous. This can be a DDX bug. Got: 7114752B, Need:
7119360B, Info:
r300: texture_desc_init: Macro:  NO, Micro: YES, Pitch: 1728, Dim:
1678x1029x1, LastLevel: 0, Size: 7119360, Format: s8_uint_z24_unorm
Failed to open VDPAU backend libvdpau_r300.so: cannot open shared object
file: No such file or directory
r300: I got a pre-allocated buffer to use it as a texture storage, but the
buffer is too small. I'll use the buffer anyway, because I can't crash
here, but it's dangerous. This can be a DDX bug. Got: 176128B, Need:
179712B, Info:
r300: texture_desc_init: Macro:  NO, Micro: YES, Pitch: 1728, Dim:
1678x25x1, LastLevel: 0, Size: 179712, Format: s8_uint_z24_unorm

Maybe related to https://bugs.freedesktop.org/show_bug.cgi?id=42085

Now I hesitate to switch ColorTiling off, because a "buffer is too small"
warning sounds not too good to me ...

Thank you!

Regards,
	Tilo

The better solution would be to configure your terminals to use
fontconfig/Xft for text rendering.

[...]

Looks like it. I attached a patch that might fix it.

On Thu, 10 Jan 2013 09:16:37 +0100, Michel Dänzer <daenzer@debian.org> wrote:

Do you have a link to "the correct debian way" to enable fontconfig/Xft
for text rendering? (Me being no X11 expert ...)

Is it a fontcontig and Xft, or is it a either fontcontig or Xft?

Thanks a alot!

	Tilo

It's app/toolkit specific. E.g. with xterm you can enable it with -fa
and related options.

It's mainly about Xft. Most users of that also use fontconfig for
selecting the fonts to use, but that's not required.

Most apps/toolkits have used the modern text rendering infrastructure by
default for a long time, but a lot of terminal emulators are still
holding out for some reason.

On Thu, 10 Jan 2013 10:34:07 +0100, Michel Dänzer <daenzer@debian.org> wrote:

Thanks a lot for your help! It lead me to a nice workaround (even if the
original question KMS=0 vs. KMS=1 is not really solved by this).

The only thing I did (after reading about Xft and fontconfig) was to
install rxvt-unicode, which has xft support.

Running "time seq 100000" with various terminal/font combinations gives:

xterm -fn 9x15:
real    0m50.001s
user    0m0.180s
sys     0m0.428s

xterm -fa 9x15:
real    0m7.785s
user    0m0.116s
sys     0m0.180s

rxvt:
real    0m11.707s
user    0m0.140s
sys     0m0.252s

urxvt:
real	0m0.994s
user	0m0.176s
sys	0m0.308s

So for some reason urxvt seems to use a font path, which is as fast as the
speed having lenny installed. The Xresources for this test were:

% cat .Xresources
xterm*background: black
xterm*charClass: 33:48,37:48,45-47:48,38:48
xterm*font: 9x15
xterm*foreground: white
xterm*saveLines: 1024
xterm*scrollBar: false
xterm*visualBell: true
xterm*visualBellDelay: 100

rxvt*background: black
rxvt*charClass: 33:48,37:48,45-47:48,38:48
rxvt*font: 9x15
rxvt*foreground: white
rxvt*saveLines: 1024
rxvt*scrollBar: false
rxvt*visualBell: true
rxvt*visualBellDelay: 100

urxvt*background: black
urxvt*charClass: 33:48,37:48,45-47:48,38:48
urxvt*font: 9x15
urxvt*foreground: white
urxvt*saveLines: 1024
urxvt*scrollBar: false
urxvt*visualBell: true
urxvt*visualBellDelay: 100

Thanks again!

	Tilo

On Thu, 10 Jan 2013 10:34:07 +0100, Michel Dänzer <daenzer@debian.org> wrote:

But accoding to the rxvt-unicode man-page, my xresource "urxvt*font: 9x15"
does not select a xft font, because urxvt uses x fonts by default. So
urxvt is able to scoll fast although no xft font is used. Running "ltrace
urxvt" shows, that xft funcions are only called, if I specify the font
with "xft:9x15".

Regards,
	Tilo