[Bug 171] Review Request: rpmfusion-config-display - tool to manage proprietary graphic drivers

> (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.

Here is what chery picking of problems I've runned into, when I tried to move from radeon/fglrx. - 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.

For theses reasons I really think we should remove the switch from radeon/fglrx 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).