Author Topic: cups and usb printers  (Read 17471 times)

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
cups and usb printers
« on: December 04, 2016, 10:37:21 pm »
Hi All

With my Canon wireless printer awaiting a new print head I have had to resort to attaching an Epson rx585 usb connected printer for the moment.

Sounds OK - except for the fact that cups cannot "see" the printer so I cannot set it up.

I opened a cmd window and tried running \cups\lib\cups\backend\usb.exe. Result:-

[J:\CUPS\LIB\CUPS\BACKEND]usb.exe

[J:\CUPS\LIB\CUPS\BACKEND]


That seems to prove that cups cannot "see" the usb connected printer.

I believe I have all necessary files in place - cups works as well as it can with my wireless printer.

I added libusb10.dll - on the libpath - to my system before trying to setup the usb connected printer.

I do note that there seems to be a specific build of usbcalls.dll on the ecups wiki HowTo page that is older than the currently installed build which comes from the Arca noae usb driver update package USB-11.14.exe

I installed the older usbcalls.dll and usbresmg.sys pair of files from that package and see this result:-

[J:\CUPS\LIB\CUPS\BACKEND]usb.exe
DEBUG: Loading USB quirks from "/cups/share/cups/usb".
DEBUG: Loaded 114 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=3
DEBUG2: Printer found with device ID: MFG:EPSON;CMD:ESCPL2,BDC,D4,D4PX,ESCPR1;MD
L:Stylus Photo RX585;CLS:PRINTER;DES:EPSON Stylus Photo RX585; Device URI: usb:/
/EPSON/Stylus%20Photo%20RX585?serial=4C3539303147044D3D&interface=1
direct usb://EPSON/Stylus%20Photo%20RX585?serial=4C3539303147044D3D&interface=1
"EPSON Stylus Photo RX585" "EPSON Stylus Photo RX585" "MFG:EPSON;CMD:ESCPL2,BDC,
D4,D4PX,ESCPR1;MDL:Stylus Photo RX585;CLS:PRINTER;DES:EPSON Stylus Photo RX585;"
 ""

[J:\CUPS\LIB\CUPS\BACKEND]


Looks like there is a problem with current usbcalls.dll/usbresmg.sys releases and cups interoperability as the older pair produce the above output which looks like it could be right.

I retried the cups admin interface "Add Printer" and the Epson is identified immediately now.

Sadly printing a test page fails.
Job 1 has the usual "not a PDF file" error and gets Cancelled.
Job 2 fails with "Unable to send data to printer".
Looks like something else is screwed up... but I have no idea what.

Job 2 seems to end with these comments in the log:-

I [04/Dec/2016:17:41:21 +0000] [Job 2] Printing page 1, 99%
D [04/Dec/2016:17:41:21 +0000] [Job 2] ATTR: job-media-progress=99
D [04/Dec/2016:17:41:21 +0000] Discarding unused job-progress event...
D [04/Dec/2016:17:41:21 +0000] Discarding unused job-progress event...
D [04/Dec/2016:17:41:21 +0000] Discarding unused printer-state-changed event...
I [04/Dec/2016:17:41:21 +0000] [Job 2] Finished page 1...
D [04/Dec/2016:17:41:21 +0000] Discarding unused job-progress event...
D [04/Dec/2016:17:41:21 +0000] Discarding unused printer-state-changed event...
D [04/Dec/2016:17:41:21 +0000] [Job 2] Gutenprint: Purging 1 row
D [04/Dec/2016:17:41:21 +0000] [Job 2] Gutenprint: ================ Done printing page 1 ================
I [04/Dec/2016:17:41:21 +0000] [Job 2] Processing page 2...
D [04/Dec/2016:17:41:21 +0000] Discarding unused job-progress event...
D [04/Dec/2016:17:41:21 +0000] Discarding unused printer-state-changed event...
I [04/Dec/2016:17:41:22 +0000] [Job 2] Rendering completed
D [04/Dec/2016:17:41:22 +0000] Discarding unused job-progress event...
D [04/Dec/2016:17:41:22 +0000] Discarding unused printer-state-changed event...
D [04/Dec/2016:17:41:22 +0000] [Job 2] Gutenprint: Ending job
I [04/Dec/2016:17:41:22 +0000] cupsdDoSelect: select() returned -1, errno = 4... pause and retry select()
D [04/Dec/2016:17:41:22 +0000] [Job 2] Gutenprint: stats 1026117B, 11.840u, 0.000s, 11.830el
D [04/Dec/2016:17:41:22 +0000] [Job 2] Gutenprint: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
D [04/Dec/2016:17:41:22 +0000] [Job 2] Gutenprint: ============================================================
D [04/Dec/2016:17:41:22 +0000] [Job 2] PID 500 (/cups/lib/cups/filter/gstoraster.exe) exited with no errors.
D [04/Dec/2016:17:41:22 +0000] [Job 2] PID 502 (/cups/lib/cups/filter/rastertogutenprint.5.2.exe) exited with no errors.
I [04/Dec/2016:17:41:22 +0000] [Job 2] Backend returned status 1 (failed)
D [04/Dec/2016:17:41:22 +0000] Discarding unused job-state-changed event...
I [04/Dec/2016:17:41:22 +0000] [Job 2] Printer stopped due to backend errors; please consult the error_log file for details.


