Overview of Jockey replacement; options for Kubuntu?

[Jonathan Thomas]

Hello,

On Fri, May 25, 2012 at 5:12 AM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Hello all,
>
> Also sending this to kubuntu-devel@, but as I'm not a subscriber
> someone needs to moderate; CC'ing Scott and Harald directly.
>
> As discussed at UDS and in [1] we want to dramatically simplify the
> machinery for installing extra drivers (NVidia, bcmwl, and friends).
> Jockey was originally designed to do a lot more than we are using it
> for, and be compatible with other distros as well (I had it working on
> Fedora 14 back then, when we discussed it in the Linux Foundation
> driver backports workgroup). But we don't use it to that extent, other
> distros have moved into a different direction, and thus it has way too
> much code and bugs. So Ubuntu will drop it and replace with with
> something much simpler and robust, and also use upstream friendly APIs
> (PackageKit).
>
> The logic of detecting drivers and providing PackageKit/aptdaemon
> plugins is now in the ubuntu-drivers-common package (formerly known
> as "nvidia-common"). This now mostly makes PackageKit/aptdaemon able
> to answer a "WhatProvides(MODALIAS, pci:s0000DEADv0000BEEF...)" query
> to map a piece of hardware to a driver package. It also contains a
> command line tool "ubuntu-drivers" with a few commands (list,
> autoinstall, and debug at the moment) which replaces jockey's usage in
> the installer (which called jockey-text --no-dbus ...).

I think that we'd rather not use PackageKit (for Kubuntu at least). We
already have python-apt and QApt as part of the default Kubuntu
install, so having a third apt worker implementation would be
undesirable. Could the new jockey communicate with a "what
provides-helper" written with libqapt that uses DBus for
communication, and use the qaptworker for running installs if I were
to implement such a helper?

>
> The user interface will be made a lot simpler and less confusing, and
> move into software-properties-gtk (or perhaps software-center at some
> point).
>
> The question arises what to do with Kubuntu. We have a few obvious
> options:
>
>  * Kubuntu uses software-properties-kde, so as long as we keep
>   software-properties, the new design could be implemented there as
>   well, and jockey-kde be dropped.

This could work, although it would (obviously) require some additional
GUI work on the KDE side of things. Though if we're already going to
have to write additional GUI...

>
>  * Kubuntu implements a similar (or their own) design using the
>   ubuntu-drivers-common API in the KDE control center as an embedded
>   tab. Then we can also drop jockey-kde.
... then I think it would be beneficial to write a KConfig Module so
that it could be integrated as a sub-page of the "Display and Monitor"
page in KDE's System Settings. I attempted to write a Jockey frontend
for this a few years back, but was foiled due to the multithreading in
jockey not playing nice with the KDE plugin apis.

>
>  * Kubuntu keeps jockey-kde, and takes over the Jockey maintenance.
>   ubuntu-drivers-common does not break Jockey, but it would still
>   need some maintenance to adapt to newer nvidia driver versions,
>   changing Qt/KDE APIs, and the like.

This is undesirable, but could be a fallback as a worst-case scenario.

>
>  * Kubuntu keeps the jockey-kde UI, but drops the backend
>   (jockey-common) and changes the UI to work with the
>   ubuntu-drivers-common API.

This could also be another fallback mode, if we get
ubuntu-drivers-common working with QApt as a backend, but don't get
the GUI done in time, etc.

>
> In either case, automatic driver installation by Ubiquity will Just
> Work (e. g. for the Broadcom wifi cards) but there should still be an
> UI for enabling or changing drivers (like NVidia, which is not
> auto-installed) manually.
>

Anyways, those are my opinions.