--- Comment #38 from Stewart Adam <s.adam(a)diffingo.com> 2009-01-26 23:31:42 ---
(In reply to comment #35)
> (In reply to comment #33)
> Packaging whole scripts for a driver isn't possible at the moment. Although it
> could be, I think this is better off in the xorg-x11-drv-fglrx package anyways.
I would put a BIG FAT WARNING ON this particular topic.
This isn't needed to remove the hardcoded blacklist-radeon on fglrx install if
we don't remove access to theses scripts. I meant this is a HIGHER LEVEL RISK
to have theses scripts runned while radeon is been used.
I think we're
misunderstanding each other - I agree for now we need to disable
fglrx/radeon switching (see below) but in the future, these scripts can stay
and won't pose any threat or cause any glitches. They will be in place on the
filesystem, but won't run as they'll "exit 0" as soon as they realize
rpmfusion-config-display has set radeon as active.
Here is what chery picking of problems I've runned into, when I
tried to move
- vga cannot be used the same as fglrx while using radeon (because of kernel
modesettings ?). If vga mode is specified on grub, we cannot run in radeon
mode. If possible, we need to go to fglrx, or worse, falback to vesa.
- screensaver doesn't quit to segfault, even if the ATI vendor scripts specific
to fglrx are removed.
- While using radeon but radeon isn't present in the initrd kernel image, fglrx
seems to be loaded anyway if not in blacklisted in
blacklist-rpmfusion-config-display (or else). This leads to have Xorg loading
to fail very badly.
(In reply to comment #37)
For theses reasons I really think we should remove the switch from
capability until initrd images are duplicated accurately. And stay with
harcoding the blacklist-rpmfusion-config-display once fglrx is installed (with
blacklist radeon drm and radeonfb). On reboot either the kernel image hasn't
been updated, then we stay with radeon modesetting. Or the kernel image has
been manually updated, or updated by a kernel update and we switch to fglrx.
On earch boot, what will depend on which xorg driver is used is as simple as
knowning which kernel module is loaded. (fglrx will always take precedance over
radeon unless this last is already loaded in the kernel image, but we might
also hardcode fglrx which will be harder since the kernel itself is always
installed and kernel images generated, before fglrx.ko is present).
+1, until the
situation improves I think that's our best (and only) option...
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.