Related Objects
- Mentioned In
- T3734: switch to modsetting on intel
How about, rather than going back to KDE Config Driver manager and its UI which is unrelated to any other way of installing stuff and which uses qapt and bits we'd rather not have, we integrate ubuntu-drivers into Discover? Does that make any sense Aleix?
I'm not sure, can you elaborate?
What would Discover do differently?
If it's just about being able to search for "nvidia" and get to install nvidia drivers, that would make sense, but I wouldn't add specific code paths.
TLDR: I'm interested, tell me more.
running
ubuntu-drivers list
gives a list of packages it thinks makes sense to install on your system
e.g. I get intel-microcode
these are just packages in the Ubuntu archive which are in restricted section and so can't go on the ISOs
Currently the UI for this is kubuntu-driver-kcm (in KDE git as kde:kubuntu-driver-kcm) which is currently a bit broken and uses qapt which we are trying to replace infavour of packagekit and discover.
I'm wondering if it makes sense to have a Discover module to check for recommendations from ubuntu-drivers and offer to install them.
The alternative is to update kubuntu-driver-kcm to work again but a whole distro-specific app seems worse than a distro-specific module from a KDE point of view and it means people needing to discover a different UI.
Jens any VDG insight?
Any movement on this behind the scenes? Kubuntu would love not to have to keep up a Kubuntu-only driver manager, and Neon doesn't want to do that either. Surely other distros who use Discover have similar needs?
Perhaps I'll ask on the Distributions list and see if we can get some movement here.
@apol, I recall that we talked recently about adding a "driver backend" to Discover. This would probably fall under the scope of that proposal.
Also, should this stay assigned to Jens? He disappeared 3 months ago.
Would you all envision this as something that's automatically-run on first post-install boot? I like the idea of it being in Discover, so that all ultimately all package management, update, and "app store" duties are done there. Because
- reduces confusion
- adds value to Discover
- removes the need for another tool for a user to find & use
I would envision the 'ubuntu-drivers list' commend being run automatically on 1st run post install-boot, and / or at least also be available anytime on demand, as a section on the left, as shown:
My 2 cents - Hope to see this come to fruition in some manner :)
appstream has ability to list drivers and list modalias to match to hardware
https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Driver.html
/usr/share/metainfo/com.intel.beignet.metainfo.xml
appstreamcli get com.intel.beignet lists a driver
which installs beignet-opencl-icd
so Discover could add a mode to list drivers recommended by appstream and help user install them
beignet driver appstream info comes from Debian. to be useful for Neon it would need Ubuntu to support it for lots of things (or us to add it)
To be clear FTR: we (that is Jon, Aleix and I) are not sure this necessarily belongs in discover. It also kinda depends on the end game here. If we are only after a list of drivers for the system it's easily realized using the new driver components in appstream. If we want something more like ubuntu's driver tool this needs some more thinking though. A big unknown in general is how to qualify drivers though. i.e. assuming we know that both nvidia-390 and xorg-nouveau provide a driver for the same device in the system (i.e. the graphics device), how do we determine which of the two is the "preferred" driver.