Problems with usb.c (input DDK)

We’ve written a driver for a touchscreen (eGalax), but ran into a few
problems with the usb.c module of the input DDK:

void * devi_usb_register_client(input_module_t * pInput_module, int nDev,
_uint32 nVendor,
_uint32 nClass, _uint32 nSubClass)

The “nSubClass” variable in this function is not used; this causes us
problems, as our device returns a nSubClass value of 255. In the
insertion() function, our device is ignored as the nSubType is not
USBD_CONNECT_WILDCARD (which we specified in the devi_usb_register_client()
call). Any particular reason why the nSubClass member of the newly
allocated structure was not being set? Setting it accordingly fixed this
problem.

Another issue we have is in the usb_dev_init() function. For some strange
reason, the usbd_urb_status() keeps retuning 0x2000009, even though the
packet we’ve received from the device is correct (all bytes accounted for).
I’m at a lost to explain why this is. For the time being, ignoring the
error from the usbd_urb_status() call fixed our problem, but this can cause
us to process incorrect data if there ever was an error encountered.

Hi Richard,

I was responding to this at work and I got side tracked. As for nSubClass,
I’m not sure right at this moment, however I will have to look into it.

Regarding the status being, 0x2000009, this is due to the device is sending
sending short packets, which the lib doesn’t support. The usb stack had
support added to it in 6.3.0, however the input lib didn’t follow (bug).
It is a quick 2 second fix, it is just missing the URB_SHORT_XFER_OK flag
in the interrupt setup (usbd_setup_interrupt()). In the usb.c look for the
setup interrupt and add the flag as such:

usbd_setup_interrupt( pModule → urb,
URB_DIR_IN | URB_SHORT_XFER_OK,
pModule → ep_int_buf,
pModule->ep_int_size );

That, I expect will resolve your remaining problem.

E.


Richard Doucet <doucetr@aecl.ca> wrote:

We’ve written a driver for a touchscreen (eGalax), but ran into a few
problems with the usb.c module of the input DDK:

void * devi_usb_register_client(input_module_t * pInput_module, int nDev,
_uint32 nVendor,
_uint32 nClass, _uint32 nSubClass)

The “nSubClass” variable in this function is not used; this causes us
problems, as our device returns a nSubClass value of 255. In the
insertion() function, our device is ignored as the nSubType is not
USBD_CONNECT_WILDCARD (which we specified in the devi_usb_register_client()
call). Any particular reason why the nSubClass member of the newly
allocated structure was not being set? Setting it accordingly fixed this
problem.

Another issue we have is in the usb_dev_init() function. For some strange
reason, the usbd_urb_status() keeps retuning 0x2000009, even though the
packet we’ve received from the device is correct (all bytes accounted for).
I’m at a lost to explain why this is. For the time being, ignoring the
error from the usbd_urb_status() call fixed our problem, but this can cause
us to process incorrect data if there ever was an error encountered.

Thanks, that did the trick.

“Erick Muis” <emuis@emuis.com> wrote in message
news:d1dkq0$jk1$1@inn.qnx.com

Hi Richard,

I was responding to this at work and I got side tracked. As for nSubClass,
I’m not sure right at this moment, however I will have to look into it.

Regarding the status being, 0x2000009, this is due to the device is
sending
sending short packets, which the lib doesn’t support. The usb stack had
support added to it in 6.3.0, however the input lib didn’t follow (bug).
It is a quick 2 second fix, it is just missing the URB_SHORT_XFER_OK flag
in the interrupt setup (usbd_setup_interrupt()). In the usb.c look for
the
setup interrupt and add the flag as such:

usbd_setup_interrupt( pModule → urb,
URB_DIR_IN | URB_SHORT_XFER_OK,
pModule → ep_int_buf,
pModule->ep_int_size );

That, I expect will resolve your remaining problem.

E.


Richard Doucet <> doucetr@aecl.ca> > wrote:
We’ve written a driver for a touchscreen (eGalax), but ran into a few
problems with the usb.c module of the input DDK:

void * devi_usb_register_client(input_module_t * pInput_module, int
nDev,
_uint32 nVendor,
_uint32 nClass, _uint32 nSubClass)

The “nSubClass” variable in this function is not used; this causes us
problems, as our device returns a nSubClass value of 255. In the
insertion() function, our device is ignored as the nSubType is not
USBD_CONNECT_WILDCARD (which we specified in the
devi_usb_register_client()
call). Any particular reason why the nSubClass member of the newly
allocated structure was not being set? Setting it accordingly fixed
this
problem.

Another issue we have is in the usb_dev_init() function. For some
strange
reason, the usbd_urb_status() keeps retuning 0x2000009, even though the
packet we’ve received from the device is correct (all bytes accounted
for).
I’m at a lost to explain why this is. For the time being, ignoring the
error from the usbd_urb_status() call fixed our problem, but this can
cause
us to process incorrect data if there ever was an error encountered.