Looking above/before those comments I see the following which looks suspiciously like the problem:-

I [04/Dec/2016:17:41:13 +0000] [Job 2] Printing page 1, 10%
D [04/Dec/2016:17:41:13 +0000] cupsdMarkDirty(---J-)
D [04/Dec/2016:17:41:13 +0000] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files"
D [04/Dec/2016:17:41:13 +0000] [Job 2] Set job-printer-state-message to "Printing page 1, 10%", current level=INFO
D [04/Dec/2016:17:41:13 +0000] [Job 2] ATTR: job-media-progress=10
D [04/Dec/2016:17:41:13 +0000] Discarding unused job-progress event...
D [04/Dec/2016:17:41:13 +0000] Discarding unused job-progress event...
D [04/Dec/2016:17:41:13 +0000] Discarding unused printer-state-changed event...
D [04/Dec/2016:17:41:13 +0000] [Job 2] Read 5944 bytes of print data...
E [04/Dec/2016:17:41:13 +0000] [Job 2] Unable to send data to printer.
D [04/Dec/2016:17:41:13 +0000] cupsdMarkDirty(---J-)
D [04/Dec/2016:17:41:13 +0000] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files"
D [04/Dec/2016:17:41:13 +0000] [Job 2] Set job-printer-state-message to "Unable to send data to printer.", current level=ERROR
D [04/Dec/2016:17:41:13 +0000] [Job 2] libusb write operation returned fffffffc.
D [04/Dec/2016:17:41:13 +0000] [Job 2] Sent 0 bytes...
D [04/Dec/2016:17:41:13 +0000] Discarding unused job-progress event...
D [04/Dec/2016:17:41:13 +0000] Discarding unused printer-state-changed event...
D [04/Dec/2016:17:41:13 +0000] [Job 2] Waiting for read thread to exit...
I [04/Dec/2016:17:41:13 +0000] cupsdDoSelect: select() returned -1, errno = 4... pause and retry select()
D [04/Dec/2016:17:41:13 +0000] [Job 2] PID 504 (/cups/lib/cups/backend/usb.exe) stopped with status 1.
I [04/Dec/2016:17:41:13 +0000] [Job 2] Printing page 1, 11%



Any ideas on cause and resolution of problem anyone?

Is anyone else seeing problems with cups and usb after applying the Arca Noae USB-11.14 update?


Regards

