I have got another idea to find a bit more details out for further considerations.
It seems that the function “get_devices” (from the source file “scheduler/ipp.c”) is responsible for the determination of available devices. Have you got any further experiences with the commands which will be constructed there?
No, I can’t help any further with this. Best to liaise with the CUPS developers IMO. Good luck.
I hope that also other experienced users would like to share further ideas here. :\
Best to liaise with the CUPS developers IMO.
I imagine that my bug reports might improve the software situation a bit. 
I have determined a bit more information for my use case with the following steps.
Now I see that the backend “usb” is also called during the device detection process. But I observe here that data extraction is not performed as expected for my working printer together with this backend while some data which look usable are provided by the execution of the program “/home/elfring/Projekte/CUPS/Probe/backend/usb” from the command-line in a terminal session.
Would you like to share any more experiences around the situation why the data exchange between the programs “cupsd”, “cups-deviced” and “usb” does not produce the expected result in my case? 
How would you test and improve the involved software further? :\
It took a while until the message “[CGI] Failed to open device, code: -3” in the file “/var/log/cups/error_log” caught my attention. I determined the function “open_device” from the source file “usb-libusb.c” as the origin for this information. The shown return value from a call of the function “libusb_open” corresponds to the preprocessor symbol “LIBUSB_ERROR_ACCESS”.
Would you like to help me further with the determination and setting of appropriate permissions for the affected print system configuration?
How often do you notice device discovery problems on your development or production systems?
**Sonne:~ #** /usr/sbin/lpinfo -v && grep -n ', code: -3' /var/log/cups/error_log
network lpd
network https
network socket
direct hp
serial serial:/dev/ttyS0?baud=115200
network smb
network ipps
network ipp
network http
1002:D [20/Jul/2015:09:08:24 +0200] [CGI] Failed to open device**, code: -3**
Would you like to follow progress with additional information from another bug report?
Does the automatic setting of file permissions for various devices need further improvements for a completely working system configuration?
Well, like Johannes Meixner is suggesting the udev rules in /usr/lib/udev/rules.d/50-udev-default.rules is responsible for setting set the ‘lp’ group permission.
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp"
It uses the ENV{ID_USB_INTERFACES}==“:0701??:” key matching to recognise a USB-connected printer, and 70-printers.rules uses a similar match for setting an environment variable associated with printer auto-configuration
# Low-level USB device add trigger
ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", TAG+="systemd", ENV{SYSTEMD_WANTS}="configure-printer@usb-$env{BUSNUM}-$env{DEVNUM}.service"
In your case, it would seem that this “:0701??:” device class is never matched, and although it would be fairly easy to create equivalent rules that do match for your hardware situation, that would not help determine the reason why the usb subsystem (or your printer) does not cause the normal rules to be triggered. This is the first time I’ve observed such behaviour.
The involved udev rules refer to the item “ID_USB_INTERFACES”.
For reference, my printer reports the following via ‘lsusb -v’
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 7 Printer
bInterfaceSubClass 1 Printer
bInterfaceProtocol 2 Bidirectional
iInterface 0
The udevadm utility can be used to aquire various device attributes. For example, my printer shows up via ‘lsusb’ with
Bus 002 Device 004: ID 04f9:0248 Brother Industries, Ltd DCP-7055 scanner/printer
From that I can do
udevadm info -a -n /dev/bus/usb/002/004
and a whole raft of device attributes are presented.
udevadm info -a -n /dev/bus/usb/002/004
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:1d.7/usb2/2-3':
KERNEL=="2-3"
SUBSYSTEM=="usb"
DRIVER=="usb"
ATTR{bDeviceSubClass}=="00"
ATTR{bDeviceProtocol}=="00"
ATTR{devpath}=="3"
ATTR{idVendor}=="04f9"
ATTR{speed}=="480"
ATTR{bNumInterfaces}==" 2"
ATTR{bConfigurationValue}=="1"
ATTR{bMaxPacketSize0}=="64"
ATTR{busnum}=="2"
ATTR{devnum}=="4"
ATTR{configuration}==""
ATTR{bMaxPower}=="2mA"
ATTR{authorized}=="1"
ATTR{bmAttributes}=="c0"
ATTR{bNumConfigurations}=="1"
ATTR{maxchild}=="0"
ATTR{bcdDevice}=="0100"
ATTR{avoid_reset_quirk}=="0"
ATTR{quirks}=="0x0"
ATTR{serial}=="E69893D1N337394"
ATTR{version}==" 2.00"
ATTR{urbnum}=="10"
ATTR{ltm_capable}=="no"
ATTR{removable}=="unknown"
ATTR{idProduct}=="0248"
ATTR{bDeviceClass}=="00"
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2':
KERNELS=="usb2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{devpath}=="0"
ATTRS{idVendor}=="1d6b"
ATTRS{speed}=="480"
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{authorized_default}=="1"
ATTRS{busnum}=="2"
ATTRS{devnum}=="1"
ATTRS{configuration}==""
ATTRS{bMaxPower}=="0mA"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="6"
ATTRS{bcdDevice}=="0311"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{quirks}=="0x0"
ATTRS{serial}=="0000:00:1d.7"
ATTRS{version}==" 2.00"
ATTRS{urbnum}=="158"
ATTRS{ltm_capable}=="no"
ATTRS{manufacturer}=="Linux 3.11.10-29-desktop ehci_hcd"
ATTRS{removable}=="unknown"
ATTRS{idProduct}=="0002"
ATTRS{bDeviceClass}=="09"
ATTRS{product}=="EHCI Host Controller"
looking at parent device '/devices/pci0000:00/0000:00:1d.7':
KERNELS=="0000:00:1d.7"
SUBSYSTEMS=="pci"
DRIVERS=="ehci-pci"
ATTRS{irq}=="20"
ATTRS{subsystem_vendor}=="0x103c"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x0c0320"
ATTRS{companion}==""
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003"
ATTRS{device}=="0x2836"
ATTRS{uframe_periodic_max}=="100"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-1"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x30c0"
ATTRS{numa_node}=="-1"
ATTRS{d3cold_allowed}=="1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
Some good info on udev testing here
BTW, it is
bInterfaceClass 7 Printer
bInterfaceSubClass 1 Printer
that corresponds to 0701 (base class and sub class) and triggers the required rule for USB-connected printers.
Which tool should I use to inspect further key values from the affected system configuration?
Where does the item “ENV{ID_USB_INTERFACES}” get set?
Does each data item consist of two digits here?
I can’t answer your questions in any great depth, since I’m not developer, and only have a general working knowledge about some of this hardware detection.
You can use ‘udevadm info’ to get attributes for a particular device.
Where does the item “ENV{ID_USB_INTERFACES}” get set?
AFAIU, it is systemd-udevd that collects this information, following the relevant uevent. (Previously, there was an external program usb_id that was used to do this, but this is all part of the daemon now).
This probably answers your question
http://www.usb.org/developers/defined_class
USB defines class code information that is used to identify a device’s functionality and to nominally load a device driver based on that functionality. The information is contained in three bytes with the names Base Class, SubClass, and Protocol.
The ATTR{bInterfaceClass} attribute should be valid for matching a printer type device
ATTR{bInterfaceClass}=="07"
Can any “confusion” happen around usage permissions eventually if devices offer several services together like the following?
Do I need to check any more details from my system configuration if I see the following information?
**Sonne:~ #** lsusb -s 3 && udevadm info -a /dev/bus/usb/001/003 | grep Class
Bus 001 Device 003: ID 0482:063e Kyocera Corp.
ATTR{bDeviceSub**Class**}=="00"
ATTR{bDevice**Class**}=="00"
ATTRS{bDeviceSub**Class**}=="00"
ATTRS{bDevice**Class**}=="09"
Where should the item “ATTR{bInterfaceClass}” get set usually?
On 2015-07-21 10:46, elfring wrote:
>
> deano_ferrari;2720372 Wrote:
>> You can use ‘udevadm info’ to get attributes for a particular device.
> Can any “confusion” happen around usage permissions eventually if
> devices offer several services together like the following?
>
> - Printing
> - Scanning
> - Storage on an USB port
Guessing, but each one gets a different manufacturer:model identifier
number. I don’t have hardware of that type available to test this
conjecture, though.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
It is possible that an untended rule is being invoked following a match. Printer and scanner rules both usually assign the ‘lp’ group to a given device node.
You can check what rule matching is invoked when a device is plugged in. Going back to ‘lsusb’ output, say if your printer is at ‘Bus 001 Device 002’, then for diagnostic purposes you can run
[FONT=monospace]udevadm info -n /dev/bus/usb/001/002 -q path[/FONT]
[FONT=monospace]
to get the full sysfs device path, then test with
udev test /devices/pci.....
or combine it like this
udevadm test $(udevadm info -n /dev/bus/usb/001/002 -q path)
This will return a lot of information, including any rules that are triggered following a match. That might help you determine which rules are being triggered when your printer is attached.[/FONT]
Where should the item “ATTR{bInterfaceClass}” get set usually?
This doesn’t get set - the attribute is read, and from that would be used to match against in a udev rule. Anyway, I think you should investigate which rules are being matched as I described in my last post.