HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

göteborg-johan · 2009-04-11 21:06:25

This might be slightly offtopic, but i read the KernelNewbies info about modeswitching and it really sounds great, but for those of us who needs proprietary drivers. Can proprietary drivers make use of the new features or does the driver have to be integrated into the kernel?

Last edited by göteborg-johan (2009-04-11 21:07:42)

airmind · 2009-04-12 00:13:11

Hi, I'm using KMS with xorg-server 1.6 and it's working great (the console switching is beautiful). But I'm having some speed issues with Compiz, it is running slowly. I'm using the UXA acceleration mode with the Intel driver.
Any reason it is running slower then before? Anything I can do to fix it?

airmind · 2009-04-12 00:16:21

göteborg-johan wrote:

This might be slightly offtopic, but i read the KernelNewbies info about modeswitching and it really sounds great, but for those of us who needs proprietary drivers. Can proprietary drivers make use of the new features or does the driver have to be integrated into the kernel?

Something has to be in the kernel, that is why the Intel driver works, but I think binary drivers will still work, but they require something inside the kernel which should no be binary only. The Radeon driver for instance is already working, but they use some open-source code (and specifications) for that.

Ranguvar · 2009-04-12 03:42:24

It'll be very hard for binary drivers to support KMS, since KMS relies on the GEM memory manager IIRC. Most binary drivers have their own memory manager. This is just one of the problems. Simply, it's as airmind said. Most binary drivers now have their own ways of doing certain things, and KMS needs them to use the kernel's way, which means they'll have to retool their drivers quite a bit.

Still... this could actually be very good. If it's enough incentive, it'll mean binary drivers will become smaller and smaller as more of what they do is done by the kernel/OSS driver pieces. From waht I understand, it's not that AMD and NVIDIA don't want to open-source their drivers, it's that they can't now that they've made them under NDAs, etc., and there's not enough incentive to make completely new free software ones. Well, here's your incentive, and it's a gradual transition to boot.

frankieboy · 2009-04-12 05:55:08

Hi!

Could anybody help me enabling KMS?
I've a compaq 6720s laptop with intel 965 GME/GLE integrated graphic chipset, I've read all guides, but if I enable kms, I get a drm error: connectors have no modes, using standard modes, nothing happens, and x won't start even if uxa is enabled, Without kms enabled, x works, with uxa enabled. I've tried without xorg.conf, but it doesn't work if kms is enabled. My boot parameters are: notsc, enable_mtrr_cleanups, nopat, I've tried adding i915.modeprobe=1 and modified modprobe.conf, mkinitcpio.conf, generated a new image, but there's no resolution switching while booting.
Any help appreciated.

Thx

Frankieboy

Liquen · 2009-04-12 07:23:36

airmind wrote:

Hi, I'm using KMS with xorg-server 1.6 and it's working great (the console switching is beautiful). But I'm having some speed issues with Compiz, it is running slowly. I'm using the UXA acceleration mode with the Intel driver.
Any reason it is running slower then before? Anything I can do to fix it?

Same here. The best video performance I ever got was with kernel 2.6.28 + xorg 1.6 + UXA. Kernel 2.6.29 slowed things down. Any help appreciated.

Wilco · 2009-04-12 08:14:34

airmind wrote:

Hi, I'm using KMS with xorg-server 1.6 and it's working great (the console switching is beautiful). But I'm having some speed issues with Compiz, it is running slowly. I'm using the UXA acceleration mode with the Intel driver.
Any reason it is running slower then before? Anything I can do to fix it?

Same problems here, only with urxvt which is hella slow now.

bender02 · 2009-04-12 16:03:15

Wilco wrote:

Same problems here, only with urxvt which is hella slow now.

I had that as well. To my surprise, switching the fonts to their xft version mostly solved the problem.

peart · 2009-04-12 19:12:24

bender02 wrote:

Wilco wrote:
Same problems here, only with urxvt which is hella slow now.
I had that as well. To my surprise, switching the fonts to their xft version mostly solved the problem.

Urxvt is real slow here too, but not with text (I used the fixed font). In my case, it's ncurses apps that draw slowly. For example, when I run make menuconfig in hte kernel sources, it takes a good 3 or 4 seconds for the blue/gray screen to draw itself.

