[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 #14 from Thorsten Leemhuis <fedora at leemhuis.info>  2009-01-04 20:10:03 ---
(In reply to comment #13)
> Created an attachment (id=70)
 --> (http://bugzilla.rpmfusion.org/attachment.cgi?id=70) [details]
> Mockup of new interface

Looks better; some more comments below

> (In reply to comment #12)

> > - is the whole "Hardware Information" section (in the upper 1/3 of the GUI)
> > really needed? 99% of our users likely have just one card; my intel graphics is
> > shows as two graphic cards, which is confusing (I assume the same will happen
> > with some AMD cards, as they have two entries in the pci list). 
> I originally put this section there so that users could see the recommended
> driver for any given GPU on their system.

Which is not much useful, as the user can only use drivers that support the
installed hardware. IOW: even if he has a GPU that supported by the 173 drivers
and later then he can only use the 173 drivers if one of the cards he has is
not supported by the 177 and later. 

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

The tool has all the information; if there are unsupported configurations (e.g.
one card that is only supported <=173 and one that is only supported in >=177)
then the tool should warn and not configure the drivers, as that would render
one of the cards unuseable.

> > I'd say the section should just get removed and the tool should just do the
> > right thing: Select the proper driver automatically -- mixing different
> > proprietary drivers (different ones from Nvidia or AMD and Nvidia) isn't
> > supported in any case
> 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.

Most users won't be interested in this. They just want to use the recommended
driver. Directly offering beta and alternate drivers just confuse users. They
should be offered, but they should be a bit hidden.

And in your latest mockup they are way to obvious. I'd even say that users will
accidentally select the 173 drivers in your design, as it looks like you need
to select one in that drop-down-box. 

IOW: if you (for example) have five drivers to offer then use one scheme to
present them. E.g. five radiobuttons or one drop-down box with five entries.
Mixing the two variants will just confuse users. That why I added the checkbox
"show beta and alternate drivers"; after checing that the radiobutton lists
would need to be recreated and show the others as well.

> > - The "driver configuration" in the lower 1/3 of the GUI should be IMHO removed
> > as well -- it's redundant with the stuff in the middle
> 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).
> 
> > - Why display the kernel-version? That is irrelevant for most users
> 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.

Maybe a second, small app that creates a pop-up right after logging in?


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