OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: Pete on December 04, 2016, 10:37:21 pm

Title: cups and usb printers
Post by: Pete 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
Title: Re: cups and usb printers
Post by: Lars 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
Title: Re: cups and usb printers
Post by: Paul Smedley 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
Title: Re: cups and usb printers
Post by: ivan 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.
Title: Re: cups and usb printers
Post by: Lars 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
Title: Re: cups and usb printers
Post by: Lars 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

Title: Re: cups and usb printers
Post by: ivan 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.

 
Title: Re: cups and usb printers
Post by: ak120 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)"
Title: Re: cups and usb printers
Post by: Paul Smedley 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
Title: Re: cups and usb printers
Post by: Pete 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
Title: Re: cups and usb printers
Post by: Lars 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.
Title: Re: cups and usb printers
Post by: Pete 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



Title: Re: cups and usb printers
Post by: Paul Smedley 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.
Title: Re: cups and usb printers
Post by: Wim Brul 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. 



Title: Re: cups and usb printers
Post by: Lars 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


Title: Re: cups and usb printers
Post by: Paul Smedley on December 07, 2016, 09:51:07 am
rebuilt libusb10.dll is at http://smedley.id.au/tmp/libusb-20161207.zip

This is built against the latest usbcalls toolkit from http://trac.netlabs.org/usb

Note I haven't tested this, I have no time today.

Cheers,

Paul
Title: Re: cups and usb printers
Post by: Pete on December 07, 2016, 10:35:38 pm
Hi Paul

Happy to report that the new libusb10.dll seems to have done the trick and my usb printer has just churned out the cups test page.

Thanks.

Pete
Title: Re: cups and usb printers
Post by: Paul Smedley on December 08, 2016, 03:16:47 am
Hi Pete,

Happy to report that the new libusb10.dll seems to have done the trick and my usb printer has just churned out the cups test page.

Great - I'll work on getting an updated libusb10.dll added to my site. I'll probably need to add a disclaimer around usbresmg.sys/usbcalls.dll dates around which build should be used....

Cheers,

Paul
Title: Re: cups and usb printers
Post by: Wim Brul on December 08, 2016, 12:32:24 pm
Hi Pete,

Happy to report that the new libusb10.dll seems to have done the trick and my usb printer has just churned out the cups test page.

Great - I'll work on getting an updated libusb10.dll added to my site. I'll probably need to add a disclaimer around usbresmg.sys/usbcalls.dll dates around which build should be used....

Cheers,

Paul

Hallo Paul and Pete,

I installed this new libusb10.dll on my laptop and it works as well for me as the one that I had before. The only difference that I noted is that the new one has debug logging enabled whereas the older one has not. I do not have a usb printer, but I can scan with my CanoScan LIDE 210 scanner and lsusb.exe works too.

LIBUSB10.DLL - 25-05-2013 11:20:28 <- libusb-1.0.16-rc6-20130525.zip
LIBUSB10.DLL - 07-12-2016 09:49:08 <- libusb-20161207.zip

This makes me wonder what version Pete had on his system and where it came from.

Regards,

Wim         
Title: Re: cups and usb printers
Post by: Lars on December 08, 2016, 05:45:25 pm
rebuilt libusb10.dll is at http://smedley.id.au/tmp/libusb-20161207.zip

This is built against the latest usbcalls toolkit from http://trac.netlabs.org/usb

Note I haven't tested this, I have no time today.

Cheers,

Paul

Hi Paul,

now that we know that this Version of libusb10.dll works just fine, are you also going to put it in the AN rpm repo ?
I just don't want that piece of SW getting lost ...

Lars
Title: Re: cups and usb printers
Post by: Silvan Scherrer on December 08, 2016, 06:17:51 pm
rebuilt libusb10.dll is at http://smedley.id.au/tmp/libusb-20161207.zip

This is built against the latest usbcalls toolkit from http://trac.netlabs.org/usb