I found this bug report which I hope will lead to a fix. However, my problem is slightly different. It also happens in xterm, and like I said before, the drawing of text does not seem affected, only ncurses stuff.

bender02 · 2009-04-12 19:19:35

@peart: I didn't have the problem in xterm, and with xft font in urxvt all apps (also ncurses) except alsamixer are fast now.
One more thing which might not have anything to do with this is that I have "Option Legacy3D False" in xorg.conf in the Device section.

kaola_linux · 2009-04-12 19:41:06

Just tried this on my Acer Aspire One with an intel gma 950. It's working fine but I don't seem to gain any improvements or any performance difference...

peart · 2009-04-12 20:12:17

bender02 wrote:

@peart: I didn't have the problem in xterm, and with xft font in urxvt all apps (also ncurses) except alsamixer are fast now.
One more thing which might not have anything to do with this is that I have "Option Legacy3D False" in xorg.conf in the Device section.

Hey bender02,

I just tried urxvt with an xft font and you are right. "make menuconfig" now draws at a normal speed, but alsamixer is still a bit on the slow side (but much faster than before). Still, I've been using the fixed font for so long I'm not sure I can get used to anything else! I'll just wait for a fix. I don't recompile my kernel or change my alsa settings every day

patroclo7 · 2009-04-12 20:44:37

Besides the slowness in xterm, I have problems in switching to the console: if I use ctrl+alt+F1 I continue to see what the X server was displaying in different colors. If I now try ctrl+alt+F2 I get again different colors for the same stuff. When I change back to X everything seems normal... It is a pity also because faster switching to the colsole would be the main advantage of kms from a user perspective.

Last edited by patroclo7 (2009-04-12 20:45:08)

b9anders · 2009-04-13 06:25:18

Works fine here, except it fails to detect the proper screen resolution.

Gives me a 1024x768 display, rather than a 1280x800 one.

Any way to change this behaviour?

kaola_linux · 2009-04-13 06:53:30

patroclo7 wrote:

Besides the slowness in xterm, I have problems in switching to the console: if I use ctrl+alt+F1 I continue to see what the X server was displaying in different colors. If I now try ctrl+alt+F2 I get again different colors for the same stuff. When I change back to X everything seems normal... It is a pity also because faster switching to the colsole would be the main advantage of kms from a user perspective.

Switching to a virtual console is fast on my netbook with kms enabled, I like it's speed upon switching...:) I have no xorg.conf. Are you not using a xorg.conf as well?

Does 2.6.28 kernel faster than the .29 when kms is enabled?

Last edited by kaola_linux (2009-04-13 06:54:35)

Wilco · 2009-04-13 08:26:45

bender02 wrote:

Wilco wrote:
Same problems here, only with urxvt which is hella slow now.
I had that as well. To my surprise, switching the fonts to their xft version mostly solved the problem.

Thanks that worked well! For me it's stable, and fast but performance of glxgears has somewhat decreased (I know, not a benchmark)

schuay · 2009-04-13 09:25:14

i used the late method ( modprobe.conf options, loading modules in rc.conf ) and it works while in runlevel 3, but as soon as execute startx, the screen flickers once and then hangs on a blank screen with a non-blinking cursor and i need to do a hard reboot.
using an acer aspire one 150L ..

edit: nevermind! i still had a polluted xorg.conf. deleted xorg.conf, everything works fine now

Last edited by schuay (2009-04-13 09:29:48)

Aktau · 2009-04-13 10:29:22

peart wrote:

bender02 wrote:
Wilco wrote:
Same problems here, only with urxvt which is hella slow now.
I had that as well. To my surprise, switching the fonts to their xft version mostly solved the problem.
Urxvt is real slow here too, but not with text (I used the fixed font). In my case, it's ncurses apps that draw slowly. For example, when I run make menuconfig in hte kernel sources, it takes a good 3 or 4 seconds for the blue/gray screen to draw itself.
I found this bug report which I hope will lead to a fix. However, my problem is slightly different. It also happens in xterm, and like I said before, the drawing of text does not seem affected, only ncurses stuff.

To all the people with xterm/urxvt issues, I also have slow redrawing issues, and some others. My situation:

- Hardware/sofware: intel 915, with Xorg 1.6 / KMS / DRI2 / UXA / Kernel .29 / Intel 2.6

