http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 Orcan Ogetbil <orcanbahri(a)yahoo.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |orcanbahri(a)yahoo.com --- Comment #1 from Orcan Ogetbil <orcanbahri(a)yahoo.com&gt; 2008-11-24 08:35:44 --- Can you explain the scope and the goals of this package a little more in detail? - Are we going to write config files for every card out there, OR - Are you going to extract this information from the Appendix A of README files inside the Nvidia driver packages (I don't know about ATI), OR - Do the end users have to write these config files by themselves? About the software: I couldn't figure out what I should put for the version in the config file. I have kmod-nvidia-newest installed. I tried version = newest version = 177 version = 177.82 version = 177.xx None worked. Either the script fails, or the window shows up but says "No module found". (I would go through the code but I didn't have time this weekend. ) -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #3 from Stewart Adam <s.adam(a)diffingo.com&gt; 2008-11-29 18:35:54 --- Update to rc1: SPEC: http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-d... SRPM: http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-d... This update re-introduces kmod_name in the driver config files so that it will work with our current driver layout ("nvidia-foo" is still using kmod name "nvidia" for now, not "kmod-foo") as well as using the 'rfbak' extension for backups instead of 'bak'. I've packaged some sample configuration files for testing: http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-d... Extract those to /etc/rpmfusion-config-display.d and then: * If you are using F10 or rawhide, remove the "nvidia.fc9" file and rename "nvidia.fc10" to "nvidia" * If you are using F9 or F8, remove the "nvidia.fc10" and "nvidia-173xx" files and rename "nvidia.fc9" to "nvidia" -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #5 from Stewart Adam <s.adam(a)diffingo.com&gt; 2008-12-20 19:05:25 --- Did you just extract the config files and run rpmfusion-config-display? As I mentioned in my last post you need to shuffle them around a bit before it works. Technically, there is be support for installations via the NVIDIA .run installer packages, but you would have to write your own configuration file for rpmfusion-config-display. It doesn't actually do any auto-detecting on what drivers are installed, and instead relies on the configuration files that the drives are supposed to package along with the required system files. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #7 from Orcan Ogetbil <orcanbahri(a)yahoo.com&gt; 2008-12-21 00:48:12 --- (In reply to comment #5) Yes, specifically I used this instruction: "If you are using F10 or rawhide, remove the "nvidia.fc9" file and rename "nvidia.fc10" to "nvidia" " Kevin, what do you mean? Am I not allowed to use 180.16 beta driver? Is there any other way of using it? -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #9 from Orcan Ogetbil <orcanbahri(a)yahoo.com&gt; 2008-12-21 01:08:19 --- The driver forked at some point. There are two different beta's. They have different capabilities. -OpenGL3 beta. Currently 180.11.02 -(just) beta. Currently 180.16 What we ship as nvidia-beta-kmod is the former one. What I want to use is the latter one. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #11 from Stewart Adam <s.adam(a)diffingo.com&gt; 2008-12-31 23:22:52 --- Here's an update for release candidate 2: SPEC: http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-d... SRPM: http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-d... rc2 has many bugfixes and improvements: * smarter profile script * fixed a few bugs when enabling/disabling from the GUI, * 2 new config options that will enable us to use rpmfusion-config-display with the 8.12 fglrx drivers * --list-drivers has a nice (readable) output now There's a bit more, all the changes are documented in the ChangeLog and README.developers files. Updated sample configuration files are available at the same place: http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-d... Please remember that: * If you are using F10 or rawhide, remove the "nvidia.fc9" sample file and rename "nvidia.fc10" to "nvidia" * If you are using F9 or F8, remove the "nvidia.fc10" and "nvidia-173xx" sample files and rename "nvidia.fc9" to "nvidia" -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #13 from Stewart Adam <s.adam(a)diffingo.com&gt; 2009-01-04 19:43:29 --- Created an attachment (id=70) --> (http://bugzilla.rpmfusion.org/attachment.cgi?id=70) Mockup of new interface (In reply to comment #12) Proprietary GPU Driver Configuration was just the first thing that came to mind, as I wanted to avoid confusion with "Display Configuration" which is system-config-display... But I think Graphics Driver Configuration is distinct enough to avoid confusion, so I'll change it to that. Will do. I originally put this section there so that users could see the recommended driver for any given GPU on their system. It could be removed entirely, but if the user does have two different cards installed, we might encounter some bugs (r-c-d will have to assume that the user wants to use the first detected card)... But that's nowhere near the majority of the cases. Those users can always use the CLI interface anyhow, which supports --list-gpus and --set-gpu. This gets a bit more complicated, as users may want to switch between nVidia variants for different reasons (for example, like when that KDE slowness bug was present in the 177 series driver). I'd prefer to keep the variant selection in there if possible with the the "autoselect" button enabled by default. I hadn't thought of making the open-source drivers selectable in the list instead of adding enable/disable buttons... That would make the interface much more simple (see attached mockup). Now that F10 masks boot messages by default, it'll be hard for users to catch the initscript's warnings if they're missing a kmod. We'll either need to have a way for users to check the driver status, or document how to do it from the CLI. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #15 from Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 2009-01-04 20:12:19 --- (In reply to comment #14) Do we maybe have any experts in UI design on rpmfusion-developers-list that could help out here to suggest/create a clean design? -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #17 from Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 2009-01-04 20:54:54 --- (In reply to comment #16) Wouldn't it be better the other way around? How is the user supposed to know which driver he wants/needs? That's afaics one of the bigtgest problems users run into right now... E.g. the user in a ideal world would install rpmfusion-config-display and it could tell the users which driver to install. Maybe rpmfusion-config-display could even install the proper package automatically using yum or PK? Hmmm. Maybe. But I still tend to think it's wrong to mix to different ways to chose the driver. Well I meant that the others should not be displayed at all (or greyed out) if the checkbox "show beta and alternate drivers" isn't checked. But maybe your way is better -- as mentioned earlier, I'm not expect in UI design -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #19 from Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 2009-01-05 18:50:25 --- (In reply to comment #18) Ehh, why? Just let each x11-xorg-drv-foo package create a small subpackage x11-xorg-drv-foo-hwinfo and track those in with a dep. Then you only have to do a rebuild of r-c-d when new pacakge get introduced (which shouldn't happen that often) I tend to say a two step solution with different tools just confuse users. Ideally it should be possible to chose, install and enable a driver with just one tool and just one or two clicks in it. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #21 from Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 2009-01-05 20:23:11 --- (In reply to comment #20) No; it IMHO definitely should be part of the driver package and completely auto generated there. Maintaining such a package manually sounds way to complicated to me -- especially when it comes to people that mix packages from updates, updates-testing or other repos (rawhide, external) Then he IMHO is own his own; improving our stuff and making things as easy as possible is IMHO way more important then supporting corner cases that have known downsides. As mentioned on IRC: I dislike a "drop-down menu" solution, as you can't see directly what options are available. You instead and to create on the drop-down box, which is error-prone. Hiding beta and legacy drivers also might get harder. Maybe you mockup really is the best and the easiest mix of the two variants. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #23 from Stewart Adam <s.adam(a)diffingo.com&gt; 2009-01-05 21:01:02 --- (In reply to comment #21) The config files can't be autogenerated, as they'll change from release to release (for example, the past 2 versions of fglrx require a Screen section while the previous releases didn't) and they include the PCI IDs of the supported hardware as well... I mean, either way something has manual, but with this setup we'll be changing an option in the config file instead of changing the initscripts or foo-config-display scripts all the time. Agreed, but if we can easily have a way to do it I don't see why we shouldn't. I'll have to do a bit more testing, but I think the config flag should work. (In reply to comment #22) It's just as easy to hide the menu items as checkbuttons, either way it's just an "if" check in the loop which adds the widgets/menu items. I mean it's not a huge deal, but I just think that if we're trying to avoid clutter and make things simple, let's not present 6+ button to the users at all unless they want to see them, which is when they click on the Manual radio button so they can see their options in the the menu. The menu itself will have a "-- Please select an item --" so that we avoid the accidental-selection problem, and when the user clicks back on the "recommended" or "open source" radiobuttons, the combobox's state is reset to a blank state. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #25 from Kevin Kofler <kevin.kofler(a)chello.at&gt; 2009-01-06 04:51:42 --- Stop right here! GNOME is not the only desktop environment in Fedora... (But no, I don't have suggestions for how to make the UI suck less. The only real solution is to get all graphics cards supported by Free drivers which come with Fedora and "just work".) -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #27 from Kevin Kofler <kevin.kofler(a)chello.at&gt; 2009-01-06 12:13:25 --- No, they're guidelines specific to GNOME. KDE has its own HIG: http://wiki.kde.org/tiki-index.php?page_ref_id=182 -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #29 from Stewart Adam <s.adam(a)diffingo.com&gt; 2009-01-23 03:23:55 --- After a some thought and discussions on IRC, the PackageKit integration will be saved for another utility (Jockey) which will help users install any of the drivers offered at RPM Fusion. I've updated rpmfusion-config-display to version 0.1. Notable changes are: - Do not sys.exit(1) in enable() and disable(), these may be called from the GUI - Add --{undo-,}libgl-symlink-hack arguments - Make crash/bug report dialog more HIG compliant SPEC: http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-d... SRPM: http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-d... -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 Conrad Meyer <konrad(a)tylerc.org&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |konrad(a)tylerc.org --- Comment #31 from Conrad Meyer <konrad(a)tylerc.org&gt; 2009-01-23 07:13:14 --- (In reply to comment #30) Generally %{name} isn't usually what is meant by "consistently use macros". Or at least, it's one of the least important ones to consistently use. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #33 from NicolasChauvet <kwizart(a)gmail.com&gt; 2009-01-23 18:09:46 --- (In reply to comment #32) ... and %ghost %{_sysconfdir}/acpi/actions/ati-powermode.sh (which can cause lot of hurt if radeon/nvidia is been used.) Beside that, the tool looks amasing. It is open by design Maybe it can also learn to tweak the /etc/X11/XvMCConfig config file for library which is libXvMCNVIDIA_dynamic.so.1 on 173xx and 96xx (some series from the main driver will only support vdpau). We might find a solution in case we allow access for the provided tools or not (depending of the current configuration), namely aticonfig nvidia-xconfig and nvidia-settings. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #35 from NicolasChauvet <kwizart(a)gmail.com&gt; 2009-01-26 16:20:03 --- 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. -- 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.

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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #39 from Stewart Adam <s.adam(a)diffingo.com&gt; 2009-01-31 08:01:26 --- Changes in 0.3: - Bugfix: Prefix all module names by "blacklist " in the blacklist file - Add --{undo-,}initrd-regen-hack arguments SPEC: http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-d... SRPM: http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-d... -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #40 from Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 2009-02-21 14:51:50 --- ping -- how to get things rolling? kwizart, could you maybe review this? I have no systems with nvidia or ati hardware at hand to test this, so I don#t feel comfortable to review this -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #42 from Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 2009-02-21 14:55:08 --- one more comment: why is stuff stored in /etc/rpmfusion-config-display.d ? I'd say users should never modify those files (or should they?), so /usr/share might be the better place -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #44 from Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 2009-02-21 19:59:08 --- (In reply to comment #43) What do you want see tested on intel hardware? But whatever: I guess the tool should just say something like "this tool only manages proprietary nonfree drivers; there are no such drivers for your hardware so you won't need this tool" or something like that I'd say: definitely go for /usr/share then. Make it use /etc/rpmfusion-config-display.d as second source if really needed, but I see no reason for that. IOW: don#t create config files or files in /etc without strong need -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #46 from Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 2009-02-21 20:42:42 --- (In reply to comment #45) Nope, right now it just warns that /etc/rpmfusion-config-display.d does not exist -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #48 from Stewart Adam <s.adam(a)diffingo.com&gt; 2009-02-21 20:59:42 --- (In reply to comment #47) Ah, that's normal since it can't tell the user they have got the wrong hardware if no harware lists (the config files) are installed. If you put this in to /etc/rpmfusion-config-display.d/fglrx, does it say you have the wrong hardware? [AMD Catalyst 8.12] config_version = 0.1 version = 8.561 kmod_name = fglrx xorg_name = fglrx vendor_id = 1002 device_ids = 9505|fooo incompatible_kmods = drm|radeon blacklist_incompatible_kmods = True xorg_incompatible_modules = xorg_required_modules = dri|glx xorg_options = VideoOverlay True|OpenGLOverlay False xorg_add_legacy_sections = True revert_to = radeonhd -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 NicolasChauvet <kwizart(a)gmail.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #49 from NicolasChauvet <kwizart(a)gmail.com&gt; 2009-02-23 18:54:54 --- Either we pick both /usr/share/rpmfusion-config-display/config and /etc/rpmfusion-config-display.d to store the official configuration files. Either just /etc/rpmfusion-config-display.d. But the files are aimed to be customizeable by users, so it will eventually be better to keep only one directory to avoid namespace issue with different directory rules. Also it is important that only the files ending with .conf to be processed, so backup files from edition (*~) will not be taken into account. Our own "official" config files are meant to be set as %config and can get potentially replaced at each update. At this time, the tool in not ready for inclusion for few reasons: - We need to froze the config FILES. (xvmc, avoid duplicate info, double choices for modules) - The tool need to be updated with the lastest scheme for replacement_xorg_libs that could lead to avoid the needs of tweaking xorg.conf at all with F-10 and beyond. - We need to figure out about what to do with the vendor configuration tools (multiple version shipped, only open sources ones for nvidia, allow to edit, will they appear if the other vendor driver is activated). - Tweaks for mesa-libGL removal for bogus application that want to dlopen libGL.so.1 from the standard places. Thoses are very the core functionality of the tool which are meant to be available for thinking about the inclusion. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #51 from Stewart Adam <s.adam(a)diffingo.com&gt; 2009-02-23 21:52:54 --- (In reply to comment #49) Good call - I'll make the config files use a '.conf' suffix and this will be stripped when parsing the files so we have the same trick where the filename is used to determine the GL library and Xorg extension file locations. I've done XvMC locally, will include in next update... What is the duplicate info we should remove? I haven't heard of this - is there a Wiki page I can read up about it? IMO: Let's stop packaging those in /usr/bin and put them somewhere else instead. We can put our own generic wrapper in /usr/bin for the CLI tools, and have the appropriate GUI tool (amdccle or nvidia-settings) launch from a button inside the rpmfusion-config-display GUI. The programming for this is done already and can be activated with the hidden options --libgl-symlink-hack and --undo-libgl-symlink-hack. We can make those options more exposed if needed, but I think leaving things as is and putting a note in README is sufficient... We don't want users playing around with that unless absolutely needed. (In reply to comment #50) One of the main goals I had in mind while designing rpmfusion-config-display was that it should be completely extendable - this way, users who prefer to use the foo.run packages or even 3rd (4th?) parties could use rpmfusion-config-display as the configuration system. While that's true, at the same time that is the desired behavior - users shouldn't be modifying our files in-place, but creating a copy of them. If they do modify our files in-place, then RPM will renamed their modified file and replace it with our packaged one. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 Adam Williamson <adamwill(a)shaw.ca&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adamwill(a)shaw.ca --- Comment #53 from Adam Williamson <adamwill(a)shaw.ca&gt; 2009-08-23 18:14:15 --- I'm reading through this as I was referred to it by my xorg-x11-drv-psb review. Just wanted to add one comment: not sure sufficient attention has been paid to identifying cards sufficiently reliably and comprehensively. To put it bluntly, the list provided in documentation by NVIDIA is nowhere near good enough. (ATI's driver has a list of IDs stuffed in a header file inside the driver package, which is helpful). I used to maintain the PCI ID lists for Mandriva, so I know this topic painfully well. The list in the NVIDIA documentation just isn't anywhere near complete, there are lots of cards out there with IDs that aren't included in that list. I used to use the Windows driver as an extra source of IDs, there's a header file in it somewhere with a somewhat obfuscated list that's rather longer than the one in the Linux driver documentation. The Mandriva list is here, for reference: http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/ldetect-lst/trunk/lst/pci... maintaining it was a gigantic pain in the ass, and I'm very glad I don't have to do it any more :) just pointing out that particular can of worms. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 --- Comment #55 from Adam Williamson <adamwill(a)shaw.ca&gt; 2009-08-23 20:01:39 --- Well... alias: pci:v000010DEd*sv*sd*bc03sc02i00* alias: pci:v000010DEd*sv*sd*bc03sc00i00* AIUI (I once boned up on modaliases but it's hard to remember everything) that's anything with NVIDIA's vendor ID in two specific device classes (that's the sc02 and sc00 bits). I suppose in theory r-c-d could use the same hack, but there's the significant problem of identifying _which_ NVIDIA driver to use: you not only have to draw up the list of IDs, you have to be sure which driver (the current or one of the legacy versions) to use for each one, if you're going to do it properly, and that's the most time-consuming bit. -- 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171 Stewart Adam <s.adam(a)diffingo.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #57 from Stewart Adam <s.adam(a)diffingo.com&gt; 2011-10-29 00:29:41 --- (In reply to comment #56) Yes. Nicolas has opted to use a static configuration and honestly, it's simpler this way so I'm doing this too for catalyst starting from F16. rpmfusion-config-display was supposed to make it easy to dynmaically switch between the proprietary and free drivers installed but because of all the workarounds needed esp. when a new Fedora release comes out, it just isn't worth it. Now that we have xorg.conf.d, it becomes much easier to create a plug-and-play driver since we no longer have to meddle with their xorg.conf. If the user is installing xorg-x11-drv-* from RPM Fusion, then it will stay activated. If they don't want it, they can (1) learn how to disable/enable it manually through the config files or (2) simply yum remove the driver to undo changes and yum install to get it back later. -- 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.