Unfortunately, many (or most) hardware devices need device-model-specific code or data, known as driver and ideally provided by the hardware manufacturer. Drivers in RPM or DEB packages need to be individually cretaed for each Linux distribtion, where as Snaps are independent of the Linux distribution where they get installed. Snao is therefore a nice format for manufacturer being able to provide hardware drivers at a low effort and low cost.
To make it easy (or even fully automatic) to find and install the correct drivers, the driver Snaps need to get associated to the hardware models they support, by having an appropriate data set in each Snap. The Snap Store would need to take the hardware signature of each Snap which it carries and so be able to answer a search for the driver for a given hardware model (= all Snaps which are associated with this model).
A client then could either trigger a hardware-model-based Snap Store Search (and Snap installaion in case of success) if it detects a new hardware device, or in the Snap Store client app (or in GNOME Control Center) there can be a list of detected/discovered hardware with “Search for driver” buttons.
This should at least work for all-userspace-drivers, like for printers and scanners for example.
What is needed is:
- Each Snap containing drivers or other hardware-model-specific code needs to provide a (text) file containing the hardware signatures for each supported device, ideally generated by a script during build of the Snap. Note that one Snap can support thousands of devices, like Gutenprint for example.
- If a Snap is uploaded into the Snap Store, the Snap Store server has to check whether it contains a hardware table and if yes, add the entries to a database (and naturally remove the entries of a Snap which gets removed or replaced)
- The Snap Store server’s API for clients should support a search by hardware signature: The client calls the appropriate function with a hardware signature and gets back a list of the Snaps which provide that signature according to the database.
For the design of the hardware table in the Snaps and the database on the Snap Store server one must take into account that different types of hardware can have different types of signatures.
Printers have for example device IDs, containing Make, Model, Page Description Languages, usually on USB, but also sometimes on SNMP and IPP, Make/Model always identifies them well enough, but USB Vendor and Product IDs can be the same for several different models.
USB (dumb) scanners can be identified by USB Vendor and Product IDs, for example.
It can also make sense to wildcards or regexps in the hardware table of a snap, so a manufacturer could easily cover all their devices or a certain series of their devices.
WDYT?
Till