- urxvt:
-- really slow redrawing (indeed seems to be ncurses apps)
-- normal memory usage

- xterm:
-- fast redrawing (same as ever)
-- ridiculously high memory usage (~100 MB per xterm)

This was ofcourse with my .Xdefault's, which is based on Gigamo's ( http://github.com/gigamo/dotfiles/tree/master ). I tried turning off .Xdefaults and what do you know: xterm's memory usage reduced BUT it started to draw really slowly. So I turned on my .Xdefaults again and just chose between urxvt and xterm depending on whether I wanted speed or low memory usage (what a standard trade-off ).

However, a very helpful user on the [testing] forum has suggested that I try a compositing manager (xcompmgr in my case because I use Awesome). This mostly abates the speed problems in urxvt. It's not up to par with the old level, but it's at least bearable.

I have no idea why turning on a compositing manager even works, because I explicitly disabled anything relating to transparancy in my .Xdefault. I guess I'll have to wait until a linux guru truly encounters this problem _or_ someone fixes the code (accidentally).

SomeGuyDude · 2009-04-13 18:07:39

Did this with my 950GM card. GLXgears shows ~320fps, but Compiz is sloooooooooooooow, and the transparency is screwy.

airmind · 2009-04-13 18:23:16

SomeGuyDude wrote:

Did this with my 950GM card. GLXgears shows ~320fps, but Compiz is sloooooooooooooow, and the transparency is screwy.

The transparency issue is with UXA and there is no fix currently. And GLXgears is giving me about 300fpx too, but that is pretty useless in this situation.

sctincman · 2009-04-13 18:50:40

airmind wrote:

The transparency issue is with UXA and there is no fix currently. And GLXgears is giving me about 300fpx too, but that is pretty useless in this situation.

Really? I'm trying out compositioning in xfce with KMS and X hotplugging (UXA by default, right?) and the transparency is working well; no slow down on my part.

Last edited by sctincman (2009-04-13 18:54:34)

aualin · 2009-04-13 19:23:02

b9anders wrote:

Works fine here, except it fails to detect the proper screen resolution.
Gives me a 1024x768 display, rather than a 1280x800 one.
Any way to change this behaviour?

I got the same problem here.

SomeGuyDude · 2009-04-13 19:46:26

sctincman wrote:

airmind wrote:
The transparency issue is with UXA and there is no fix currently. And GLXgears is giving me about 300fpx too, but that is pretty useless in this situation.
Really? I'm trying out compositioning in xfce with KMS and X hotplugging (UXA by default, right?) and the transparency is working well; no slow down on my part.

What card do you have? I'm wondering if it's because I used the i915 deal with a 950GM card.

sctincman · 2009-04-13 20:21:23

whoops, that would have been important to mention :* a GM45 here so a bit newer. Perhaps this is the reason behind the dissparities between performance impacts? (have seen a lot of people say it decreased, but some saying it increased performance)

b9anders · 2009-04-13 22:21:20

with kms enabled, xorg takes up a whopping 420+ MB here. Is that par for the course for this?

Arch Linux

#26 2009-04-11 21:06:25

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#27 2009-04-12 00:13:11

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#28 2009-04-12 00:16:21

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#29 2009-04-12 03:42:24

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#30 2009-04-12 05:55:08

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#31 2009-04-12 07:23:36

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#32 2009-04-12 08:14:34

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#33 2009-04-12 16:03:15

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#34 2009-04-12 19:12:24

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#35 2009-04-12 19:19:35

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#36 2009-04-12 19:41:06

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#37 2009-04-12 20:12:17

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#38 2009-04-12 20:44:37

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#39 2009-04-13 06:25:18

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#40 2009-04-13 06:53:30

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#41 2009-04-13 08:26:45

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#42 2009-04-13 09:25:14

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#43 2009-04-13 10:29:22

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#44 2009-04-13 18:07:39

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#45 2009-04-13 18:23:16

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#46 2009-04-13 18:50:40

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#47 2009-04-13 19:23:02

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#48 2009-04-13 19:46:26

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#49 2009-04-13 20:21:23

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

#50 2009-04-13 22:21:20

Re: HOWTO: Enable KMS with the stock 2.6.29-ARCH kernel

Board footer