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

[RPM Fusion Bugzilla]

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171





--- Comment #37 from NicolasChauvet <kwizart at gmail.com>  2009-01-26 21:46:03 ---
(In reply to comment #36)
> > - 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.
> 
> It should work if you add nomodeset.
> 

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.