Author Topic: win10 hates my control transfer device descriptor?  (Read 12153 times)

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
win10 hates my control transfer device descriptor?
« on: October 24, 2017, 05:10:11 pm »
So in windows 95-7 this is ok.

//input bulk

    7,          /* sizeof(usbDescrEndpoint) */
    USBDESCR_ENDPOINT,  /* descriptor type = endpoint */
    0x81,       // bulk IN endpoint number 1
    0x03,       /* attrib: Interrupt endpoint */
    8, 0,       /* maximum packet size */
    0x0A, /* in ms*/

//the output control

    7,          // sizeof(usbDescrEndpoint)
    USBDESCR_ENDPOINT,  // descriptor type = endpoint
    0x01,        // out endpoint
    0x00,       // attrib: Interrupt endpoint :1async 2:bulk 3:int (0:control win10 will not work on 0, needs 3,)
    8, 0,       // maximum packet size
    0x02, // in ms
#endif     
};

see note, changing to a 0 causes the device no to communicate in win10. I'm not sure what the issue is here?




Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: win10 hates my control transfer device descriptor?
« Reply #1 on: October 25, 2017, 10:17:38 am »
Use endpoint zero for all control transfers. I don't think the USB specs forbid designating additional control endpoints, but doing so doesn't provide any more bandwidth for control transfers or other benefits.

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
Re: win10 hates my control transfer device descriptor?
« Reply #2 on: October 25, 2017, 12:41:05 pm »
This is what I should have

enp0: I set this to 0x81(in)  and 03 (interrupt)
enp1: I set this to 0x01(out) and 0 (control)

this does not work on linux, win10, or mac. For some unknown reason I must do this.


enp0: I set this to 0x81(in)  and 03 (interrupt)
enp1: I set this to 0x01(out) and 3 (interrupt)

Does that make any sense at all? By "not work" I mean that for the case I mentioned first, the device enumerates but the interrupt data does not occur. I must tell the OS that my enp1 is interrupt in order for things to work right but enp1 is not interrupt... NOTE: this issue is only for win10 and linux, win7 seems to be ok with it either way.



I have one thought yet to try. I may not be filtering packets as they come in to the device by type. treating both as interrupt and control. I'll look in to that soon. (i.e only do control transfer data is bmRequestType & 0x80 is clear. )
« Last Edit: October 25, 2017, 01:23:02 pm by ulao »

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: win10 hates my control transfer device descriptor?
« Reply #3 on: October 25, 2017, 02:57:43 pm »
Besides what I posted earlier, control endpoints are bidirectional. Thus you cannot have Endpoint 1 IN AND Endpoint 1 control because Endpoint 1 control uses both IN and OUT transactions.

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
Re: win10 hates my control transfer device descriptor?
« Reply #4 on: October 25, 2017, 08:42:45 pm »
Ok that helps, I thought the in/out was interference to the endpoint.

What gets confusing is there are two types of in/outs

the USBRQ_DIR_HOST_TO_DEVICE vs USBRQ_DIR_DEVICE_TO_HOST
and the report type
      1:  input report
      2:  output report
      3:  feature report

I had that confused. So my descriptor is wrong then, what represents in and out.

0x81 in
0x01 out
ox?? in/out ?


Ideally I'd like this

1 bulk (in)  (default endpoint)  I assume this is EP0
1 control (in/out) EP1

How do I set that up with what I have. Do I need to define a 3rd? If so how do I tell it what is EP0 and EP1-in EP1-out ?

Code: [Select]
Device Descriptor
Offset Field Size Value Description
0 bLength 1 12h 
1 bDescriptorType 1 01h Device
2 bcdUSB 2 0110h USB Spec 1.1
4 bDeviceClass 1 00h Class info in Ifc Descriptors
5 bDeviceSubClass 1 00h 
6 bDeviceProtocol 1 00h 
7 bMaxPacketSize0 1 08h 8 bytes
8 idVendor 2 16D0h 
10 idProduct 2 0D04h 
12 bcdDevice 2 0101h 1.01
14 iManufacturer 1 01h "BLISS-BOX"
15 iProduct 1 02h 
16 iSerialNumber 1 03h "0001"
17 bNumConfigurations 1 01h 

