linux box not allowing control set's but does get's ok.

[ulao]

I can use a get control transfer no problem on linux but a set is failing.

This is what wireshark sees when use a set. The data never made it to the device.


attached WS log.

[bpaddock]

Are there any issues with the UDEV rules for the user account?
They can prevent writes while allowing reads.
Does demsg shed any light when it happens?

[ulao]

nope, we are good with the permissions.  Plus the get operations are working.

I did see this...

watching forceFeedback (it uses a set control transfer ) it works


so I dummied up a clone in my app.




Looking at this I do see I forgot to change the array report size to a 4. I did try 8 but get the same results.  Another interesting thing here is that any data I send the device says it received it. I can make up a report id with some random size and it thinks it worked.

[ulao]

I created a test sample from a claimed working version online and it would seem there is a bug in the latest lib usb as it too is not working. I already tied a few versions os libusb 1.x


my report id is 18
sending a out control transfer feature report
no error, but does not hit device.

Code: [Select]

static int test_control_transfer(void)
 {
 int r,i;
 char answer[PACKET_CTRL_LEN];
 char question[8];
  question[0]=1;
 question[3]=0xff;
 fprintf(stderr, "----------------\n");

 r = libusb_control_transfer(devh,CTRL_OUT,HID_SET_REPORT,(HID_REPORT_TYPE_FEATURE<<8)|0x12, 0,question, 8,TIMEOUT);
 if (r < 0) {
 fprintf(stderr, "Control Out error %d\n", r);
 return r;
 }

 return 0;
 }

[ulao]

WFT?

this worked.
 question[0]=0x12; question[1]=1; question[4]=0x00; r = libusb_control_transfer(devh, CTRL_OUT,HID_SET_REPORT,(HID_REPORT_TYPE_FEATURE<<|0x12, 0,question, 8,TIMEOUT);

this does not

 question[0]=1; question[3]=0x00; r = libusb_control_transfer(devh, CTRL_OUT,HID_SET_REPORT,(HID_REPORT_TYPE_FEATURE<<|0x12, 0,question, 8,TIMEOUT);

so you have to pass in the report id in the first element as well as the parameter ? That's stupid.

oddly I get  error -7 even though it worked. Using wirewhark I don't see an error at all. The packet even completes in a timely manner. Yet the libusb code is waiting for some sort of reply that never occurs.

Jan, maybe when you return and have time can you update a feature control out transfer sample using the latest libusb?

[Jan Axelson]

Yes, you have to pass the report id in the first element

[ulao]

Do you have any idea why it give an error -7.

[Jan Axelson]

What is giving the error and do you have a reference for what the error indicates?

[ulao]

libusb 1.0 is issuing an error -7 (timeout). There is no need for the error because the device received the data.  Most of this is explain in my posts above.


1) the host sends a control transfer get ok. No errors.
2) the host sends a control transfer set and gets error -7. NOTE the device received the set ok.
3) Libusb 1.0 tries to send the set over and over, no idea why.
4) libusb 0.1  sends a control transfer set ok. No errors.

This is what the log gives me

[20.121537] [00003114] libusb: debug [libusb_alloc_transfer] transfer 0x55a7580de520
[20.121550] [00003114] libusb: debug [libusb_submit_transfer] transfer 0x55a7580de520
[20.121555] [00003114] libusb: debug [add_to_flying_list] arm timerfd for timeout in 5000ms (first in line)
[20.121585] [00003114] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[20.121802] [00003114] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[25.121587] [00003114] libusb: debug [handle_events] poll() returned 1
[25.121620] [00003114] libusb: debug [handle_events] timerfd triggered
[25.121626] [00003114] libusb: debug [libusb_cancel_transfer] transfer 0x55a7580de520
[25.122291] [00003114] libusb: debug [disarm_timerfd]
[25.122326] [00003114] libusb: debug [handle_events] poll() 3 fds with timeout in 0ms
[25.122340] [00003114] libusb: debug [handle_events] poll() returned 1
[25.122354] [00003114] libusb: debug [reap_for_handle] urb type=2 status=-2 transferred=8
[25.122360] [00003114] libusb: debug [handle_control_completion] handling completion status -2
[25.122367] [00003114] libusb: debug [usbi_handle_transfer_cancellation] detected timeout cancellation
[25.122371] [00003114] libusb: debug [disarm_timerfd]
[25.122375] [00003114] libusb: debug [usbi_handle_transfer_completion] transfer 0x55a7580de520 has callback 0x7fbff56d8b30
[25.122380] [00003114] libusb: debug [sync_transfer_cb] actual_length=8
[25.122388] [00003114] libusb: debug [libusb_free_transfer] transfer 0x55a7580de520
Error during libusb_control_transfer: -7

Here is my logic analyzer results. Looks like after it sends a good feature set, it just sends again, and again. ?



Control data test Summary.

1) this device works with libusb 0.1
2) this device works with windows
3) This device work with linux FFB (FFB uses control transfers set/get)

Thus the issue is clearly libusb 1.0. As why I was wondering if you samples work? I tried the same code in my host software and get this error -7.

[Jan Axelson]

Be sure the endpoint is returning ACK in the Setup and Data stages, not doing so would cause the host to retry.

[ulao]

If it was not returning ack these statement would not be true.

1) the host sends a control transfer get ok. No errors.
2) the host sends a control transfer set and gets error -7. NOTE the device received the set ok.
3) Libusb 1.0 tries to send the set over and over, no idea why.
4) libusb 0.1  sends a control transfer set ok. No errors.

and

1) this device works with libusb 0.1
2) this device works with windows
3) This device work with linux FFB (FFB uses control transfers set/get)


What I'm trying to say is that I have boxed this thing in. It is not the device. There has to be a bug in libusb 1.0. Unless you have an example that works.

[ulao]

Analyzing the code it looks like I may not be returning ack. It just so happens that all other forms of the usbapi somehow deal with it ok. I will try this tonight and report back.

[ulao]

Jan you are an amazing person, thank you. Apparently 0.1 of libusb and hidapi are a lot less picky. This bug goes back about 5 years and was in the device.  The issue was the device didnt reply with ACK for 8 byte data. instead it was replying NAC assuming more data was to follow.

[Jan Axelson]

Glad to hear you found the source of the problem! Thanks for reporting back.