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

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #37 from NicolasChauvet <kwizart(a)gmail.com&gt; 2009-01-26 21:46:03 --- (In reply to comment #36) Maybe but at this time it is too late, we're already in the boot process and thus, need to workaround if the request is to use radeon. In the fglrx case, it wouldn't hurt to use vga=whatever nomodeset. But if we want to have the capability to boot on radeon with modesetting, that grub line cannot be inherited from such end-users tweaks while updating the kernel. In short, it will requires us to maintain two differents kernel images if we want to support switching from "radeon with modesetting" from one side; and "fglrx or radeon without modesetting" from the other side.(1) 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). Then, It will be possible to re-introduce a full featured radeon with modesetting support, if the end-user creates another kernel image with radeon radeonfb and drm. It will support kernel modesetting and plymouth, (blacklist will not prevent this once mkinitrd is generated --with radeon --with drm). But That will remains an "experimented users only" (or at least could be documented somewhere). This path is the better way to have the switch implemented accurately. (which will need a re-boot). Specially as new xorg-x11-drv-ati update might introduce new hardware support that will break some fglrx users where their hardware will became "supported" by radeon. For the record, that current scheme is the new world under which we need to think the ATI/AMD package, no new fglrx release can be expected to save us from this mess (IMO). (1) It might not become uncommon to have fglrx users want to add a vga option and then switching to the free radeon driver (specially if they're told their chip became supported). We can have many situations like that either or not the problem will be reported to us. At this step, my advice it to leave the switch radeon/fglrx are the documentation level. -- 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.