Configuration Descriptor 1 Bus Powered, 200 mA
Offset Field Size Value Description
0 bLength 1 09h 
1 bDescriptorType 1 02h Configuration
2 wTotalLength 2 0029h 
4 bNumInterfaces 1 01h 
5 bConfigurationValue 1 01h 
6 iConfiguration 1 00h 
7 bmAttributes 1 00h Bus Powered
 4..0: Reserved  ...00000   
 5: Remote Wakeup  ..0.....  No
 6: Self Powered  .0......  No, Bus Powered
 7: Reserved (set to one)
(bus-powered for 1.0)  0.......   
8 bMaxPower 1 64h 200 mA

Interface Descriptor 0/0 HID, 2 Endpoints
Offset Field Size Value Description
0 bLength 1 09h 
1 bDescriptorType 1 04h Interface
2 bInterfaceNumber 1 00h 
3 bAlternateSetting 1 00h 
4 bNumEndpoints 1 02h 
5 bInterfaceClass 1 03h HID
6 bInterfaceSubClass 1 00h 
7 bInterfaceProtocol 1 00h 
8 iInterface 1 00h 

HID Descriptor
Offset Field Size Value Description
0 bLength 1 09h 
1 bDescriptorType 1 21h HID
2 bcdHID 2 0110h 1.10
4 bCountryCode 1 00h 
5 bNumDescriptors 1 01h 
6 bDescriptorType 1 22h Report
7 wDescriptorLength 2 055Ah 1370 bytes

Endpoint Descriptor 81 1 In, Interrupt, 8 ms
Offset Field Size Value Description
0 bLength 1 07h 
1 bDescriptorType 1 05h Endpoint
2 bEndpointAddress 1 81h 1 In
3 bmAttributes 1 03h Interrupt
 1..0: Transfer Type  ......11  Interrupt
 7..2: Reserved  000000..   
4 wMaxPacketSize 2 0008h 8 bytes
6 bInterval 1 08h 8 ms

Endpoint Descriptor 01 1 Out, Interrupt, 2 ms
Offset Field Size Value Description
0 bLength 1 07h 
1 bDescriptorType 1 05h Endpoint
2 bEndpointAddress 1 01h 1 Out
3 bmAttributes 1 03h Interrupt
 1..0: Transfer Type  ......11  Interrupt
 7..2: Reserved  000000..   
4 wMaxPacketSize 2 0008h 8 bytes
6 bInterval 1 02h 2 ms





« Last Edit: October 25, 2017, 08:58:04 pm by ulao »

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: win10 hates my control transfer device descriptor?
« Reply #5 on: October 26, 2017, 08:56:36 am »
Endpoint zero is the default control endpoint and the only control endpoint you need.

For interrupt IN transfers, you can use endpoint 1 IN.

For interrupt OUT transfers, you can use endpoint 1 OUT.

On the host side, for Input reports using ReadFile or Filestreams, the host will use the HID's interrupt IN endpoint.

For Output reports using WriteFile or Filestreams, the host will use the HID's interrupt OUT endpoint if it exists; otherwise the host will use the control endpoint.

For Feature reports, the host will use the control endpoint.

HIDs don't use bulk endpoints.

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
Re: win10 hates my control transfer device descriptor?
« Reply #6 on: October 26, 2017, 01:26:49 pm »
Based on that, the defining of pipes in my code snipt above, I must be defining my endpoint 1, thus I can only assume my implementation of endpoint 0 is not configurable and just set up right.

Since I do not need my endpoint 1 to do anything but input I guess I don't need the second pipe config at all. I guess my confusion was that I was trying to define my default EP0.

Thx for clearing this up.
« Last Edit: October 26, 2017, 01:28:33 pm by ulao »

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: win10 hates my control transfer device descriptor?
« Reply #7 on: October 26, 2017, 08:37:25 pm »
The device descriptor defines max packet size for endpoint zero.