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.
*/