Hi all,
in accordance with the thread
http://www.osronline.com/showThread.CFM?link=188734
I wanted to know how can i support Dot4 IEEE 1284.4 in my virtual USB bus
driver.
Thanks
dennis scott
Your USB bus driver is *theoretically* agnostic to the higher level
presentation protocols used by devices such as printers. So as long as you
are providing a conformant transfer mechanism everything should just work,
where work means you are delivering the bits correctly to whatever print
device is on the other end.
Tracing the urb transfer requests/responses and comparing them to a real
system should at least give you a clue as to exactly what is going wrong.
Are there IOCTLs or URBs arriving at your emulation layer that you are not
supporting? If you could pinpoint exactly where the print operation fails
that would help root cause the problem.
In your other thread you asked if you needed to emulate a hub device. The
answer is that some device stacks like to talk to their hubs and
consequently you will eventually need to support some or all of the HUB
IOCTLs and an addressable object that correlates to a HUB device. You could
replicate the windows USB architecture exactly, or it is also possible to
simply incorporate HUB functionality into the adapter device. If there is no
evidence that HUB IOCTL failure is associated with your print failures then
I wouldn’t worry about this issue.
Mark Roddy
On Tue, Aug 24, 2010 at 6:51 AM, Dennis Scott
wrote:
> Hi all,
>
> in accordance with the thread
>
> http://www.osronline.com/showThread.CFM?link=188734
>
> I wanted to know how can i support Dot4 IEEE 1284.4 in my virtual USB bus
> driver.
>
> Thanks
> dennis scott
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Mark,
Below are the IRP/IOCTL’s i am (bus) getting from the point of
initialisation to setup complete.
IRP_MN_QUERY_DEVICE_RELATIONS
IRP_MN_QUERY_ID
IRP_MN_QUERY_CAPABILITIES
IRP_MN_QUERY_DEVICE_TEXT
IRP_MN_QUERY_DEVICE_TEXT
IRP_MN_QUERY_ID (3 times for instance, hardware and compatibility id)
IRP_MN_QUERY_RESOURCE_REQUIREMENTS
IRP_MN_QUERY_BUS_INFORMATION
IRP_MN_QUERY_RESOURCES
IRP_MN_QUERY_INTERFACE
IRP_MN_QUERY_LEGACY_BUS_INFORMATION
IRP_MN_FILTER_RESOURCE_REQUIREMENTS
IRP_MN_START_DEVICE
IRP_MN_QUERY_CAPABILITIES
IOCTL_INTERNAL_USB_SUBMIT_URB
URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE
URB_FUNCTION_SELECT_CONFIGURATION
URB_FUNCTION_CLASS_INTERFACE
“non of the above IRP/IOCTL’s are failed”
every IOCLT’s untill this point are same with respect to test system, after
this i ll not get any IOCTL’s and the printer device will be installed and i
can see the printer in online state in printer and faxes.
I am not able to figure out what is the problem, are other IOCTL’s are
intended to HUB?
On Tue, Aug 24, 2010 at 6:00 PM, Mark Roddy wrote:
> Your USB bus driver is theoretically agnostic to the higher level
> presentation protocols used by devices such as printers. So as long as you
> are providing a conformant transfer mechanism everything should just work,
> where work means you are delivering the bits correctly to whatever print
> device is on the other end.
>
> Tracing the urb transfer requests/responses and comparing them to a real
> system should at least give you a clue as to exactly what is going wrong.
> Are there IOCTLs or URBs arriving at your emulation layer that you are not
> supporting? If you could pinpoint exactly where the print operation fails
> that would help root cause the problem.
>
> In your other thread you asked if you needed to emulate a hub device. The
> answer is that some device stacks like to talk to their hubs and
> consequently you will eventually need to support some or all of the HUB
> IOCTLs and an addressable object that correlates to a HUB device. You could
> replicate the windows USB architecture exactly, or it is also possible to
> simply incorporate HUB functionality into the adapter device. If there is no
> evidence that HUB IOCTL failure is associated with your print failures then
> I wouldn’t worry about this issue.
>
> Mark Roddy
>
>
> On Tue, Aug 24, 2010 at 6:51 AM, Dennis Scott > > wrote:
>
>> Hi all,
>>
>> in accordance with the thread
>>
>> http://www.osronline.com/showThread.CFM?link=188734
>>
>> I wanted to know how can i support Dot4 IEEE 1284.4 in my virtual USB bus
>> driver.
>>
>> Thanks
>> dennis scott
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
After the class interface URB there should be a series of PNP requests to
the PDO querying its PNP state.
Other than that everything is the same as a normal sequence of events. My
guess is that you are not processing the class or vendor request correctly,
even though you are not seeing an error from the other end.
As usual, a physical usb analyzer might help.
Mark Roddy
On Tue, Aug 24, 2010 at 8:53 AM, Dennis Scott
wrote:
> URB_FUNCTION_CLASS_INTERFACE
Dennis Scott wrote:
Mark,
Below are the IRP/IOCTL’s i am (bus) getting from the point of
initialisation to setup complete.IRP_MN_QUERY_DEVICE_RELATIONS
IRP_MN_QUERY_ID
IRP_MN_QUERY_CAPABILITIES
IRP_MN_QUERY_DEVICE_TEXT
IRP_MN_QUERY_DEVICE_TEXT
IRP_MN_QUERY_ID (3 times for instance, hardware and compatibility id)
IRP_MN_QUERY_RESOURCE_REQUIREMENTS
IRP_MN_QUERY_BUS_INFORMATION
IRP_MN_QUERY_RESOURCES
IRP_MN_QUERY_INTERFACE
That’s probably the cause. IRP_MN_QUERY_INTERFACE allows two drivers to
create a private interface. The lower driver returns a set of function
pointers (like a COM interface or a pure virtual C++ class). The upper
driver can then call those functions directly, without using IRPs.
You’d have to check which interface is being requested, and then hope
the interface is listed in one of the DDK header files so you can figure
out how to reverse engineer it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Oh that’s a good point. USB adapters have to support
USB_BUSIF_USBDI_VERSION_0/1/2/3 see usbbusif.h in inc\ddk
Mark Roddy
On Tue, Aug 24, 2010 at 5:21 PM, Tim Roberts wrote:
> IRP_MN_QUERY_INTERFACE
In my driver i have implemented USB_BUSIF_USBDI_VERSION_1 interface.
Tim: i didn’t understand below statement of yours can you explain it to me?
“You’d have to check which interface is being requested, and then hope
the interface is listed in one of the DDK header files so you can figure
out how to reverse engineer it.”
On Wed, Aug 25, 2010 at 3:06 AM, Mark Roddy wrote:
> Oh that’s a good point. USB adapters have to support
>
> USB_BUSIF_USBDI_VERSION_0/1/2/3 see usbbusif.h in inc\ddk
>
> Mark Roddy
>
>
> On Tue, Aug 24, 2010 at 5:21 PM, Tim Roberts wrote:
>
>> IRP_MN_QUERY_INTERFACE
>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Tim: I think i understood your statement,
In query interface the GUID i got is “924A156C-CFAA-D011-8D2A-00A0C906B244”
which is not the
USB_BUS_INTERFACE_USBDI_GUID(B1A96A13-3DE0-4574-9B01-C08FEAB318D6), and i am
not able to locate this guid value in header files.
i got GUID using following code:
irpStack = IoGetCurrentIrpStackLocation(Irp);
interfaceType = (GUID *) irpStack->Parameters.QueryInterface.InterfaceType;
for(i=0;i{
RtlStringCchPrintfA(buf+2*i, 3, “%02X”, ((unsigned char
)interfaceType+i));
}
KdPrint((“Query GUID: %s\n”,buf));
what the above GUID corresponds to? vendor specific???
dennis scott
On Wed, Aug 25, 2010 at 10:04 AM, Dennis Scott
wrote:
> In my driver i have implemented USB_BUSIF_USBDI_VERSION_1 interface.
>
> Tim: i didn’t understand below statement of yours can you explain it to me?
>
>
> “You’d have to check which interface is being requested, and then hope
> the interface is listed in one of the DDK header files so you can figure
> out how to reverse engineer it.”
>
> On Wed, Aug 25, 2010 at 3:06 AM, Mark Roddy wrote:
>
>> Oh that’s a good point. USB adapters have to support
>>
>> USB_BUSIF_USBDI_VERSION_0/1/2/3 see usbbusif.h in inc\ddk
>>
>> Mark Roddy
>>
>>
>> On Tue, Aug 24, 2010 at 5:21 PM, Tim Roberts wrote:
>>
>>> IRP_MN_QUERY_INTERFACE
>>
>>
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
Dennis Scott wrote:
Tim: I think i understood your statement,
In query interface the GUID i got is
“924A156C-CFAA-D011-8D2A-00A0C906B244” which is not the
USB_BUS_INTERFACE_USBDI_GUID(B1A96A13-3DE0-4574-9B01-C08FEAB318D6),
and i am not able to locate this guid value in header files.i got GUID using following code:
irpStack = IoGetCurrentIrpStackLocation(Irp);
interfaceType = (GUID *)
irpStack->Parameters.QueryInterface.InterfaceType;for(i=0;i> {
> RtlStringCchPrintfA(buf+2*i, 3, “%02X”, *((unsigned char
> *)interfaceType+i));
> }
> KdPrint((“Query GUID: %s\n”,buf));
>
> what the above GUID corresponds to? vendor specific???
Have you really never looked in to how you correctly print a GUID? The
way you’re doing it is not correct. The first four bytes are printed as
a single dword, the next two are a word, the next two are word, and only
then do you print a byte at a time. What you have there is
6C154A92-AACF-11D9-8D2A-00A0C906B244, which is present in the DDK as
GUID_TRANSLATOR_INTERFACE_STANDARD
I don’t know what that means. How are you handling this?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Usb devices, including usb printers, work fine without whatever
GUID_TRANSLATOR_INTERFACE_STANDARD is. It has nothing to do with usb
adapters, virtual or otherwise.
So I don’t think the OPs problem is lack of query interface support. More
than likely it is back to how he is processing class or vendor requests.
Having implemented a virtual usb adapter, I do recall that this set of
requests were rather easy to get wrong.
Mark Roddy
On Wed, Aug 25, 2010 at 12:36 PM, Tim Roberts wrote:
> Dennis Scott wrote:
> > Tim: I think i understood your statement,
> >
> > In query interface the GUID i got is
> > “924A156C-CFAA-D011-8D2A-00A0C906B244” which is not the
> > USB_BUS_INTERFACE_USBDI_GUID(B1A96A13-3DE0-4574-9B01-C08FEAB318D6),
> > and i am not able to locate this guid value in header files.
> >
> > i got GUID using following code:
> >
> > irpStack = IoGetCurrentIrpStackLocation(Irp);
> >
> > interfaceType = (GUID )
> > irpStack->Parameters.QueryInterface.InterfaceType;
> >
> > for(i=0;i> > {
> > RtlStringCchPrintfA(buf+2i, 3, “%02X”, *((unsigned char
> > *)interfaceType+i));
> > }
> > KdPrint((“Query GUID: %s\n”,buf));
> >
> > what the above GUID corresponds to? vendor specific???
>
> Have you really never looked in to how you correctly print a GUID? The
> way you’re doing it is not correct. The first four bytes are printed as
> a single dword, the next two are a word, the next two are word, and only
> then do you print a byte at a time. What you have there is
> 6C154A92-AACF-11D9-8D2A-00A0C906B244, which is present in the DDK as
> GUID_TRANSLATOR_INTERFACE_STANDARD
>
> I don’t know what that means. How are you handling this?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
OK, Thanks Tim for the clarification.
Mark: So this turn out to be problem in handling class or vendor requests,
what exactly i have to take care while handling this request??
On Thu, Aug 26, 2010 at 12:31 AM, Mark Roddy wrote:
> Usb devices, including usb printers, work fine without whatever
> GUID_TRANSLATOR_INTERFACE_STANDARD is. It has nothing to do with usb
> adapters, virtual or otherwise.
>
> So I don’t think the OPs problem is lack of query interface support. More
> than likely it is back to how he is processing class or vendor requests.
> Having implemented a virtual usb adapter, I do recall that this set of
> requests were rather easy to get wrong.
>
> Mark Roddy
>
>
> On Wed, Aug 25, 2010 at 12:36 PM, Tim Roberts wrote:
>
>> Dennis Scott wrote:
>> > Tim: I think i understood your statement,
>> >
>> > In query interface the GUID i got is
>> > “924A156C-CFAA-D011-8D2A-00A0C906B244” which is not the
>> > USB_BUS_INTERFACE_USBDI_GUID(B1A96A13-3DE0-4574-9B01-C08FEAB318D6),
>> > and i am not able to locate this guid value in header files.
>> >
>> > i got GUID using following code:
>> >
>> > irpStack = IoGetCurrentIrpStackLocation(Irp);
>> >
>> > interfaceType = (GUID )
>> > irpStack->Parameters.QueryInterface.InterfaceType;
>> >
>> > for(i=0;i>> > {
>> > RtlStringCchPrintfA(buf+2i, 3, “%02X”, *((unsigned char
>> > *)interfaceType+i));
>> > }
>> > KdPrint((“Query GUID: %s\n”,buf));
>> >
>> > what the above GUID corresponds to? vendor specific???
>>
>> Have you really never looked in to how you correctly print a GUID? The
>> way you’re doing it is not correct. The first four bytes are printed as
>> a single dword, the next two are a word, the next two are word, and only
>> then do you print a byte at a time. What you have there is
>> 6C154A92-AACF-11D9-8D2A-00A0C906B244, which is present in the DDK as
>> GUID_TRANSLATOR_INTERFACE_STANDARD
>>
>> I don’t know what that means. How are you handling this?
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
I would invest in a usb line analyzer. I spent a lot of time not investing
in a usb line analyzer to figure out how I was getting these requests wrong.
I had no choice in the matter at the time. I don’t recall the exact
details, and as the interface between my virtual bus and the remote real bus
is proprietary it probably is not exactly relevant how I got the bits wrong,
but I did and the results were “nice printer device does nothing”.
Mark Roddy
On Thu, Aug 26, 2010 at 12:21 AM, Dennis Scott
wrote:
> OK, Thanks Tim for the clarification.
>
> Mark: So this turn out to be problem in handling class or vendor requests,
> what exactly i have to take care while handling this request??
>
> On Thu, Aug 26, 2010 at 12:31 AM, Mark Roddy wrote:
>
>> Usb devices, including usb printers, work fine without whatever
>> GUID_TRANSLATOR_INTERFACE_STANDARD is. It has nothing to do with usb
>> adapters, virtual or otherwise.
>>
>> So I don’t think the OPs problem is lack of query interface support. More
>> than likely it is back to how he is processing class or vendor requests.
>> Having implemented a virtual usb adapter, I do recall that this set of
>> requests were rather easy to get wrong.
>>
>> Mark Roddy
>>
>>
>> On Wed, Aug 25, 2010 at 12:36 PM, Tim Roberts wrote:
>>
>>> Dennis Scott wrote:
>>> > Tim: I think i understood your statement,
>>> >
>>> > In query interface the GUID i got is
>>> > “924A156C-CFAA-D011-8D2A-00A0C906B244” which is not the
>>> > USB_BUS_INTERFACE_USBDI_GUID(B1A96A13-3DE0-4574-9B01-C08FEAB318D6),
>>> > and i am not able to locate this guid value in header files.
>>> >
>>> > i got GUID using following code:
>>> >
>>> > irpStack = IoGetCurrentIrpStackLocation(Irp);
>>> >
>>> > interfaceType = (GUID )
>>> > irpStack->Parameters.QueryInterface.InterfaceType;
>>> >
>>> > for(i=0;i>>> > {
>>> > RtlStringCchPrintfA(buf+2i, 3, “%02X”, *((unsigned char
>>> > *)interfaceType+i));
>>> > }
>>> > KdPrint((“Query GUID: %s\n”,buf));
>>> >
>>> > what the above GUID corresponds to? vendor specific???
>>>
>>> Have you really never looked in to how you correctly print a GUID? The
>>> way you’re doing it is not correct. The first four bytes are printed as
>>> a single dword, the next two are a word, the next two are word, and only
>>> then do you print a byte at a time. What you have there is
>>> 6C154A92-AACF-11D9-8D2A-00A0C906B244, which is present in the DDK as
>>> GUID_TRANSLATOR_INTERFACE_STANDARD
>>>
>>> I don’t know what that means. How are you handling this?
>>>
>>> –
>>> Tim Roberts, xxxxx@probo.com
>>> Providenza & Boekelheide, Inc.
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer