I am sorry I have been unclear : with the old Unix, I was able to run low level tests such as :
cat test_file > /dev/lp0
with such a test I would have been able to test the kernel driver only; so would have I been able to do with usblp, which generates such special devices : I could have generated low level printing data with pnm2ppa and sent them to /dev/usb/lp0.
The problem is that I don't know the USB subsystem enough, I don't know libusb at all, and I don't have a clue about how libusb addresses an USB device ? And all the low level tests which I found, implying libusb, make use of cups usb backend : I am for instance able to run :
but this does not help to understand whether the bug is in cups or elsewhere : this is my problem with this diagnostic. In my opinion we should first clarify this.
I am sorry I have been unclear : with the old Unix, I was able to run low level tests such as :
cat test_file > /dev/lp0
with such a test I would have been able to test the kernel driver only; so would have I been able to do with usblp, which generates such special devices : I could have generated low level printing data with pnm2ppa and sent them to /dev/usb/lp0.
The problem is that I don't know the USB subsystem enough, I don't know libusb at all, and I don't have a clue about how libusb addresses an USB device ? And all the low level tests which I found, implying libusb, make use of cups usb backend : I am for instance able to run :
cat texte.ps | gs -q -sDEVICE=ppmraw -r600 -sPAPERSIZE=letter -dNOPAUSE -sOutputFile=- - | pnm2ppa --eco -v 720 -i - -o - | DEVICE_ URI="usb: //HP/DESKJET% 20710C" /usr/lib/ cups/backend/ usb 1 1 1 1 ''
but this does not help to understand whether the bug is in cups or elsewhere : this is my problem with this diagnostic. In my opinion we should first clarify this.
What do you think ?