On Wed, 2010-04-07 at 13:07 -0400, Andrew Parker wrote: > I followed [4], and got the following: > > Examining connected devices > No Device IDs available. That means there are no reliable Device IDs to be had here. This can happen if the only way the printer can be detected is with DNS-SD. I don't have a good solution for that yet. > In [1] its states "Start with the relevant driver package for your > printer *not* installed and the printer disconnected. " specifically > for USB printers. I use two network printers and their drivers are > installed. Does this matter? Not in this case, no, as there were no Device IDs to match against. There are two things: 1. Testing whether the right drivers declare support for the attached devices. For this, we collect any Device IDs available from the attached printers, then look up which installed drivers declare support for them. We then take a look through trying to match up any drivers that look like they *ought* to declare support for the printers but don't (it's a sort of fuzzy match). 2. Testing the automatic installation of those drivers. For this, you have to start with the drivers uninstalled, obviously. Device IDs are akin to USB IDs: they are definitive for that particular model. Device IDs are not specific to any particular connection type (e.g. USB, parallel port, etc). Printer drivers do declare "make and model" strings, but these are human-readable and cannot be matched against anywhere near as reliably as Device IDs can. > "lpinfo -l -v" does not list the printers I use, but does list others, > but with no device IDs: > > Device: uri = socket://172.26.33.191 > class = network > info = HP LaserJet 4050 Series > make-and-model = HP LaserJet 4050 Series > device-id = > location = > Device: uri = socket://172.26.33.192 > class = network > info = Xerox WorkCentre 5638 v1 Multifunction System > make-and-model = Xerox WorkCentre 5638 v1 Multifunction System > device-id = > location = machine location not set > > What would you like me to do? It might be that these printers support SNMP. You could try running the snmp backend for them directly, like: /usr/lib/cups/backend/snmp 172.26.33.191 Ideally the 'lpinfo' command would have collected that information already -- the reason it doesn't is that our default firewall drops responses to SNMP broadcast queries (see bug #538675). Direct (non-broadcast) queries are fine. Tim. */
Attachment:
signature.asc
Description: This is a digitally signed message part
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
