4:43 p.m.
It seems ati drivers are stalled in testing?
I'm thinking of building a new home media server, and wondering what to put in
it. I was thinking amd is now more linux friendly, and would be a good
choice. The fact that the driver seems stalled in rpmfusion worries me.
1:12 p.m.
On 1/29/09 11:43 AM, Neal Becker wrote:
It seems ati drivers are stalled in testing?
I'm thinking of building a new home media server, and wondering what to put in
it. I was thinking amd is now more linux friendly, and would be a good
choice. The fact that the driver seems stalled in rpmfusion worries me.
It's not stalled, but it won't work without manual user interaction
(regeneration of initrd images) so we're keeping it there for now. I'm going
to test 9-1 this weekend and see what's improved (or what hasn't :/)
Stewart
1:51 p.m.
2009/1/30 Stewart Adam <maillist(a)diffingo.com>:
On 1/29/09 11:43 AM, Neal Becker wrote:
>
> It seems ati drivers are stalled in testing?
>
> I'm thinking of building a new home media server, and wondering what to
> put in
> it. I was thinking amd is now more linux friendly, and would be a good
> choice. The fact that the driver seems stalled in rpmfusion worries me.
>
It's not stalled, but it won't work without manual user interaction
Because
you have removed the blacklist-radeon scripts !!!
On hardware where radeon is "working" (or at least ,radeon detects the
hardware).
the plymouth boot have made the radeon drm loading within the kernel image.
For that reason the initrd needs to be regenerated: (without radeon.ko
and drm.ko in it)
(using mkinitrd -f /boot/initrd$(uname -r).img $(uname -r)
That's been said with the 8.12 release, there is a need for a
workaround for the nodes creation
/etc/udev/makedev.d/40-fgrlx-dri.nodes:
dri/card0
dri/card1
dri/card2
dri/card3
I think this file is created once the fglrx driver is loaded. which
means that we have a circle dependency, because we need to regenerate
the kernel image without the radeon loaded to have fglrx to "load",
but regenerate again to have the script included in the initrd image
to have fglrx to "work".
(This seems needed : "On special Hardware (TM)" )
If we have the files hardcoded we could avoid this very annoying steps
but it will make the switch fro driver to another more difficult.
That's not the way we want.
So a more interesting way would be to have another experimental
package, named fglrx-bootstrap (or else)
that will bundle theses scripts in an hardcoded way (still they could
be edited by r-c-d) and have the initrd image regenerated
accordingly...
But for now the switch remains messy... (and isn't meant to be fixable easily)
(regeneration of initrd images) so we're keeping it there for
now. I'm going
to test 9-1 this weekend and see what's improved (or what hasn't :/)
I've already uploaded the new ATI 9.1 binary driver, will do some
investagation for few time right now.
Nicolas (kwizart)
6:37 a.m.
On 1/30/09 8:51 AM, Nicolas Chauvet wrote:
2009/1/30 Stewart Adam<maillist(a)diffingo.com>:
> On 1/29/09 11:43 AM, Neal Becker wrote:
>> It seems ati drivers are stalled in testing?
>>
>> I'm thinking of building a new home media server, and wondering what to
>> put in
>> it. I was thinking amd is now more linux friendly, and would be a good
>> choice. The fact that the driver seems stalled in rpmfusion worries me.
>>
> It's not stalled, but it won't work without manual user interaction
Because you have removed the blacklist-radeon scripts !!!
I'm not sure what you
mean by scripts... Do you mean the blacklist file +
udev node config file?
On hardware where radeon is "working" (or at least ,radeon
detects the
hardware).
the plymouth boot have made the radeon drm loading within the kernel image.
For that reason the initrd needs to be regenerated: (without radeon.ko
and drm.ko in it)
(using mkinitrd -f /boot/initrd$(uname -r).img $(uname -r)
That's been said with the 8.12 release, there is a need for a
workaround for the nodes creation
/etc/udev/makedev.d/40-fgrlx-dri.nodes:
dri/card0
dri/card1
dri/card2
dri/card3
All that's been done already on the package in updates-testing,
it's been
available for a while now.
If we have the files hardcoded we could avoid this very annoying
steps
but it will make the switch fro driver to another more difficult.
That's not the way we want.
So a more interesting way would be to have another experimental
package, named fglrx-bootstrap (or else)
that will bundle theses scripts in an hardcoded way (still they could
be edited by r-c-d) and have the initrd image regenerated
accordingly...
But for now the switch remains messy... (and isn't meant to be fixable easily)
There's no point in duplicating our work - rpmfusion-config-display already
does all that. I'm going to update the review tomorrow with version 0.3
which has a bugfix for the blacklist file (I forgot to prefix all module
names with the "blacklist" keyword) and it also adds --initrd-regen-hack /
--undo-initrd-regen-hack which will make it extremely easy for users to switch:
# rpmfusion-config-display --enable
# rpmfusion-config-display --initrd-regen-hack
and:
# rpmfusion-config-display --disable
# rpmfusion-config-display --undo-initrd-regen-hack
> (regeneration of initrd images) so we're keeping it there for
now. I'm going
> to test 9-1 this weekend and see what's improved (or what hasn't :/)
I've already uploaded the new ATI 9.1 binary driver, will do some
investagation for few time right now.
I just finished testing on my machine, here
are the results:
* Catalyst 9-1 works much better, both performance and stability-wise.
* fglrx_dri.so is now working with multilib again and both a 32bit and 64bit
version is required if you want to use i386 programs such as Wine - Seeing
as such, I've moved it back into -libs.
* udev and blacklist hacks are still required, although vga=0xXYZ can be
used to get a plymouth boot screen without KMS while the fglrx driver is enabled
I've submitted builds for devel and F-10, I expect that the kmod on devel
will fail (there were major changes to the ACPI code in 2.6.29 and no
patches are readily available yet) but F-10 should be working fine as long
as you're using 2.6.27 or 2.6.28 kernels.
Regards,
Stewart
1:50 p.m.
On Saturday, 31 January 2009 at 07:37, Stewart Adam wrote:
[...]
I just finished testing on my machine, here are the results:
* Catalyst 9-1 works much better, both performance and stability-wise.
That's great news.
[...]
I've submitted builds for devel and F-10, I expect that the kmod
on devel
will fail (there were major changes to the ACPI code in 2.6.29 and no
patches are readily available yet) but F-10 should be working fine as long
as you're using 2.6.27 or 2.6.28 kernels.
Can I please have an F-9 build as well?
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:04 p.m.
On 1/31/09 8:50 AM, Dominik 'Rathann' Mierzejewski wrote:
On Saturday, 31 January 2009 at 07:37, Stewart Adam wrote:
<snip>
> I've submitted builds for devel and F-10, I expect that the
kmod on devel
> will fail (there were major changes to the ACPI code in 2.6.29 and no
> patches are readily available yet) but F-10 should be working fine as long
> as you're using 2.6.27 or 2.6.28 kernels.
Can I please have an F-9 build as well?
Done - Building now as jobs 2635 and 2636.
Let me know if they work well for
you, I don't have any F-9 machines with ATI hardware at the moment...
Stewart
12:11 p.m.
On Saturday, 31 January 2009 at 18:04, Stewart Adam wrote:
On 1/31/09 8:50 AM, Dominik 'Rathann' Mierzejewski wrote:
>On Saturday, 31 January 2009 at 07:37, Stewart Adam wrote:
<snip>
>>I've submitted builds for devel and F-10, I expect that the kmod on devel
>>will fail (there were major changes to the ACPI code in 2.6.29 and no
>>patches are readily available yet) but F-10 should be working fine as long
>>as you're using 2.6.27 or 2.6.28 kernels.
>
>Can I please have an F-9 build as well?
Done - Building now as jobs 2635 and 2636. Let me know if they work well
for you, I don't have any F-9 machines with ATI hardware at the moment...
I only tested glxgears and fgl_glxgears last night and they worked fine.
I'll try running some 3D games tonight.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5569
days inactive
5573
days old
rpmfusion-developers@lists.rpmfusion.org
6 comments
4 participants
participants (4)
-
Dominik 'Rathann' Mierzejewski -
Neal Becker -
Nicolas Chauvet -
Stewart Adam