An Updated ATI Kernel Mode-Setting Driver

[Ant P.]

Hmm, I've just installed all the KMS bits for R200 and it doesn't seem to be working.

I get a framebuffer console that works fine...

~ $ dmesg | grep modesetting
[    2.199528] [drm] radeon default to kernel modesetting.
[    2.199606] [drm] radeon kernel modesetting enabled.

But when I go to start X I get the old monitor on-off-on flicker and this:

~ $ grep -i KMS /var/log/Xorg.0.log
(II) [KMS] drm report modesetting isn't supported.

And just to rub it in I seem to have no HW accel at all, I'm getting 1-second lags just moving the mouse over buttons.

(btw this is about the 5th time in a row I've had my xmodmap settings broken by an X11 upgrade, what gives?)

[Louise]

(btw this is about the 5th time in a row I've had my xmodmap settings broken by an X11 upgrade, what gives?)

Maybe this can help?

http://forums.fedoraforum.org/showthread.php?t=224444

[Ant P.]

Maybe this can help?

http://forums.fedoraforum.org/showthread.php?t=224444

Thanks for that, I didn't think of using "clear Lock" there, will try that. (edit: nope, still screwy...)

This was all I had in my .xmodmap file:

remove Lock = Caps_Lock
keysym Caps_Lock = Escape

I seem to have terrible luck with keyboard things in X... this time it broke all my modifier keys, last time the keyboard stopped responding if I had xmodmap in my xinitrc, and the first time I used evdev years ago the keys were pretty much randomised...

[bridgman]

If my memory is right, they are working on a 2.6.28 kernel, and, when they are ready, they port it to the latest kernel. 2.6.28 is the version most users are running

That's what was happening for the 6xx/7xx 3d drm support, but I think glisse was using a more recent kernel for his work, probably an earlier 2.6.31 since that's where KMS first merged upstream.

[highlandsun]

Jerome's initial r6xx/r7xx KMS support patch is here:
http://people.freedesktop.org/~gliss...x-chipse.patch

That says it provides no hardware acceleration. Aside from testing purposes or curiosity, why would someone else want to use this patch? Without EXA and XV things would be pretty unbearable... The 1680x1050 screen on my laptop means a lot of pixels to shove around using just the CPU.

(Just trying to talk myself into/out of applying the patch to my 2.6.31-rc5 tree......)

[highlandsun]

It applied OK on top of my 2.6.31-rc6 tree. There was one already-applied patch (adding the RS880 pciid) which I ignored. Now to see if it actually does anything useful...

edit: after I rebuilt libdrm with --enable-radeon-experimental-api and rebuilt xf86-video-ati, X started working. But, like the patch says, no acceleration of any kind. No Xv, no EXA.

And a warning - it appears that after you've loaded the radeon kernel module once, it's not safe to load it again with modesetting enabled. I was able to unload it and reload it with modeset=0, which I needed to do a few times because I didn't have all the KMS pieces in place. But the next time I tried to unload and reload it (with modesetting active) I just got a blank screen and everything was hung, no SysRq or anything...

[nanonyme]

That says it provides no hardware acceleration. Aside from testing purposes or curiosity, why would someone else want to use this patch?

Not all patches are meant for end-users, some are actually just parts of the development process.

[agd5f]

And a warning - it appears that after you've loaded the radeon kernel module once, it's not safe to load it again with modesetting enabled. I was able to unload it and reload it with modeset=0, which I needed to do a few times because I didn't have all the KMS pieces in place. But the next time I tried to unload and reload it (with modesetting active) I just got a blank screen and everything was hung, no SysRq or anything...

You need to unbind the console from the fb device, e.g.,
echo 0 > /sys/class/vtconsole/vtcon1/bind
You will lose your console however, so best to do this from a second PC over ssh.

[highlandsun]

Not all patches are meant for end-users, some are actually just parts of the development process.

Understood. But usually, developers share patches with each other by directly pulling from each other's git repos. Since this was made available as a standalone patch, it seemed to be aimed at a slightly wider audience.

Anyway, after running it for a short period of time my system started to slow down. dmesg showed that it was being flooded with messages:

Aug 13 21:23:30 violino kernel: [ 740.664131] [drm] Emit age: 26591 (Current: 26586)
Aug 13 21:23:30 violino kernel: [ 740.664131] [drm] Emit age: 26592 (Current: 26586)
Aug 13 21:23:30 violino kernel: [ 740.664131] [drm] Emit age: 26593 (Current: 26586)

it was pegging klogd... So I've gone back to no KMS, which is better anyway since it has acceleration...

[Xavier]

Hi,

There is very little compatibility between the open and Catalyst driver internals. The Catalyst drivers have had a high performance kernel memory manager for a number of years, with similar capabilities to GEM/TTM plus a few years of performance tuning, and bringing that memory manager into fglrx was one part of the new 3D stack we released back in September 07.

The memory manager is tightly integrated with both the 3D drivers and the low-level GPU management across all OSes, so switching to GEM/TTM is not a practical option.

So, why hasn't that wonderful memory manager been used in the OSS radeon driver, instead of TTM ?