Bug 264771

> I could not reproduce how to set up a queue with the old stlye URI
> in YaST (without changing "CUPS USB Device Settings" before).
> Could you tell us in bug #264771 what you did in YaST so that
> you got the old style URI?
>
> Perhaps it happens only if there is a printer at the USB where
> no manufacturer or model can be autodetected (e.g. in your special case)
> because all my USB printers are autodetected (as far as I know all
> printers with a built-in USB inferface can be autodetected).

It seems so.  After attaching the printer to the laptop and starting
YaST, it immediately offers usb://dev/usb/lp0, without any manual
intervention -- I don't have a parallel port, and my printer can't be
automatically recognized.

Regarding comment #1:
Could you attach /var/log/YaST2/y2log to this bug so that we might
be able to see why you got immediately usb://dev/usb/lp0

Created attachment 131330 [details]
YaST log file

>> YaST uses the new-style URI by default but YaST can be switched
>> via [Other]->"CUPS Expert Settings" ->"CUPS USB Device Settings"
>> to use the old-style URI by default.

global variable CUPS::usb_dev_names is changed but never used (yast always uses cups-usb backend)
So there is option but without any functionality, I will remove it.

With logs attached we will see more

Does perhaps the CUPS usb backend itself report the deprecated URI?

Werner,
1.
what results when you execute the CUPS usb backend directly as root:
/usr/lib/cups/backend/usb
2.
what does as root
lpinfo -v
show you?

What I found in code is, that YaST use Device File from hwinfo --printer, when no output from /usr/lib/cups/backend/usb available
Please attach also output from "hwinfo --printer"

`hwinfo --printer' produces no output.

`/usr/lib/cups/backend/usb' produces no output.