Note I haven't tested this, I have no time today.

Cheers,

Paul

Hi Paul,

now that we know that this Version of libusb10.dll works just fine, are you also going to put it in the AN rpm repo ?
I just don't want that piece of SW getting lost ...

Lars
Lars the rpm version is since longer linked correct. We plan to update it to the latest libusb version and also check in the source.

regards
Silvan
Title: Re: cups and usb printers
Post by: Lars on December 09, 2016, 12:49:15 am
Thanks !
Title: Re: cups and usb printers
Post by: Pete on December 09, 2016, 04:53:21 am
Hi Paul

The current usbcalls.dll/usbresmg.sys:-

25-03-16  5:30p        28,046      0 a---  USBRESMG.SYS
25-03-16  5:30p        36,205    226 a---  USBCALLS.DLL

The above are part of the Arca Noae USB-11.14 package. Updated versions of these files were also included in the Arca Noae USB-11.13 package so may also need the later libusb10.dll


Regards

Pete
Title: Re: cups and usb printers
Post by: Pete on December 09, 2016, 04:55:45 am
Hi Wim

I believe I was using this package ftp://ftp.netlabs.org/pub/ecups/install/libusbdll10.wpi - original link on http://trac.netlabs.org/ecups/wiki/CupsPort - which contains:-

25-05-13  6:20p        45,790    230 a---  libusb10.dll

The version listed in the wpi file is 1.0.16.1

Same date as the version in libusb-1.0.16-rc6-20130525.zip but different time. Is the file size different?


Regards

Pete
Title: Re: cups and usb printers
Post by: Pete on December 09, 2016, 05:00:06 am
Hi All

The replacement printhead for my Canon MG7550 has arrived and is installed and working. So, it's goodbye to usb printing again - until next time I need an emergency printer  :-)


Regards

Pete
Title: Re: cups and usb printers
Post by: Paul Smedley on December 09, 2016, 09:15:41 am
Hi Lars,

rebuilt libusb10.dll is at http://smedley.id.au/tmp/libusb-20161207.zip

This is built against the latest usbcalls toolkit from http://trac.netlabs.org/usb

Note I haven't tested this, I have no time today.


now that we know that this Version of libusb10.dll works just fine, are you also going to put it in the AN rpm repo ?
I just don't want that piece of SW getting lost ...

I didn't build the version in the rpm repo...... My only builds are on my site and in the link in this thread.... I presume it's based on my source in the netlabs USB repository but who knows....
Title: Re: cups and usb printers
Post by: Wim Brul on December 09, 2016, 12:35:44 pm
Hi Pete,

Hi Wim

I believe I was using this package ftp://ftp.netlabs.org/pub/ecups/install/libusbdll10.wpi - original link on http://trac.netlabs.org/ecups/wiki/CupsPort - which contains:-

25-05-13  6:20p        45,790    230 a---  libusb10.dll

The version listed in the wpi file is 1.0.16.1

Same date as the version in libusb-1.0.16-rc6-20130525.zip but different time. Is the file size different?


Regards

Pete

Thanks for reporting back. I compared both files. Their size and binary content are the same. Only the time appears to be different.

Regards,

Wim
Title: Re: cups and usb printers
Post by: Pete on December 09, 2016, 09:20:41 pm
Hi Wim

If you think the older libusb10.dll should have worked with the latest usbcalls.dll/usbresmg.sys then I am not going to argue - simply state that it did not work here.

It can join another great mystery:

My system cannot boot, delivering the "OS/2 is unable to operate.." message, when using the current os2ahci.add 1.32 supplied by Arca Noae and an eSATA drive is attached. If I change the os2ahci.add driver to the 1.32 build supplied with ecS2.2beta2 the system has no problem booting with the eSATA drive attached.

I am told that the only difference between the 2 versions of the 1.32 release is the buildlevel signature...


Regards

Pete