Hy Dave, Gregg
Thanks for your answers.

To Dave:
> I've heard some folk report that the MS-Windows support for CDC is a
> bit flakey.  Maybe that's part of their general strategy of
> undermining standards-based interoperability...
I googled for some details about the used usbser.sys driver but found
nothing useful. Is there any source for detailed information about the
implementation of the usbser.sys driver?

> Alternatively, the issue might be the way the SET_LINE_CODING or
> SET_CONTROL_LINE_STATE requests are rejected by the current serial
> gadget code.  Fixing that should be a straightforward patchlet.  If
> you're NOT getting one of the warning messages about unsupported
> messages from gs_setup, that option becomes unlikely.
I logged the USB transactions with a USB Sniffer.
During my analysis (still ongoing) i found that in the "abstract control
manangement functional descriptor" defines the bmCapabilities as 0 (zero)
(found in the configuration descriptor).
This means that non of the following features are supported:
- Set_Comm_Feature
- Clear_Comm_Feature
- Get_Comm_Feature
- Set_Line_Coding
- Get_Line_Coding
- Set_Control_Line_State
- Serial_State notification
- Send_Break
- Network_Connection
(found on USB Class Definitons for Communication Devices, Version 1.1,
 Table 28, page 36, Rev. 1999-01-19)
I found the definition of the descriptor in the source file
(drivers/usb/gadget/serial.c) on line 429, where the bmCapabilities were
defined.
So, setting that to another value wouldn't be tricky but what does
it means for the according features? I'm pretty new in the "USB World" and
doesn't feel comfortable with the details of the VT100 (or similar - i think
that will be the interface that the gadget serial "emulates") definitions.
Is there a source for detailed information about this features (other than the
USB CDC Definition)?
You wrote "Fixing that should be a straightforward patchlet" could you explain
that in more detail?

To Gregg:
> Wasn't there a similar problem concerning one individual's
> work with a Gumstick device, which is I think PXA based, and
> one of the releases of Windows? (Although it might be,
> Gumstick that is, based on the same ARM family processor
> that's inside the NSLU2.)
Sorry, didn't found any information on google about that.
I think gumstix is using a PXA-255.

Regards,
Aurel
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to