usbHsAcquireUsbIf doesn't seem to be correct
ischeinkman opened this issue · comments
According to swipc-gen, usbHsAcquireUsbIf has 2 output buffers instead of just 1. However, even with adding a second buffer to the IPC command, the call just ends up zeroing both buffers and not returning a handle, nor an error code.
I tried manipulating the passed in device ID (since it seems to actually be structured as 2 bytes of padding and then a little-endian s16, instead of a full s32), but I could never seem to get different behavior, even with the examples.
code?
Here is the most recent test I did with, the output data: https://gist.github.com/ischeinkman/ed99bab8dfb5899a03856513a6a38027
This command has changed in at least 2.0.0 and 3.0.0. Which firmware version are you on?
6.20
Do not use fprintf in IPC funcs, TLS will get overwritten...
I noticed that myself a bit ago too.
Seems like I'm actually getting an error code of USB: 204 in the response struct; see https://gist.github.com/ischeinkman/ed99bab8dfb5899a03856513a6a38027#file-usbhs_ex-log2-txt-L10991 .
So usbHsAcquireUsbIf is currently returning 0xf601?
The function is returning 0xf601; however, the value within the TLS buffer after the first call to serviceIpcDispatch is 0xcc8c.
TLS is irrelevant when the SVC fails...
Try removing all logging in that func, & test + update-gist.
Sorry, I guess I am not being clear.
When I make the first call to serviceIpcDispatch, the response contains an error code of 0xcc8c. However, since I have fprintfcalls between the serviceIpcDispatch call and the serviceIpcParse call, this response is overwritten in the buffer and leads to the function attemptint to call _usbHsGetEvent on a non-existent ClientIfSession, which leads to an error code of 0xf601 which the function then returns.
When I remove the logging in the function it then returns 0xcc8c.
Cmd changed with 3.0.0, need to add support.
Looks like the buffer locations are flipped:
https://gist.github.com/ischeinkman/b34c56e719ffc3d60e6ba077de109788
So it works fine besides that?
Can you hexdump inf_session.inf?
Sorry for going dark; I ended up quickly patching my local copy and then forgot to update here.
The following code ends up successfully creating byte-identical values for s->inf and interface:
if (!kernelAbove300()) {
ipcAddRecvBuffer(&c, &s->inf.inf, sizeof(UsbHsInterfaceInfo), BufferType_Normal);
}
else {
size_t ba_size = offsetof(UsbHsInterfaceInfo, output_endpoint_descs[12]);
size_t bb_size = sizeof(UsbHsInterface) - ba_size;
u8 * raw_ptr = (u8 *) &s->inf.inf;
ipcAddRecvBuffer(&c, raw_ptr + bb_size, ba_size, BufferType_Normal);
ipcAddRecvBuffer(&c, raw_ptr, bb_size, BufferType_Normal);
}I am still having other issues but I am not currently sure if they are due to my own code or libnx itself, but at this point I think this specific issue can be closed.
Looks to me almost the same as e9cc565, but with the buffer addresses swapped (not the sizes... huh)
Looks to me almost the same as e9cc565, but with the buffer addresses swapped (not the sizes... huh)
It is exactly the same with the buffer addresses swapped but not the sizes.
Pinging @ischeinkman - this is the last thing holding back a release.
Sorry about that -- once I realized that my local code was working I got too distracted finishing up my usb drive library (shameless plug).
Yes, that code seems to be working exactly the same as the one I had before. Thank you for all the help!