Kernel Mode-Setting Push For Linux 2.6.29 Kernel

[phoronix]

Phoronix: Kernel Mode-Setting Push For Linux 2.6.29 Kernel

David Airlie has just called upon Linus Torvalds to pull the kernel mode-setting framework and Intel KMS driver support into the Linux 2.6.29 kernel. If you're a faithful Phoronix reader this shouldn't come as a surprise since Intel, Red Hat, and others have been busy hacking away at kernel mode-setting to get it ready to merge. The core kernel mode-setting code will now be in the next mainline kernel release along with the Intel i915 KMS driver, but the kernel must be built with the CONFIG_DRM_I915_KMS option since KMS isn't yet enabled by default...

http://www.phoronix.com/vr.php?view=Njk2MA

[hobbes]

What are the real odds of ATI pulling GEM-like support within the next three months?

I'm just asking for a educated guess.

Thanks for reading.

[bugmenot]

What is the schedule now?
Do radeon developers add changes to GEM, so that even radeon cards runs with GEM quite well and not only intel devices?

And if they do so, what is with radeonhd? Can they use the (extended/adjusted) GEM as well as radeon?

Thanks.

[smitty3268]

I'm also curious about radeonhd support - is KMS something that can be easily ported between the two? It seems like most of the differences between radeon and radeonhd are in the hardware initialization, which I assume is what would go into the kernel. Are there any plans to just use the same code in the kernel, and if so would radeonhd just go away or are there other significant differences?

[TechMage89]

There aren't really substantial differences, so when kms becomes mainstream, radeonhd will likely fade away.

As for GEM support, neither radeon nor radeonhd makes real use of it yet (the only real use in the Xorg driver is for UXA acceleration, which hasn't been implemented for anything except intel yet). I'm not sure of the status of GEM support in Mesa, although I believe it is used for Intel, at least.

[sabriah]

Originally Posted by hobbes

What are the real odds of ATI pulling GEM-like support within the next three months?

I'm just asking for a educated guess.

Thanks for reading.

It is about 3 to 7.

[AliBaba]

...CONFIG_DRM_I915_KMS option since KMS isn't yet enabled by default

Well, nice to see, that kms+intel finally seems to be ready. I'm tracking development for a few weeks now and repositories have been very busy, which is great to see.

Hardware: GMA X4500, GM45.
Software:

• kernel: master + airlie's drm-next
• mesa, drm: master
• xorg: master
• video-intel: master

I got UXA running, but using "i915 modeset=1" produces a black screen at start of GDM and forces me to do a SysRq reboot. I can nevertheless report that the freezes using Compiz are finally gone with UXA.

Edit: Btw, I build video-intel with the kms-switch.

[val-gaav]

Originally Posted by hobbes

What are the real odds of ATI pulling GEM-like support within the next three months?

It would be quite dissapointing if kms/gem for radeon didn't make it into 2.6.30 ...

It's 3 months to get there but it's half year for a stable kernel with it... Some people don't want to use/compile RCs. And kernel is quite crucial part of the system so it does make sense to not use RCs.

[AliBaba]

Originally Posted by val-gaav

And kernel is quite crucial part of the system so it does make sense to not use RCs.

Not exactly, no.

Every distribution I know lets you install several kernels side-by-side enabling you to fall back to a working configuration. I use 2.6.27, 2.6.28-rc* (and now 2.6.28) the Debian way (make-kpkg) and I can remove or add any kernel I build easily.

There's by the way not even a reason to not use RCs at all if you are not affected by a _very_ serious bug (e1000 :-). The difference between a kernel with drm-next pulled by Linus or one where I merge Dave Airlie's branch myself (and maybe get all bugfixes before they land in Linus' kernel) does not exist, imho.


My three cents, btw...

[val-gaav]

The e1000 bug was quite serious. I think that example proves my point. Sure you can have a stable kernel and a RC on the same distro, but the stable one will not fix the hardware that RC broke.

That said distros don't usually package kernel RCs, and not everyone wants to compile his kernel and repeat the process with every new RC (2 week time), and some users may not want to compile their own kernel at all