{"id":23738068,"url":"https://github.com/csmart/jockey-yum","last_synced_at":"2026-03-01T17:30:17.055Z","repository":{"id":66656958,"uuid":"2200132","full_name":"csmart/jockey-yum","owner":"csmart","description":"Ubuntu's device driver manager","archived":false,"fork":false,"pushed_at":"2011-09-08T10:24:56.000Z","size":1664,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"master","last_synced_at":"2024-12-31T08:52:29.266Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://launchpad.net/jockey","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/csmart.png","metadata":{"files":{"readme":"README.txt","changelog":null,"contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2011-08-13T02:12:12.000Z","updated_at":"2017-05-16T00:14:44.000Z","dependencies_parsed_at":"2023-02-20T08:45:26.038Z","dependency_job_id":null,"html_url":"https://github.com/csmart/jockey-yum","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/csmart%2Fjockey-yum","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/csmart%2Fjockey-yum/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/csmart%2Fjockey-yum/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/csmart%2Fjockey-yum/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/csmart","download_url":"https://codeload.github.com/csmart/jockey-yum/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":239879312,"owners_count":19712176,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-31T08:52:39.387Z","updated_at":"2026-03-01T17:30:17.005Z","avatar_url":"https://github.com/csmart.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"Jockey driver manager\n=====================\n\nJockey provides the infrastructure and the user interface for finding\nand installing third-party drivers which are applicable to the\ncomputer. This includes drivers which are added or updated after the\nrelease of a distribution, or drivers which cannot be included into\nthe distribution for various reasons (CD space limitation, licensing\nproblems, etc.). \n\nA common use case is providing a friendly and semiautomatic way to\ninstall drivers for new hardware which the current distribution\nrelease does not support yet, or install Nvidia and ATI fglrx X.org\ndrivers.\n\nJockey was designed to be distribution agnostic and fulfill the need\nof different distributions, driver vendors, and system integrators. It\nis designed and developed within the LinuxFoundation driver backports\nworkgroup [1].\n\nOperation\n---------\n\nAt startup, the Jockey backend probes the system for available\nhardware. This can happen in various ways, currently implemented is\nscanning /sys for modaliases. In the future it is planned to add more\nmethods, such as querying cups for detected printers which do not have\na driver.  Detection methods will be added as needed by component\nvendors and distributions. The set of available hardware is\nrepresented as \"HardwareID\" objects (which can represent anything that\nuniquely identifies a piece of hardware, such as a vendor/product ID,\na modalias, or a printer identification string).\n\nFor each hardware ID, a set of driver databases (instances of\nDriverDB) are queried for available drivers. At the moment, the only\nexisting implementation is LocalKernelModulesDriverDB, which uses the\nstandard Linux kernel modules.alias maps to map modaliases to\nkernel modules. In the near future we plan to add another\nimplementation which queries an online driver database as well.\nThe DriverDBs transform the set of HardwareIDs to a set of DriverIDs.\n\nA DriverID represents all necessary metadata about a driver, such as:\n\n * driver class (kernel module, printer driver, package, X.org\n   graphics driver, firmware, etc.)\n * handler class name (see below)\n * location of the driver (repository, package name, possibly sha1 and\n   other checksums, signatures)\n * driver specific parameters (arbitrary type/value pairs which the\n   handler understands)\n\nAll drivers handled by Jockey need to be encapsulated by a subclass of\n\"Handler\". A handler instance provides a hook for arbitrary code which\nneeds to run in order to fully install a driver. Jockey already\nprovides handler implementations for common cases such as kernel\nmodules, kernel module firmware, X.org driver, groups of drivers, etc.\nThe vast majority of drivers will use parameterized instances of these\ndefault handlers, but drivers which need some more sophisticated\nlocal configuration can ship their own handler subclass and add the\nnecessary code.\n\nAuto-install mode\n-----------------\n\nFor integration into installers or for OEMs, handlers can be marked for\nautomatic installation. When calling Jockey with --auto-install, these marked\nhandlers will be automatically installed if they are applicable to the system.\nThe --list option will show which drivers are configured for this.\n\nThis can happen by setting a handler's \"self._auto_install = True\" attribute in\nthe code, but the preferred way is to create a flag file\n/usr/share/jockey/handlers/autoinstall.d/\u003cid\u003e, where \u003cid\u003e is the driver ID\nshown by --list (for example, \"xorg:fglrx\" or \"kmod:wl\").\n\nStructure\n---------\n\nThe bulk of Jockey's work (hardware detection, driver database\nqueries, package installation, etc.) is done by an UI independent\nbackend which provides its functionality over the system D-BUS. Access\nis controlled by PolicyKit privileges (see\nbackend/com.ubuntu.devicedriver.policy.in for details); by default,\nall users can do local device driver status queries, all local users\ncan trigger a remote driver database query, and actually\ninstalling/removing drivers is restricted to system administrators.\n\nThe different user interfaces (GTK, and KDE, and both provide a CLI as\nwell) run with normal user privileges and just provide a human\nfriendly and internationalized presentation/UI of the backend\nservices. They do not contain any driver logic.\n\nAdapting Jockey to a Linux distribution\n---------------------------------------\n\nJockey is carefully written to not be specific to any Linux\ndistribution. All OS/distro specific operations are encapsulated in\nthe \"OSLib\" class, which needs to be subclassed and implemented by the\nLinux distributions. Most methods already have a reasonable default\nimplementation upstream, but some are just inherently distro specific\n(search for \"NotImplementedError\" to find those).\n\nThis minimizes the porting efforts of distributors while retaining the\npossibility to make adjustments in one central place.\n\nThe abstract OSLib class is thoroughly documented, and there already\nexists a branch for Ubuntu[3], and the test suite has a dummy\nimplementation (see tests/sandbox.py). These should suffice to\nimplement Jockey for other distributions as well.\n\nDependencies\n------------\n\nJockey needs a working Python installation, and the following Python\nmodules:\n\n - dbus-python for providing the D-BUS service for enquiring\n   and requesting drivers. Latest release is available at\n   http://dbus.freedesktop.org/releases/dbus-python/ . dbus-python\n   itself depends on pygobject, which can be downloaded from\n   http://ftp.gnome.org/pub/GNOME/sources/pygobject/ .\n\n - pyxdg: http://freedesktop.org/wiki/Software/pyxdg\n\n - X-Kit for X.org driver handler for parsing and changing xorg.conf.\n   Releases available at https://launchpad.net/xorgparser/+download , or check\n   out latest trunk with \"bzr get lp:xorgparser\".\n   \n - DistUtilsExtra for running setup.py (which will care about\n   building, merging, and installing gettext .po files, installing\n   icons, etc.): Latest tarball can be downloaded from\n   https://launchpad.net/python-distutils-extra/+download .\n   Note that this is not necessary for running Jockey from the source\n   tree.\n\n - pycurl for fetching and verifying GPG fingerprints from vendor https sites.\n   Latest releases can be downloaded from http://pycurl.sourceforge.net .\n\n - polkit-1. The latest release is available at\n   http://hal.freedesktop.org/releases/\n\n - If you want to run the frontend as normal user, you also need a\n   PolicyKit authentication agent for your desktop environment. You need\n   PolicyKit-GNOME (available at the same URL) for GNOME, a KDE frontend is\n   available at ftp://ftp.kde.org/pub/kde/stable/apps/KDE4.x/admin/\n\n   Alternatively, you can change the .desktop files to run them as root (e. g.\n   add \"X-KDE-SubstituteUID=true\" to the KDE one).\n\n - If you want to use the default upstream implementation of the\n   package handling methods in OSLib, you need PackageKit (tested with\n   \u003e= 0.2.2). The latest release is available at\n   http://www.packagekit.org/releases/\n   If your distribution does not work with PackageKit, you need to\n   provide your own implementation in OSLib.\n\nFor the GTK frontend, you need the GIR typelibs for GLib, GdkPixbuf, Gtk, and\nNotify, and optionally AppIndicator.\n\nFor the KDE frontend, you need\n\n - PyQt4: http://www.riverbankcomputing.co.uk/pyqt/index.php\n\n - PyKDE4 from the kdebindings KDE component\n\nTrying it\n---------\n\nAs written above, Jockey provides mostly infrastructure. Without an\nimplementation for a particular distribution and without actual\ndrivers it is fairly useless. However, you can get a first impression\nby installing the upstream version.\n\n 1. Run \"./setup.py build\" (as normal user) for running the i18n magic\n    and to build the PolicyKit .policy file.\n\n 2. Running the backend on the system D-BUS requires at least the\n    D-BUS .conf and Policykit .policy files to be installed, so the\n    easiest way is to install the package:\n\n    # ./setup.py install --record jockey.files\n\n    (as root).\n\nThen you can run either \"jockey-gtk\" or \"jockey-kde\" to spawn the GUI.\nSee --help for information how to run it in particular modes, or how\nto use it in command line mode.\n \nThis will bring up the UI and list all standard kernel modules which\nare tied to hardware. (Note that you will *not* see all this stuff in\na proper distribution implementation, of course.) Disabling and\nenabling kernel modules will work, it cause them to get\n(un)blacklisted. Make sure to not render your system unbootable that\nway :-) .\n\nNormal the backend is started automatically via D-BUS activation.\nFor debugging you can also start it on a shell with debugging enabled:\n\n  # /usr/share/jockey/jockey-backend --debug\n\nfor some insight of how Jockey detects hardware and which\nkernel modules are responsible for driving it.\n\nIf you want to uninstall again, use the --record file created with\ninstall:\n\n  # xargs rm \u003c jockey.files\n  # xargs rmdir -p \u003c jockey.files\n\nTesting drivers without hardware\n--------------------------------\n\nIf you do not actually have hardware which needs third-party drivers, you can\ncreate a \"match-all\" fake modalias file for all the drivers you want to test.\nHave a look at examples/fake.modaliases how this looks like.\n\nJust copy that to /usr/share/jockey/modaliases/fake and restart jockey.\n\nD-BUS interface\n---------------\n\nJockey provides two different D-DBUS interfaces. One is on the system\nbus and provides access to the Jockey backend, which needs root\nprivileges. This is used by the various Jockey frontends (GTK, KDE,\ncommand line), but can of course be used independently by other\napplications. Please see jockey/backend.py, all functions marked with\n\"@dbus.service.method\", for a detailled interface documentation.\n\nThe single most interesting request that other applications have is \"I\nhave this device, and need a driver\". This requires a graphical user\ninterface for allowing the user to confirm installation, and present\nprogress dialogs, etc. Thus Jockey offers a D-BUS interface on the\nsession as well, which provides this feature in a convenient way:\n\n  bus: com.ubuntu.DeviceDriver\n  object path: /GUI\n  interface: com.ubuntu.DeviceDriver\n  method: search_driver(hardware_id)\n\nThis method takes a single string, a \"Hardware ID\" (see above).\n\nExample:\n\n   dbus-send --print-reply --dest=com.ubuntu.DeviceDriver /GUI \\\n      com.ubuntu.DeviceDriver.search_driver \\\n      string:\"printer_deviceid:MFG:Hewlett-Packard;MDL:HP DesignJet 3500CP\"\n  \nThis will search local and remote driver databases (such as\nopenprinting.org) for a matching driver, and if it finds one which is\nnot installed yet, present the details of that driver, ask for\nconfirmation, and install it.\n\nThis returns a pair (success, files); where 'success' is True if a\ndriver was found, acknowledged by the user, and installed, otherwise\nFalse; \"files\" is the list of files shipped by the newly installed\npackages (useful for e. g. printer drivers to get a list of PPDs to\ncheck).\n\nTest suite\n----------\n\nEvery new feature and bug fix should first get a test case, to\nmaintain nearly 100% code coverage. tests/sandbox.py provides fake\nimplemetations of OSLib, a fake /sys tree, modinfo, etc., so that the\nentire hardware detection and handler system can be automatically\ntested independent of the actual hardware Jockey runs on, as well as\nbeing independent of a concrete OSLib implementation.\n\nTo run it, simply do\n\n tests/run \n\nThe graphical UIs have separate test scripts, since they might not\nwork in all cases (like running them automatically during package\nbuild):\n\n  tests/run-gtk\n  tests/run-qt\n\nA commit to trunk must only be done if all test suites succeed.\n\nPlease note that the tests do not depend on the system D-BUS or\ninstallation of any files. They will spawn their own local test\nbackend on the session D-BUS.\n\nDevelopment\n-----------\n\nDevelopment of trunk and the Ubuntu implementation happens on the\n\"jockey\" Launchpad project: \n\n  https://launchpad.net/jockey\n  \nThis is the place to report bugs, do translations, hosting your own\nbranches (if you wish to do so), and download upstream releases.\n\nReferences\n----------\n\n[1] http://www.linux-foundation.org/en/Driver_Backport\n[2] https://code.launchpad.net/~jockey-hackers/jockey/trunk\n[3] https://code.launchpad.net/~ubuntu-core-dev/jockey/ubuntu\n\nMartin Pitt \u003cmartin.pitt@ubuntu.com\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcsmart%2Fjockey-yum","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcsmart%2Fjockey-yum","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcsmart%2Fjockey-yum/lists"}