Paul Gress wrote:
Norm Jacobs wrote:
I forgot to mention that if you use CUPS as your print system, you
don't need the printers:snmp service because CUPS and it's managment
app system-config-printer, don't use HAL for network attached printer
discovery.
So let me see if I have this correct. Since I'm using Cups, as
supplied, I do not need to use printer discovery, turn it off. Cups
enabled = Printer (Device) Discovery disabled. Correct?
The short version is yes.
The printer discovery support under hal provides async printer
discovery. The USB printer discovery comes from the kernel via
sysevents that translate into hal device tree add/remove events and the
corresponding dbus messages.
The network attached printer discovery was done as a hal addon, which
mimics the behaviour provided for USB attached printers.
When you run CUPS, system-config-printer uses hal-cups-utils which has
it's own method of plugging into HAL for async printer discovery and it
pretty much ignores the network attached printer discoveries. This is
consistent with it's operation on other platforms. Instead, when you
launch system-config-printer, and ask to create a new queue, it asks
CUPS to discover the available printers using the CUPS backend modules.
Shouldn't there be a popup messages alerting to this in "Services
settings" (services-admin)?
You might file an RFE to mark the printers:snmp service as incompatible
with the cups/scheduler service, though strictly speaking, they aren't
really incompatible. They just don't interact with each other, but
could be made to do so.
-Norm
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
