Hi. sorry for delay, but had the flue last week... Chris Rivera wrote:
On Thu, 2007-03-01 at 12:33 +0100, Klaus Singvogel wrote:
We need to mention that the current hal backend needs to be extended to satisfy the new requirements, which actual CUPS system expects from backends. But it seems that upstream developers didn't work on this opportunity till today.
What requirements are you referring to?
The backends report now different states of printers back to the cups daemon.
Hmm. I had a quick look at the current hal/dbus architecture. I didn't see any pollin by any device so far. Instead an administration process called by the hal/dbus system is executed. I'm speeking about the hal-cups-utils/hal_lpadmin tools. Maybe I'm wrong...
Right. HAL callouts are used to add/remove printers when appropriate.
So, we can use any program here? Thinking of YaST for automatic de-/installation...
But if not, then we might replace the hal backend by _any_ backend, and no need to use no longer developed tools (hal backend) is needed. Instead we can use our own mechanism here, even YaST, as soon as YaST supports installation of printers without any need of user feedback (full automatism).
You would have to convert the HAL udis to whatever uri scheme the other backends use. We might be able get the device node in the callout and eliminate some of the work for the backends, but this seems kinda clunky. It would be nice to just take advantage of HAL and use the HAL udis as persistent printer uris.
But does HAL backend work properly for multi function printers (MFP) (= FAX/Scanner/Printer devices)? Does HAL backend always work with _any_ supported OpenSource driver? AFAIK the hplip backend needs to be used to be able to scan with such MFP devices. Using the usb backend caused (locking) problems, when scaning with such devices. As the code of the hal backend is pretty close to the usb backend, I expect same problems here.
I want to point out, that there should be no goal to remove the usb backend from the system. The reasons are the manuals, and the CUPS book, which only speaks about this. Also the good help at the cups mailing lists should be mentioned, which is no longer usuable for the customers, if we cut the usb backend off the system.
How are ambiguities between the backends resolved? Having both usb and HAL backends cause the same printer to be detected twice. You need mappings between uri schemes to avoid this, right?
Yes, I think that such a mapping might be necessary. But the libusb provides the same information (vendor, model, serial) as the dbus node contains. I think the program for mapping shouldn't take to long to write down. But a good testing needs to be done though. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org