OS/2, eCS & ArcaOS - Technical > Setup & Installation

libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here

<< < (2/3) > >>

Lars:
No the bus number change is intentional.
It used to be hard coded to 1, now it is taking the host controller number (which effectively is the bus number).
The second number is the device number. That should be > 1 though (I am not sure,I forgot). in any case, that is purely cosmetic and not the problem. If someone could send me an exceptq report, that could help to fix the problem.
The other thing that you could do is to do a "SET LIBUSB_DEBUG=255" and pipe stderr to a file. That'll give detailed info of what Libusb is doing.

Dariusz Piatkowski:
Hi Lars!


--- Quote from: Lars on September 05, 2022, 10:38:29 pm ---No the bus number change is intentional.
It used to be hard coded to 1, now it is taking the host controller number (which effectively is the bus number).
The second number is the device number. That should be > 1 though (I am not sure,I forgot). in any case, that is purely cosmetic and not the problem. If someone could send me an exceptq report, that could help to fix the problem...
--- End quote ---

Hmm...very good, well, at least it's reassuring to know this isn't some kind of un-known that I've ran into.

So here is the output of 'usbtree':


--- Code: ---[G:\]usbtree
USB driver version = 12.13
----- USB device tree ---------
DS 0808=7814

Controller 0: USBEHCD$
Root Hub 0 (5 ports) 1002:4396
Cannot find hub

Controller 0: USBEHCD$
Root Hub 1 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 2 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 3 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 4 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 5 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 6 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 7 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 8 (0 ports) 1002:4396

--- End code ---

...and I've attached a quick screenshot of the Hadware Manager window showing the HP Scanner and the remaining USB ports.


--- Quote from: Lars on September 05, 2022, 10:38:29 pm ---...The other thing that you could do is to do a "SET LIBUSB_DEBUG=255" and pipe stderr to a file. That'll give detailed info of what Libusb is doing.

--- End quote ---

I've attached the sane LOG files I was attempting to u/l to the GitHub ticket. The TRP file is in there as well.

Now, here is an interesting part that I had ran into, found the following lines in my CONFIG.SYS:


--- Code: ---SET SANE_CONFIG_DIR=g:\etc\sane.d
SET SANE_DEFAULT_DEVICE=hp:libusb:001:001

SET SANE_DEBUG_HPAIO=4
SET SANE_DEBUG_HP=4
SET SANE_DEBUG_SANEI_USB=4
SET SANE_DEBUG_DLL=4

--- End code ---

...and now I suspect that the "SET SANE_DEFAULT_DEVICE=hp:libusb:001:001" is the actual PROBLEM here!!!

There is a reason why I had set this up...I did this at the time that I moved to RPM based SANE setup, previously I had a separate ZIP based install.

Soooo....let me take a shot at this by figuring out why I would have used that SET statement and then re-running with the latest USBLIB1 1.0.24 drop to see if that's perhaps what has caused the problem.

Damn...nice...thank you for asking the questions...normally I look through CONFIG.SYS to rule out any of such customizations, but clearly in this case I missed that step.

Lars:
Additionally,
Libusb makes use of USBCALLS.
Have you tried to revert back to older USB drivers and see if that makes a difference?

Lars:
You already gave the answer: the device is correctly detected at 3:1 but you are forcing to 1:1.
With unpredictable consequences.

Lars:
...plus
the output of usbtree does not line up with what the HW manager shows. Just look at the vid:pid for the hubs.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version