Pete

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: cups and usb printers
« Reply #1 on: December 05, 2016, 06:56:02 am »
The USBCALLS.DLL interface has changed (I cannot remember why, I didn't change it, I just "followed the crowd" with my USB driver set). Whatever EXE or DLL uses it (presumably libusb.dll) will need to be relinked against an updated import library for USBCALLS.DLL. I have the feeling that this has not yet happened.
The interface has changed massively and depending on what functions were used, the calling application/dll might also need to be modified (relinking might not be sufficient in this case).
You will be able to see the changes by running "exehdr /V usbcalls.dll" (exehdr.exe comes with the OS/2 toolkit) and comparing the "Exports" section of the 2 DLLs.
Maybe Paul Smedley is reading this ...

By the way: the same holds true for some apps making use of USBCALLS.DLL. After rebuilding "CAMERA.EXE" (show files from smartphones employing PTP protocol, from Rich Walsh) with an updated import library, it now also works.

Lars
« Last Edit: December 05, 2016, 07:17:09 am by Lars »

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile
Re: cups and usb printers
« Reply #2 on: December 05, 2016, 09:23:49 am »
Hi Lars and Pete,

The USBCALLS.DLL interface has changed (I cannot remember why, I didn't change it, I just "followed the crowd" with my USB driver set). Whatever EXE or DLL uses it (presumably libusb.dll) will need to be relinked against an updated import library for USBCALLS.DLL. I have the feeling that this has not yet happened.
The interface has changed massively and depending on what functions were used, the calling application/dll might also need to be modified (relinking might not be sufficient in this case).
You will be able to see the changes by running "exehdr /V usbcalls.dll" (exehdr.exe comes with the OS/2 toolkit) and comparing the "Exports" section of the 2 DLLs.
Maybe Paul Smedley is reading this ...

By the way: the same holds true for some apps making use of USBCALLS.DLL. After rebuilding "CAMERA.EXE" (show files from smartphones employing PTP protocol, from Rich Walsh) with an updated import library, it now also works.

So sounds like I need to rebuild libusb against the latest usbcalls? Where do I get the latest usbcalls.lib? From the Arca Noae driver package?

Cheers,

Paul

ivan

  • Hero Member
  • *****
  • Posts: 1558
  • Karma: +17/-0
    • View Profile
Re: cups and usb printers
« Reply #3 on: December 05, 2016, 12:13:37 pm »
That explains why TAME no longer works with our USB scanners unless we use the old USBCALLS.DLL.

Could you post the updated CAMERA.EXE because I was wondering why I now had to take the card out of my camera to download files.

Also could I ask for those that changed USBCALLS.DLL to do something about updating all the programs that rely on it to work or at least provide something that will allow those programs to work.

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: cups and usb printers
« Reply #4 on: December 05, 2016, 04:31:39 pm »
Hi Lars and Pete,

The USBCALLS.DLL interface has changed (I cannot remember why, I didn't change it, I just "followed the crowd" with my USB driver set). Whatever EXE or DLL uses it (presumably libusb.dll) will need to be relinked against an updated import library for USBCALLS.DLL. I have the feeling that this has not yet happened.
The interface has changed massively and depending on what functions were used, the calling application/dll might also need to be modified (relinking might not be sufficient in this case).
You will be able to see the changes by running "exehdr /V usbcalls.dll" (exehdr.exe comes with the OS/2 toolkit) and comparing the "Exports" section of the 2 DLLs.
Maybe Paul Smedley is reading this ...

By the way: the same holds true for some apps making use of USBCALLS.DLL. After rebuilding "CAMERA.EXE" (show files from smartphones employing PTP protocol, from Rich Walsh) with an updated import library, it now also works.

So sounds like I need to rebuild libusb against the latest usbcalls? Where do I get the latest usbcalls.lib? From the Arca Noae driver package?

Cheers,

Paul

Hi Paul. David Azariewicz should be able to provide it (I think in the USB toolkit which I think is part of the AN 11.14 USB Driver package). Alternatively it's very simple to create an Import lib on your own if you have an IBM Compiler (VAC):
run "implib.exe usbcalls.dll" on the new USBCALLS.DLL and it will create an appropriate Import library usbcalls.lib (or look "implib -?" for help).

Lars
« Last Edit: December 05, 2016, 04:39:57 pm by Lars »

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: cups and usb printers
« Reply #5 on: December 05, 2016, 04:36:57 pm »
That explains why TAME no longer works with our USB scanners unless we use the old USBCALLS.DLL.

Could you post the updated CAMERA.EXE because I was wondering why I now had to take the card out of my camera to download files.

Also could I ask for those that changed USBCALLS.DLL to do something about updating all the programs that rely on it to work or at least provide something that will allow those programs to work.

1) about TAME: let's hope it also uses libusb.dll in which case it will be fixed when libusb.dll is fixed.
2) about camera.exe: if I find the time, yes. The prob is it is not my package and contains some files with Copyright David Azariewicz (I mean the source package).
3) about the rest: You must be kidding. I propose to ask for a specific application and then let's find the guy who wrote it originally. For my "OS/2 HWManager WPS replacement class" I can say it uses the up to date USBCALLS.DLL ...


