Jonathan Thomas [2012-06-04 17:27 -0400]:
> So UbuntuDrivers.detect will be useful for getting a list of available
> driver packages. But how will presentation/selection of drivers be
> handled? Does each package represent a driver, and information to be
> displayed to the user be derived from that?
In Jockey we have a few hardcoded strings for known special cases (e.
g. the NVidia driver). My original idea was to drop those and just use
the package description, and then fix the package description instead
of having a separate string mapping. But if the latter is still
desired, it should be put into ubuntu-drivers-common instead of being
duplicated in the two GUIs. However, that will mean that the UIs
_will_ have to use the Ubuntu specific API; the PackageKit API can
only get you package references.
Please remember that u-d-common is far from being set in stone. If
Mathieu and you need some new API there, please do add it. It would
just be nice to keep it as simple as possible and instead of adding
hacks there, fix stuff at the proper place (i. e. make sure that
driver package's postinst scripts set up everything, instead of some
post-package-install quirk hooks).
> (I'm going by the design from the wiki linked to by the blueprint)
> And for cases where multiple drivers per device are available, how
> will the frontends for this handle grouping of packages by device?
In Jockey we haven't so far, but indeed it would be nice to do so, as
the current presentation is far from obvious (showing up to six
different NVidia drivers). I think the GUIs have to specially handle
the well-known nvidia-* and fglrx-* (as they have "normal" and
"-updates" variants, as well as several versions), and just show any
other package result as a separate driver to be enabled or disabled
(i. e. installed or uninstalled).