[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 #38 from Stewart Adam <s.adam at 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
> 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.
> 
(In reply to comment #37)
[snip]
> 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).
+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.