Overview of Jockey replacement; options for Kubuntu?

[Jussi Schultink]

Hi all

On Fri, May 25, 2012 at 4:09 PM, Jonathan Thomas <echidnaman at gmail.com> wrote:
> 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.

This is definately my preferred solution - make it fit with other KDE
items and ways of doing things as much as possible. Also, if the
module can be written so that it would support other backends it
perhaps even could be forwarded upstream, which would be ideal.
>
>>
>>  * 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.
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

Hope my 2c are useful

Jussi