[arch-general] Xorg changes / DRM modules
I've updated the git packages for nouveau and ati ddx driver packages in testing. I also updated the nouveau-drm package. This required to add the new nouveau-firmware package. It will be also needed to use kernel nouveau-drm module that will be introduced with kernel 2.6.33. I will keep updating the separate nouveua-drm module for a while to get features and fixes faster than in Linus tree. The firmware will probably also result in loading issues in early kms mode. We might think about recommending late mode for now. libdrm has been updated to 2.4.17 - this is breaking all radeon 3d stuff and will require changes in MESA when I understand the upstream devs right. Mesa7.7 is expected in a few days anyways and should make Radeon 3d stuff working again after a few late commits (7.7rc4 doesn't build with new libdrm). Other drivers should still work. Please test them. Radeon kms is still buggy like hell and unusable for my RC410 [Radeon Xpress 200M] card. It makes X and the whole system freeze instantly when moving windows around or when I try to start 3d apps. Sometimes even at Xorg start at all. This has been introduced with 2.6.32 kernels. Upstream recommends to try the various drm trees: http://article.gmane.org/gmane.comp.video.dri.devel/40626 Any opinions from other ati users what branch is the most stable and useful these days? I'm thinking about adding a radeon-drm kernel module package to solve the tons of speed and stability issues. As already written on the closed devel list, I'd like to get help for these packages from other devs and community members. Whoever is well informed in Xorg/kernel drm development and wants to help to stabilize our drivers please contact me. -Andy
On Mon, Dec 21, 2009 at 11:35:12PM +0100, Andreas Radke wrote:
libdrm has been updated to 2.4.17 - this is breaking all radeon 3d stuff and will require changes in MESA when I understand the upstream devs right. Mesa7.7 is expected in a few days anyways and should make Radeon 3d stuff working again after a few late commits (7.7rc4 doesn't build with new libdrm). Other drivers should still work. Please test them.
Radeon kms is still buggy like hell and unusable for my RC410 [Radeon Xpress 200M] card. It makes X and the whole system freeze instantly when moving windows around or when I try to start 3d apps. Sometimes even at Xorg start at all. This has been introduced with 2.6.32 kernels. Upstream recommends to try the various drm trees:
http://article.gmane.org/gmane.comp.video.dri.devel/40626
Any opinions from other ati users what branch is the most stable and useful these days? I'm thinking about adding a radeon-drm kernel module package to solve the tons of speed and stability issues.
As already written on the closed devel list, I'd like to get help for these packages from other devs and community members. Whoever is well informed in Xorg/kernel drm development and wants to help to stabilize our drivers please contact me.
-Andy
I'm not an expert but I will share my experience anyway. I follow drm-radeon-testing branch but I think drm-radeon-next is considered more stable for official packaging. Is shipping an updated radeon module enough though? I don't think It will work without all the new drm code. The KMS code is starting to heavily depend on irq which didn't exist when 2..6.32 was released. With newer code you will need the ucode firmware(1). 2.6.32.2 was bugged because of a patch that assumed the existence of irq. IMHO, Encouraging people to dasable KMS on official packages is more sane for now. Those who need the latest and greatest should do it on their own. (1) http://aur.archlinux.org/packages.php?ID=33016
Am Tue, 22 Dec 2009 01:17:23 +0200 schrieb Nezmer@allurelinux.org:
IMHO, Encouraging people to dasable KMS on official packages is more sane for now. Those who need the latest and greatest should do it on their own.
Please, don't make too many experiments in the stable repos and keep the packages in the repos as close to the "stable" upstream releases as possible. I don't think that having a git version in the repo is a good idea anyway. I can imagine that upstream already knows about the problems and is already working on it. I agree with Nezmer that people who want the latest unstable packages should build them on their own from AUR. If an official package completely doesn't work then I think downgrading it to the latest working version is better than upgrading it to an unstable version. Greetings, Heiko
Am Tue, 22 Dec 2009 00:46:29 +0100 schrieb Heiko Baums <lists@baums-on-web.de>:
Please, don't make too many experiments in the stable repos and keep the packages in the repos as close to the "stable" upstream releases as possible. I don't think that having a git version in the repo is a good idea anyway.
We would also like to do this. Would mean much less work for us. New kernel brings changes in drm modules. Xorg ddx driver updates require new kernel modules and sometimes even more recent stuff. There's new mesa out now. And upstream devs work hard on the kmd-drm-gallium switch for the future. Sadly not all part move at the same time and distributions have to decide whether to package old stuff that isn't supported upstream anymore or more recent and sadly buggy stuff. We will try to fix all known issues in testing before we move stuff to core/extra. -Andy
On 12/22/2009 01:59 PM, Andreas Radke wrote:
Am Tue, 22 Dec 2009 00:46:29 +0100 schrieb Heiko Baums<lists@baums-on-web.de>:
Please, don't make too many experiments in the stable repos and keep the packages in the repos as close to the "stable" upstream releases as possible. I don't think that having a git version in the repo is a good idea anyway.
We would also like to do this. Would mean much less work for us.
New kernel brings changes in drm modules. Xorg ddx driver updates require new kernel modules and sometimes even more recent stuff. There's new mesa out now. And upstream devs work hard on the kmd-drm-gallium switch for the future.
Sadly not all part move at the same time and distributions have to decide whether to package old stuff that isn't supported upstream anymore or more recent and sadly buggy stuff.
We will try to fix all known issues in testing before we move stuff to core/extra.
-Andy
also we have to know what issue exists and that's require testing from you guys. don't forget that downgrading is not a solution and all issue should be submitted to bugtracker. this is the only way to let us know about that. -- Ionut
At Dienstag, 22. Dezember 2009 12:59 Andreas Radke wrote:
We would also like to do this. Would mean much less work for us.
i can understand this reason but please don't forget if something goes wrong than everybody includes you have more work as with seperate *-git packages.
Sadly not all part move at the same time and distributions have to decide whether to package old stuff that isn't supported upstream anymore or more recent and sadly buggy stuff.
Sorry, this is an option for a private repo but not for a distribution from my view. Again, i can understand you and your problems but if mainstream stops offering stable versions and offers only git version than this is the mistake of the mainstream and must not be repeated by us. I would not have a problem with waiting until mainstream have all under controll and offers a stable solution.
We will try to fix all known issues in testing before we move stuff to core/extra.
I believe that you and the other arch devs will gives all. Thanks for this work. See you, Attila
participants (5)
-
Andreas Radke
-
Attila
-
Heiko Baums
-
Ionut Biru
-
Nezmerï¼ allurelinux.org