Lars


ivan

  • Hero Member
  • *****
  • Posts: 1558
  • Karma: +17/-0
    • View Profile
Re: cups and usb printers
« Reply #6 on: December 05, 2016, 05:43:52 pm »
Hi Lars,

Thanks for seeing if you can release your modified CAMERA.EXE.

I was not finger pointing directly at anyone regarding the changes in USBCALLS.DLL, just venting my frustration that things get changed and nothing is said about the changes until someone complains that some program isn't working especially when you need to use it.

We see this to some extent in the engineering/manufacturing industry where changes are made to equipment internally without notification and then it becomes almost impossible to repair older equipment.  I did advise one client to add a clause to a supply contract that should the supplier/manufacturer change anything without notification they, the supplier, became responsible for maintenance.  Our client got several new updated pieces of equipment because of that.

 

ak120

  • Guest
Re: cups and usb printers
« Reply #7 on: December 05, 2016, 06:55:32 pm »
run "implib.exe usbcalls.dll" on the new USBCALLS.DLL and it will create an appropriate Import library usbcalls.lib (or look "implib -?" for help).

I don't know which IMPLIB tool you're using. But for IBM's the command line should be:
implib usbcalls.lib usbcalls.dll
For help it's better to use "Tools Reference" section "Managing Import Libraries (IMPLIB)"

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile
Re: cups and usb printers
« Reply #8 on: December 05, 2016, 08:10:04 pm »
That explains why TAME no longer works with our USB scanners unless we use the old USBCALLS.DLL.

Could you post the updated CAMERA.EXE because I was wondering why I now had to take the card out of my camera to download files.

Also could I ask for those that changed USBCALLS.DLL to do something about updating all the programs that rely on it to work or at least provide something that will allow those programs to work.

1) about TAME: let's hope it also uses libusb.dll in which case it will be fixed when libusb.dll is fixed.
2) about camera.exe: if I find the time, yes. The prob is it is not my package and contains some files with Copyright David Azariewicz (I mean the source package).
3) about the rest: You must be kidding. I propose to ask for a specific application and then let's find the guy who wrote it originally. For my "OS/2 HWManager WPS replacement class" I can say it uses the up to date USBCALLS.DLL ...

TAME uses Sane - I should be able to rebuild Sane against the new usbcalls and/or libusb

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: cups and usb printers
« Reply #9 on: December 05, 2016, 09:43:13 pm »
Hi All

Sorry to have brought the usbcalls.dll problem into the light. However, I suspect other changes within the Arca Noae USB driver package will need to be investigated as even when using the old usbcalls.dll/usbresmg.sys printing fails with "Unable to send data to printer".

Regards

Pete

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: cups and usb printers
« Reply #10 on: December 05, 2016, 10:23:23 pm »
Hi All

Sorry to have brought the usbcalls.dll problem into the light. However, I suspect other changes within the Arca Noae USB driver package will need to be investigated as even when using the old usbcalls.dll/usbresmg.sys printing fails with "Unable to send data to printer".

Regards

Pete

