• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Test results needed from USB connected HP Printers

Started by Paul Smedley, 2012.02.09, 12:46:09

Previous topic - Next topic

Paul Smedley

Hi,

In order to help hplip-os2 development, I need some test results from hp-mkuri from usb connected HP printers or MFPs.

Please download http://smedley.id.au/hp-mkuri.zip and execute:
hp-mkuri.exe -o

Send me the screen output (if any) and also libusb.log

My HP MFP gives no screen output, and libusb.log shows 'unable to send control message - rc= 280'

Thanks,

Paul

ivan

Hi Paul,

Will this work with USB printers attached to a print server or must they be direct connected?

ivan

Paul Smedley

Quote from: ivan on 2012.02.09, 18:31:36
Hi Paul,

Will this work with USB printers attached to a print server or must they be direct connected?

ivan

Hi Ivan,

I have hplip working over a network connection for both printing and scanning.

The purpose of the above testing is to determine if my printer detection issue when directly connected via USB is local or more widespread.

So to be more specific - no, I don't need results when tested over a connection using a print server.

It would be interesting though to see if hp-mkuri can detect the printer, using the following syntax:
hp-mkuri -i aaa.bbb.ccc.ddd

Where aaa.bbb.ccc.ddd is the IP address of the print server

Cheers,

Paul

Paul Smedley

Unfortunately it seems there are some issues with usbresmg.sys

With most of my USB devices, usbres reports a string error and in the device report, under strings, shows things like:
GetString Error -225 for Manufacturer Name, Product Name and Serial number.

An older Canon Lide scanner works ok and displays the correct information.

Unless I can get the source to usbresmg, it seems unlikely I'll be able to get hplip to work with USB devices :(

wimpie

Quote from: Paul Smedley on 2012.02.10, 03:43:54
Unfortunately it seems there are some issues with usbresmg.sys

With most of my USB devices, usbres reports a string error and in the device report, under strings, shows things like:
GetString Error -225 for Manufacturer Name, Product Name and Serial number.

An older Canon Lide scanner works ok and displays the correct information.

Unless I can get the source to usbresmg, it seems unlikely I'll be able to get hplip to work with USB devices :(
Hi Paul,

Is it possible that these strings (iManufacturer, iProduct, iSerialNumber) are not present in these devices? A lot of USB devices don't contain these strings. Or may be you used an improper language code?

It is most likely that you did not use the language code. I have done some testing obtaining these strings with my usbecd.sys device driver and some devices always return these strings even when the language code has not been specified in the setup packet. Others return an error to my device driver when the language code has not been specified. This language code must first have been obtained from the device and then subsequently be provided in the wIndex field of the setup packet when you query the device for the length of the string and when you obtain the string.

Can you see these with usbres.exe  "View device Report" (use right mouse button followed by left mouse button)? Or did you do just that? I get "Manufacturer Name : Not implemented" when that string is not there.

Wim.

Paul Smedley

Hi Wim,

Sorry if I wasn't clear.

The devices I'm testing definitely have the string present for at least some of the fields - lspci on linux confirms that.

At first I thought the problem was related to libusb/usbcalls however the device report from usbresmg.sys also shows the string error

You are probably right about the language code - perhaps usbresmg.sys needs to be modified to support this.

Cheers

Paul

rudi

Quote from: Paul Smedley on 2012.02.10, 22:27:20
The devices I'm testing definitely have the string present for at least some of the fields - lspci on linux confirms that.
At first I thought the problem was related to libusb/usbcalls however the device report from usbresmg.sys also shows the string error

I've seen that before. I seem to remember, that it happened on some devices, that were already claimed/initialized by other drivers (USBKBD, USBMOUSE). Could it be that you have USBPRT loaded and that this driver feels responsible for your printer ? Or is the printer in reality a multifunction device that is partially handled by existing device drivers ?


Radek

HP LJ1200 connected to USB here:

LIBUSB: unable to query number of USB devices - rc= 1b58

Well, Sony Vaio: Everything connected to USB that should work also works (printer, all three mouses, CD drive, USB sticks) but usbres complains "no USB driver found". usbcfg works, 6 UHCI, 2 EHCI, 1 mass storage, 1 printer. The printer is connected to LPT1 redirected to USB and it was on line while testing. Also, I made sure that it really works by printing some nonsense. RC6a.

Paul Smedley

Quote from: Radek on 2012.02.11, 09:26:05
HP LJ1200 connected to USB here:

LIBUSB: unable to query number of USB devices - rc= 1b58

