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

RPM Fusion Bugzilla noreply at rpmfusion.org
Fri Jan 23 21:51:49 CET 2009


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





--- Comment #34 from Stewart Adam <s.adam at diffingo.com>  2009-01-23 21:51:49 ---
(In reply to comment #30)
> * Please make the description span the 80 columns. It'll look nicer.
Done
> * We don't need to package the INSTALL file.
I've removed NEWS, too
> * Please put the full text of GPLv2 into the COPYING file. The COPYING file, as
> is, looks scary.
I must have copied COPYING from the wrong local project... Fixed now.
> ? Can we make a pixmap (icon) for this?
Sure - I'm not anywhere close to a good graphic artist, but if someone wants to
create a pixmap I'll gladly accept it.
> * Requires: pygtk2-libglade will pull python-2.5+ and pygtk2. So no need to add
> Requires: pygtk2 and python >= 2.4
> * Requires: pyxf86config >= 0.3.1
> Do we need the version requirement for this? Even Fedora-7 comes with 0.3.33
> * BuildRequires: automake, autoconf, python-devel >= 2.4
> seem not necessary. Instead, you just need BR: python
All fixed

(In reply to comment #32)
> * You need to Obsoletes/Provides livna-config-display
> Obsoletes:         livna-config-display < 0.0.22-100
> Provides:          livna-config-display = 0.0.23
> * The config file would deserve a .conf ( /etc/rpmfusion-config-display.conf )
> * Every files the tool expect to edit will have to be owned by the package :
> %ghost %{_sysconfdir}/modprobe.d/%{name}
> %ghost %{_sysconfdir}/modprobe.d/ld.so.conf.d/%{name}.conf
> %ghost %{_sysconfdir}/udev/makedev.d/40-%{name} (if needed)
All of the above is fixed
> I think previous configuration files that will conflict with the unified
> configuration of closed source driver should be removed in %prep
> /etc/ld.so.conf.d/nvidia*.conf , etc.
Although we'd be removing "our own" files, I think that since we are going to
need a rebuild of all the graphic driver packages anyways, we should just drop
it from the xorg-x11-drv-foo packages which will effectively remove it from all
user's systems.
> * I really don't understand wtf feature is expected from jockey:
> What r-c-d primary goal is to configure the xorg.conf according to the selected
> hardware driver and the way we package the driver. (in other words, configure
> the xorg.ModulePath driver and ld.so.conf along with different checks).
> 
> In the opposite, jockey's aimed to discover which driver will support the given
> available hardware. This has nothing to do which how the driver is been
> configured. (jockey still use aticonfig and nvidia-xconfig tools IIRC)
> 
> So if someone want to package jockey, please do it in another review and make
> it requires rpmfusion-config-display eventually. But rpmfusion-config-display
> has nothing to do with jockey.
Agreed - I just posted the bit about Jockey to document our decision about the
PK integration feature. The work on Jockey will be done in the near future in a
separate review.

(In reply to comment #33)
> (In reply to comment #32)
> ...
> > * Every files the tool expect to edit will have to be owned by the package :
> > %ghost %{_sysconfdir}/modprobe.d/%{name}
> > %ghost %{_sysconfdir}/modprobe.d/ld.so.conf.d/%{name}.conf
> > %ghost %{_sysconfdir}/udev/makedev.d/40-%{name} (if needed)
> and 
> %ghost %{_sysconfdir}/acpi/actions/ati-powermode.sh (which can cause lot of
> hurt if radeon/nvidia is been used.)
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.
We can use rpmfusion-config-display's hooks (--get-state) to "exit 0" if needed
before any action is taken.
> Beside that, the tool looks amasing. It is open by design
Thanks!
> 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).
That would be easy to do - just let me know what you need tweaked/added/removed
and I'll add that in the next version.
> 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.
I was thinking about adding another hidden option --fix-module-paths which
would check for the correct module paths and add them if applicable (ie, when
the proprietary driver is enabled)... We could wrap this call in those tools,
so the modulepaths would always be added if they are needed.

SPEC:
http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-display.spec
SRPM:
http://downloads.diffingo.com/rpmfusion-config-display/rpmfusion-config-display-0.2-1.fc10.src.rpm


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


More information about the rpmfusion-developers mailing list