What you say makes no sense to me. The USBCALLS.DLL was changed for exactly the reason to fix transfer problems (at least that's what I remember). Unless we cannot get the new USBCALLS.DLL/USBRESMG.SYS to cooperate with TAME / libusb.dll / "you name it" we will never know if all problems will not vanish into thin air.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: cups and usb printers
« Reply #11 on: December 06, 2016, 01:20:05 am »
Hi Lars

Yes, you are right, it would be much better to update libusb10.dll to work with current usbcalls/usbresmg releases.

I guess I was just a little surprised that printing failed when using the older usbcalls/usbresmg files.


Regards

Pete




Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile
Re: cups and usb printers
« Reply #12 on: December 06, 2016, 11:40:20 am »
Hi Lars

Yes, you are right, it would be much better to update libusb10.dll to work with current usbcalls/usbresmg releases.

I guess I was just a little surprised that printing failed when using the older usbcalls/usbresmg files.

Sorry, I didn't get to this tonight. Will try look at it tomorrow.

In relation to your issue with the older usb stack, I recall some issues with USB.EXE where an older version from CUPS 1.3 or so was necessary.

It may also be worth trying the rpm builds of cups.

Wim Brul

  • Sr. Member
  • ****
  • Posts: 295
  • Karma: +25/-0
    • View Profile
    • Wim's home page
Re: cups and usb printers
« Reply #13 on: December 06, 2016, 05:18:52 pm »
Since October 2013 I have been working on the implementation of isochronous transfers in USB Resource Manager. I have produced (beta test) matched sets of usbcalls.dll and usbresmg.sys that are backwards compatible. I have removed old code both in usbresmg.sys and usbcalls.dll for functions that were never properly supported. Existing synchronous transfer functions work well again and I have implemented these as asynchronous too. I have added code for the new asynchronous isochronous transfer functions. All of my changes have found their way into the Arca Noae and Lars Erdmann usb driver sets. 

There is no need for existing applications to be relinked. During regression testing both PtPro110 and Camera15 did not find an attached ptp camera. Both programs were updated to increase their UsbQueryDeviceReport report buffer size from 1024 to 4096 bytes. This was necessary to cater for usb devices with large compound descriptors. Otherwise no ptp camera would be found at all when such a device was present. In addition PtPro110 was updated to have its CloseSession routine not passing 1 parameter which it shouldn't.  The updated applications ptpro111.zip and camera153.zip are available on hobbes. 




Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: cups and usb printers
« Reply #14 on: December 06, 2016, 06:54:53 pm »
Some ordinals of new functions overlay ordinals of old functions (most notably ordinal 4 that now offers a function that did not exist before).
I can only say that I had to relink cameraderie with an updated import libary for usbcalls.dll.

To make it more clear, there the library from: http://en.ecomstation.ru/projects/usbtools/download/usbcalls-20060807.zip
Code: [Select]
Library:                        usbcalls
Description:                    USB Interface DLL - (c) Froloff&Son 2006

Module type:                    Dynamic link library
                                Per-process initialization
                                Per-process termination
Number of memory pages:         00000002 (2)
Initial CS:EIP:                 object 1 offset 00000000
Initial SS:ESP:                 object 0 offset 00000000
Automatic data object:          2
And "exehdr usbcalls.dll | find " 4"" results in:
Code: [Select]
   4    1  000011e6  UsbIsoStart        exported, shared data
For the latest usbcalls.dll (in this case my build, but David's is exactly the same):
Code: [Select]
Library:                        USBCALLS
Description:                    @#Lars Erdmann:10.211#@##1## 14 Nov 2016 22:30:23     Laptop    ::::::@@USBCALLS DLL for OS/2 (c) 2015 Lars Erdmann

Module type:                    Dynamic link library
                                Per-process initialization
                                Per-process termination
                                NO internal fixups in executable image
Number of memory pages:         00000008 (8)
Initial CS:EIP:                 object 1 offset 00003876
Initial SS:ESP:                 object 0 offset 00000000
Automatic data object:          2
And "exehdr usbcalls.dll | find " 4"" results in:
Code: [Select]
   4    1  0000101e  UsbQueryDeviceInfo exported
where "UsbQueryDeviceInfo" is a function that is completely new and never existed in the old DLL.

To crosscheck with Wim's DLL:
Code: [Select]
Library:                        USBCALLS
Description:                    @#W.M.Brul:14.20150630#@USBCALLS

Module type:                    Dynamic link library
                                Per-process initialization
                                Per-process termination
Number of memory pages:         0000000c (12)
Initial CS:EIP:                 object 1 offset 00000000
Initial SS:ESP:                 object 0 offset 00000000
Automatic data object:          2
and "exehdr.exe usbcalls.dll | find " 4" results in:
Code: [Select]
   4    1  000025e2  UsbQueryDeviceInfo exported
I can say that David's, Wim's and my version of USBCALLS.DLL are exactly the same from a binary interface point of view (and also otherwise).

In short: sticking to one and the same ordinal of "4" for two different functions broke the binary compatibility between the DLL from Froloff (2006) and the new version.


Lars


« Last Edit: December 07, 2016, 07:54:59 am by Lars »