Well, Sony Vaio: Everything connected to USB that should work also works (printer, all three mouses, CD drive, USB sticks) but usbres complains "no USB driver found". usbcfg works, 6 UHCI, 2 EHCI, 1 mass storage, 1 printer. The printer is connected to LPT1 redirected to USB and it was on line while testing. Also, I made sure that it really works by printing some nonsense. RC6a.

Is usbresmg.sys installed?

Paul Smedley

Hi Rudi,

Quote from: rudi on 2012.02.11, 01:07:03
Quote from: Paul Smedley on 2012.02.10, 22:27:20
The devices I'm testing definitely have the string present for at least some of the fields - lspci on linux confirms that.
At first I thought the problem was related to libusb/usbcalls however the device report from usbresmg.sys also shows the string error

I've seen that before. I seem to remember, that it happened on some devices, that were already claimed/initialized by other drivers (USBKBD, USBMOUSE). Could it be that you have USBPRT loaded and that this driver feels responsible for your printer ? Or is the printer in reality a multifunction device that is partially handled by existing device drivers ?

I liked your idea a lot - however even after removing the OS/2 drivers for msd, printers, mice and keyboards, the behaviour of usbres in terms of string failure are the same.

Paul Smedley

Quote from: Paul Smedley on 2012.02.10, 22:27:20
You are probably right about the language code - perhaps usbresmg.sys needs to be modified to support this.

An addition - usbres.exe shows the HP MFP has 0 # Languages, and LangIds is empty....

A device that works shows 1 as # Languages, and LangIds = 1033

So it looks like Wim is 100% correct...

Now to work out why and fix it :)

wimpie

Quote from: Paul Smedley on 2012.02.11, 10:19:50
Quote from: Paul Smedley on 2012.02.10, 22:27:20
You are probably right about the language code - perhaps usbresmg.sys needs to be modified to support this.

An addition - usbres.exe shows the HP MFP has 0 # Languages, and LangIds is empty....

A device that works shows 1 as # Languages, and LangIds = 1033

So it looks like Wim is 100% correct...

Now to work out why and fix it :)

Hi Paul,

From USB 1.1 spec chapter 9.6.5:  String descriptors are optional. A device that does not support string descriptors within device, configuration and interface descriptors must have all references to string descriptors be set to zero. USB devices that omit all string descriptors shall not return an array of LANGID codes.

So to me it is valid what the HP MFP (whatever that is?) does. However it is not clear to me what you want to fix. I suppose it is in your own code (that you are porting) that you encountered this problem. I don't think that usbresmg.sys needs to be fixed. It must be done at application level. May be usbres.exe needs to fixed as well.

Wim.

Radek

Oops, usbresmg wasn't installed. Now it is

Paul Smedley

Hi Wim,

Quote from: wimpie on 2012.02.11, 14:58:00
Quote from: Paul Smedley on 2012.02.11, 10:19:50
Quote from: Paul Smedley on 2012.02.10, 22:27:20
You are probably right about the language code - perhaps usbresmg.sys needs to be modified to support this.

An addition - usbres.exe shows the HP MFP has 0 # Languages, and LangIds is empty....

A device that works shows 1 as # Languages, and LangIds = 1033

So it looks like Wim is 100% correct...

Now to work out why and fix it :)

Hi Paul,

From USB 1.1 spec chapter 9.6.5:  String descriptors are optional. A device that does not support string descriptors within device, configuration and interface descriptors must have all references to string descriptors be set to zero. USB devices that omit all string descriptors shall not return an array of LANGID codes.

So to me it is valid what the HP MFP (whatever that is?) does. However it is not clear to me what you want to fix. I suppose it is in your own code (that you are porting) that you encountered this problem. I don't think that usbresmg.sys needs to be fixed. It must be done at application level. May be usbres.exe needs to fixed as well.

Yes I know the langid string is optional, but in this case, even in the absence (or inability to detect it) of the language string, the strings ARE present.

For the device, usbres shows:
Has Index 1|Getstring Error -225

linux can see the device strings

usbres shows 'Not Implemented' for devices with no strings present

Paul Smedley

#14
Quote from: Radek on 2012.02.11, 16:37:28
Oops, usbresmg wasn't installed. Now it is

I'm wondering if hp-mkuri needs some files from hplip in order to correctly detect the printer... there are no obvious errors in your log, but I'm presuming hp-mkuri showed no output?

what about trying:
hp-mkuri -b 1 -d 4

This tells it to look on usb bus 1, and at device 4 (your HP device appears to be device #4)

Also, please start syslogd before testing - I think this is part of at least eCS 2.0.

After running hp-mkuri, close syslogd and check %ETC%\syslog.msg for debug messages.