[arch-general] KMS again with 2.6.33?
I was wondering whether KMS would officially return with 2.6.33 since a lot of fixes have gone into it? Obviously there will be a lengthy testing series first. Is it currently planned to try KMS again with 2.6.33? -- Sven-Hendrik
Am Samstag 06 Februar 2010 schrieb Sven-Hendrik Haase:
I was wondering whether KMS would officially return with 2.6.33 since a lot of fixes have gone into it? Obviously there will be a lengthy testing series first. Is it currently planned to try KMS again with 2.6.33?
-- Sven-Hendrik You can still use kms, depends on your card but we have full support for it right now. greetings tpowa
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 06.02.2010 12:03, Tobias Powalowski wrote:
Am Samstag 06 Februar 2010 schrieb Sven-Hendrik Haase:
I was wondering whether KMS would officially return with 2.6.33 since a lot of fixes have gone into it? Obviously there will be a lengthy testing series first. Is it currently planned to try KMS again with 2.6.33?
-- Sven-Hendrik
You can still use kms, depends on your card but we have full support for it right now. greetings tpowa
As it stands, it requires recompiling the whole stack to enable DRI2 acceleration as well as using AUR packages. While this obviously is supported by the packages, I don't consider it "officially supported by Arch". Even the wiki says so. I'm talking about real official Arch support with supported packages now that KMS drivers are out of staging. -- Sven-Hendrik
Am Samstag 06 Februar 2010 schrieb Sven-Hendrik Haase:
On 06.02.2010 12:03, Tobias Powalowski wrote:
Am Samstag 06 Februar 2010 schrieb Sven-Hendrik Haase:
I was wondering whether KMS would officially return with 2.6.33 since a lot of fixes have gone into it? Obviously there will be a lengthy testing series first. Is it currently planned to try KMS again with 2.6.33?
-- Sven-Hendrik
You can still use kms, depends on your card but we have full support for it right now. greetings tpowa
As it stands, it requires recompiling the whole stack to enable DRI2 acceleration as well as using AUR packages. While this obviously is supported by the packages, I don't consider it "officially supported by Arch". Even the wiki says so. I'm talking about real official Arch support with supported packages now that KMS drivers are out of staging.
-- Sven-Hendrik It will be supported as .33 will ship kms. Right now .32 supports kms for ati and intel cards, nouveau is optional.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sat, Feb 6, 2010 at 12:56 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
It will be supported as .33 will ship kms. Right now .32 supports kms for ati and intel cards, nouveau is optional.
It seems the question was not only about kms but also about dri2, which is needed to get 3d support with kms. About nouveau, ums was dropped from ddx on 11th January and extra/xf86-video-nouveau package is from 17th January. So the only option is to use kms, which should also be enabled by default now.
On Mon, 2010-02-08 at 18:52 +0100, Xavier Chantry wrote:
It seems the question was not only about kms but also about dri2, which is needed to get 3d support with kms.
About nouveau, ums was dropped from ddx on 11th January and extra/xf86-video-nouveau package is from 17th January. So the only option is to use kms, which should also be enabled by default now.
Which means autoloading of nouveau modules by udev, which means breaking the nvidia drivers for everyone not blacklisting it. This is going to be so much fun... especially now nouveau was merged in the staging tree.
On Tue, Feb 9, 2010 at 12:50 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Mon, 2010-02-08 at 18:52 +0100, Xavier Chantry wrote:
It seems the question was not only about kms but also about dri2, which is needed to get 3d support with kms.
About nouveau, ums was dropped from ddx on 11th January and extra/xf86-video-nouveau package is from 17th January. So the only option is to use kms, which should also be enabled by default now.
Which means autoloading of nouveau modules by udev, which means breaking the nvidia drivers for everyone not blacklisting it.
This is going to be so much fun... especially now nouveau was merged in the staging tree.
That's true, but the conflict goes both way. And the situation isn't different with ati vs fglrx, is it ? Anyway, there is no reason to enable nouveau in the kernel, the current out-of-tree build is just fine and allows for more frequent updates. As long as users still have to install it explicitly, they should be able to handle this conflict. But it would indeed be more problematic if we wanted to have it directly in the kernel package.
On Tue, 2010-02-09 at 01:20 +0100, Xavier Chantry wrote:
That's true, but the conflict goes both way. And the situation isn't different with ati vs fglrx, is it ?
Anyway, there is no reason to enable nouveau in the kernel, the current out-of-tree build is just fine and allows for more frequent updates. As long as users still have to install it explicitly, they should be able to handle this conflict. But it would indeed be more problematic if we wanted to have it directly in the kernel package.
The point is that it moved to the staging tree now, where further development will take place. After a while, there won't be an out-of-tree version anymore because all development happens in the official kernel git tree. An example of this is intel: there's several kernel trees around with intel drivers, but no possible way to build intel drm out of tree.
On Tue, Feb 9, 2010 at 9:00 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
The point is that it moved to the staging tree now, where further development will take place. After a while, there won't be an out-of-tree version anymore because all development happens in the official kernel git tree. An example of this is intel: there's several kernel trees around with intel drivers, but no possible way to build intel drm out of tree.
All development happens in that git tree : http://cgit.freedesktop.org/nouveau/linux-2.6/ This is then merged to drm-next and then to linus tree. If you just fetch that, you indeed cannot do an out-of-build tree, you have to build the whole kernel. But it's possible to write a Makefile that makes it possible : http://cgit.freedesktop.org/nouveau/linux-2.6/plain/nouveau/Makefile?h=maste... This Makefile allows to only build the relevant drm/nouveau code, and apparently also to create an archive of it. I don't see why this should stop being possible, and why it would not be possible to do the same with other drivers.
participants (4)
-
Jan de Groot
-
Sven-Hendrik Haase
-
Tobias Powalowski
-
Xavier Chantry