`lpinfo -v' gives

  network socket
  network http
  network ipp
  network lpd
  direct scsi

I can reproduce it:

/usr/lib/cups/backend/usb
direct usb://EPSON/Stylus%20Photo%20810 "EPSON Stylus Photo 810" "EPSON Stylus Photo 810 USB #1" "MFG:EPSON;CMD:ESCPL2,BDC,D4;MDL:Stylus Photo 810;CLS:PRINTER;DES:EPSON Stylus Photo 810;"

chmod -x /usr/lib/cups/backend/usb

/usr/lib/cups/backend/usb
bash: /usr/lib/cups/backend/usb: Permission denied


hwinfo --printer
21: USB 00.0: 10900 Printer
  [Created at usb.122]
  UDI: /org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial
  Unique ID: AX3v.twN5GQuyNJ3
  Parent ID: fJYU.vLnN03Gt8dE
  SysFS ID: /devices/pci0000:00/0000:00:1d.7/usb5/5-6/5-6.4/5-6.4:1.0
  SysFS BusID: 5-6.4:1.0
  Hardware Class: printer
  Model: "EPSON Stylus Photo 810"
  Hotplug: USB
  Vendor: usb 0x04b8 "Epson"
  Device: usb 0x0005 "Stylus Printer"
  SubVendor: "EPSON"
  SubDevice: "Stylus Photo 810"
  Revision: "1.00"
  Serial ID: "W33040110201335050"
  Driver: "usblp"
  Driver Modules: "usblp"
  Device File: /dev/usb/lp0
  Device Files: /dev/usb/lp0, /dev/usblp0
  Device Number: char 180:0
  Speed: 12 Mbps
  Module Alias: "usb:v04B8p0005d0100dc00dsc00dp00ic07isc01ip02"
  Driver Info #0:
    Driver Status: usblp is active
    Driver Activation Cmd: "modprobe usblp"
  Config Status: cfg=yes, avail=yes, need=no, active=unknown
  Attached to: #19 (Hub)


Now, when no ../usb backend output is available and only usable information is Device File: /dev/usb/lp0 I think it's fine when this device is used. 
But when output from ../usb is available, this uri is used, otherwise not.

Werner, it seems you have a scsi printer, so you need to use /usr/lib/cups/backend/scsi backend

The problem is that the old style usb URI does no longer work,
i.e. YaST must not set up any queue using "usb://dev/usb/lp0"
because it will simply not work.

In the special case of comment #8 it would be o.k. if YaST sets
up a queue using the file URI scheme like file:/dev/usb/lp0
but this does not work by default because of security reasons
there is by default no "FileDevice Yes" in /etc/cups/cupsd.conf see 
https://bugzilla.novell.com/show_bug.cgi?id=264219#c1
and I won't like YaST to open security problems if it writes
"FileDevice Yes" to cupsd.conf silenty and additionally this
requires a cupsd restart so that in the end I recommend to
simply not set up queues with a file URIs at all.

I think it is best to drop any hwinfo support in YaST printer
and rely only on what the CUPS backends report because this is
what is supposed to work.
Anything else is blind guess and plain luck.

reopened according comment #9
Johannes, ok I will remove hwinfo and use only cups backends

But there should be problem with parallel printers.

/usr/lib/cups/backend/parallel
direct parallel:/dev/lp0 "Unknown" "LPT #1"

hwinfo --printer
14: Parallel 00.0: 10900 Printer
  [Created at parallel.156]
  Unique ID: ffnC.s5K9xZzhQb4
  Parent ID: YMnp.ecK7NLYWZ5D
  Hardware Class: printer
  Model: "EPSON Stylus Photo 810"
  Vendor: "EPSON"
  Device: "Stylus Photo 810"
  Device File: /dev/lp0
  Config Status: cfg=yes, avail=yes, need=no, active=unknown
  Attached to: #9 (Parallel controller)

Steffen, where from you know information about Model/Vendor?

Michal,
was the EPSON Stylus Photo 810 connected and switched on during booting
or did you connect it or switched it on while the sytem was running?
I ask because the parport related kernel modules do autodetection
only when they are loaded - see "dmesg" or /var/log/boot.msg if
your printer was detcted while the modules have been loaded, e.g. do
"dmesg | egrep '^parport|^lp'".

As far as I know, hwinfo reloads parport related kernel modules
to force an autodetection but reloading of parport related kernel modules
had caused several problems, e.g. see
https://bugzilla.novell.com/show_bug.cgi?id=116655#c52
and it still causes problems, e.g.: bug #270804.


I can reproduce on my workstation that the CUPS backend doesn't "see"
a printer which was connected and switched on during booting:

# dmesg | egrep '^parport|^lp'
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP]
parport0: Printer, HEWLETT-PACKARD DESKJET 990C
lp0: using parport0 (interrupt-driven).

# lsmod | egrep '^parport|^lp|^ppdev'
parport_pc             42084  1 
lp                     15652  0 
parport                39752  2 parport_pc,lp

# /usr/lib/cups/backend/parallel 
direct parallel:/dev/lp0 "Unknown" "LPT #1"

# modprobe ppdev
# lsmod | egrep '^parport|^lp|^ppdev'
ppdev                  13060  0 
parport_pc             42084  1 
lp                     15652  0 
parport                39752  3 ppdev,parport_pc,lp

# /usr/lib/cups/backend/parallel 
direct parallel:/dev/lp0 "Unknown" "LPT #1"


It is the same on Klaus' workstation:

# lsmod | egrep '^parport|^lp|^ppdev'
parport_pc             42084  1 
lp                     15652  0 
parport                39752  2 parport_pc,lp

# dmesg | egrep '^parport|^lp'
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
parport0: Printer, Hewlett-Packard HP LaserJet 1100
lp0: using parport0 (interrupt-driven).

# /usr/lib/cups/backend/parallel 
direct parallel:/dev/lp0 "Unknown" "LPT #1"


What is strange is that it had worked well in the past, see
https://bugzilla.novell.com/show_bug.cgi?id=64412#c44
https://bugzilla.novell.com/show_bug.cgi?id=155474#c2
https://bugzilla.novell.com/show_bug.cgi?id=185135#c1

ad 12:
From /proc/sys/dev/parport/parport*; Johannes has summed up the situation
nicely.

This seems to be the difference:

On my workstation I get
# cat /proc/sys/dev/parport/parport0/autoprobe
CLASS:PRINTER;
MODEL:DESKJET 990C;
MANUFACTURER:HEWLETT-PACKARD;
DESCRIPTION:Hewlett-Packard DeskJet 990C;
COMMAND SET:MLC,PCL,PML;

But in the CUPS sources backend/parallel.c calls the function
backendGetDeviceID in backend/ieee1284.c which does
  ioctl(fd, LPIOC_GET_DEVICE_ID(device_id_size), device_id)
and it seems this ioctl fails.

Sorry for the late reply, I was abroad.

Regarding comment #8:  I really doubt that my old Apple LaserWriter Select
is an SCSI printer!  AFAIK, it has always had a parallel interface for
the IBM world (and an AppleTalk interface for Macs).

AFAIK, the very problem is that this printer doesn't have support
for self detection (thus hwinfo or any other program has no chance to
recognize the printer).  What is the recommended way to use the new CUPS
scheme in such cases?  Assigning an artificial printer ID?

Regarding comment #16:

An undetectable parallel port printer is reported by the CUPS
parallel backend like:
  root@host# /usr/lib/cups/backend/parallel 
  direct parallel:/dev/lp0 "Unknown" "LPT #1"
The DeviceURI parallel:/dev/lp0 is used and this works well.

But in your special case it is different because the USB-parport
converter makes it an undetectable USB printer (for the computer)
and this does no longer work out-of-the box with CUPS 1.2 because
any real USB printer is detectabe so that in your special case
you must use the special setup as described in
https://bugzilla.novell.com/show_bug.cgi?id=264219#c1

Klaus, could you fix parallel backend to provide Model/Vendor informations (comment #15)?

cat /proc/sys/dev/parport/parport0/autoprobe
CLASS:PRINTER;
MODEL:Stylus Photo 810;
MANUFACTURER:EPSON;
DESCRIPTION:EPSON Stylus Photo 810;
COMMAND SET:ESCPL2,BDC,D4;

/usr/lib/cups/backend/parallel
direct parallel:/dev/lp0 "Unknown" "LPT #1"

After that we can completly remove hwinfo and use only cups backends which will be good for bug-compatibility with cups (of course I wish no bugs ;-) ).

Reply to #17:

What about adding some info to all printers in the printer database (similar
to the stuff in #18) which marks old, non-detectable parallel printers as
such so that, after manual selection of the printer, YaST can do the
appropriate action in case it is connected via an USB-parellel adapter?

I can imagine that there are some users which do the same since such an
adapter is far cheaper than a new printer...

Werner, I like this idea, but who will create database such this?
we can ask opensuse users to send us this information, I don't have any other idea

Regarding comment #19:

We don't have a printer database.
All what we have is the PPD files under /usr/share/cups/model/.
What is called "YaST printer database" is /var/lib/YaST2/ppd_db.ycp
which is only a cache of PPD file information just like
what CUPS has as /var/cache/cups/ppds.dat.

Furthermore we don't know which printers are non-detectable
(up to now your model is the only one which I know).

Finally non-detectable parallel port printers are no problem.
Only non-detectable parallel port printers which are connected
via a USB->parport converter are a problem, see comment #17.

Please let us not misuse this bug report (which is about
"disable old style usb:/dev/lp0 URI in yast2 printer")
for general discussions about how to deal with non-detectable
parallel port printers which are connected via a USB->parport
converter or how to deal with USB->parport converters in general.
Please file an enhancement request for such issues.

postpone after 10.3

For the log regarding printer detection via parallel backend:

See the STR which describes the original problem
http://cups.org/str.php?L2535
and the matching comments e.g. this one
http://www.cups.org/newsgroups.php?s14299+gcups.general+v14306+T0
and the STR with the fix for version 1.4-current (r7020)
http://www.cups.org/str.php?L2553

The latter seems to indicate that now the ppdev kernel module
may be required but as far as I know it is not loaded by default.

mass reopening all 10.2 LATER+REMIND bugs.

close all 10.2 LATER/REMIND bugs as WONTFIX. Reopen yourself if you still plan to work on it.