host_hid mouse data displaced #442
Comments
|
please try with tinyusb-0.10.0 branch of this repo |
|
Tagging @hathach |
|
Having some trouble actually testing this. I tried this by re-cloning the pico-sdk branch tinyusb-0.10.0 (in the original pico-sdk location), followed by rebuilding pico-examples. When I first ran "cmake -B build" in pico-examples, a CMake warning came back, requiring me to go to the pico-sdk repo and run "git submodule update --init", in order to build any tinyusb examples (which I did). I am assuming that this checked out the correct version of raspberrypi/tinyusb into pico-sdk/lib/tinyusb, although I wasn't able to find the commit ID on the expected branches. (commit ID was a long number terminating in "934cd935") The build failed during the build of the tinyusb sources, in usb/device/dev_audio_headset, so I'm wondering if perhaps the link in the pico-sdk/lib/tinyusb on the tinyusb-0.10.0 branch is not fetching an appropriate version of the tinyusb module... |
|
ah - yeah, there isn't a checked in version o pico-examples to match tinyusb-0.10.0 (it has changed though) you should be able to build from the examples/device directory in tinyusb though with PICO_SDK_PATH set. |
|
To be clear, do you mean to: ...Because this had problems during the cmake step: |
|
that's a weird error (that makes me think you don't have the latest pico-0.10.0 tinyusb code) That said, you need to specify a FAMILY and a BOARD e.g. |
|
you can use |
|
That failed in a different way. As for the version of the pico-0.10.0 tinyusb code, I cloned the tinyusb-0.10.0 branch of pico-sdk last night, and ran "git submodule update --init" which brought in whatever version was linked from lib/tinyusb in that branch... but I too was unclear whether it was the correct one. Here is the most recent output: |
|
Actually I realized... When building in examples/host, it also failed (but in a different way): |
|
I don't think i realized you were building the standalone "tinyusb way" from within the tinyusb submodule of pico-sdk. in any case, there pico-sdk->tinyusb did not have the latest submodule commit reference; i have updated |
|
No, I had only been using the release version of pico-SDK, pico-examples, etc. until you asked me to test on a branch. I wouldn't feel comfortable opening an issue against anything but the release version. I have good news/bad news to report: However, when I run the example - which should report mouse movements when I have a mouse plugged in - I get the following output with each of the mice I try - including the official Raspberry Pi mouse which worked fine on the release version (but didn't have forward/back buttons on the side). |
|
@dshadoff can you clone the upstream and cd to https://github.com/hathach/tinyusb/tree/master/examples/host/cdc_msc_hid then then copy the uf2 to pico to test with. |
|
OK, I interpreted that as: This creates a separate tinyusb repository, adjacent to pico-sdk, and on the master git branch (which is more current than 0.10.0, as it had a commit as recently as 9 hours ago). Also, my pico-sdk is still on the tinyusb-0.10.0 branch. Results are mostly good news: The build went fine
|
|
sure there is a bug, now let test with the logitech mouse
then post your log as txt file for analyzing. you could also post the log with the 3) wired mouse fwd/bck not work right, but that would be later or better a separated issue. |
|
What do you mean "logitech vid" ? How would I find that ? Specifically, the difference in output between no USB devices plugged into the RPi400 and with only the Logitech unifying receiver plugged in, is the following (from usbhid-dump)... perhaps the logitech vid can be derived from this: |
|
Here is the capture with Logitech unifying receiver. I've also captured the log from the other mouse (not attached), but I agree that Logitech is a higher-value fix. (The other mouse was only bought because Logitech fix didn't seem close). |
@dshadoff run to get the configuration descriptor of your logitech then following command to get the report descriptor in readable format Both are required for further troubleshooting. |
|
OK, lsusb provides the following: From the above, I am assuming that instead of "cafe", I should be using the "046d" portion of the Logitech device ID ? Running the final command I run into a problem, as "hidrd-convert" is not found on the Pi 400 I am using; where can I obtain it ? |
|
Never mind, was able to locate it and get it with: The output is attached here: |
|
Hi hathach I have the same problem. I used the USB packet analyzer. It seems that GET_DESCRIPTOR(DEVICE) did not receive the requested size. If there is anything we can do to help, please request it. |
|
@v9938 To clarify, when you say "the same problem", are you referring to: |
|
Hi dshadoff Of course, I can discuss it on another topic. |
|
@kilograham and @hathach should decide how to proceed. I just wanted to clarify your comment. |
|
@dshadoff thanks for the info, I am also able to reproduce the issue with one of my laying dongle and spent a couple hours troubleshooting it. It needs a bit of works, here is what I found so far.
Overall, since I want to implement double buffering at least for host in the near future, I feel that keep fixing the RP2040-E5 walkaround doesn't justify the effort. It is best to use implement double buffer to get in sync with hardware. Though I need a bit more time to separate the hcd and dcd endpoint transfer, since it is easy to mess up the device side just now. Better to do it in incremental step. I will update this topic whenever there is a new PRs for this.
|
|
Is raspberrypi/tinyusb#7 relevant here @hathach ? Or should that PR be closed already? |
You should ask the OP of that issue. The host is current has some bugs related to the E4 anyway, I will try to see if I could get it all resolved soon enough. |
|
I know that you're looking at the wireless Logitech logs (and I hope progress is going well), but now I have also captured the details for the original wired 4-button mouse (where X and Y appear to be 16-bit values instead of 8-bit, so 'rpt->Y' contains a sign-extended MSB of X, and the actual Y value is in the 'rpt->wheel' data position): lsusb says: The hidrd output for the device is here: And the output from the special (LOG=3) build of the host example is here: |
|
Thanks any data available in advance is good when I switch back to work on tinyusb (on other work just now). |
The report representation format (which byte for which usage) is detailed in report descriptor. HID parser is very complicated (most complicated descriptor of USB), and TinyUSB basically cannot parse it all. It currently only provide a very simple parser to parse usage_page and usage of each report ID. For more than that, application have to parse it themself, the report descriptor is available with the For mouse and keyboard, we can actually use boot interface which guarantee to work on all mouse/keyboard. For boot support, I will do it later on when having time. If you want to understand more about HID, check out the USB HID specs, it is rather short and simple. For now, I will wrap up my work here with the double buffered. Others are unrelated issue, and should be addressed separately. |
|
@dshadoff I made another branch to force/set boot protocol for keyboard, mouse device here https://github.com/hathach/tinyusb/tree/more-hid-host (since double buffered branch is under review). This should solve your issue with mis-matched report with your logitech/wired mouse. |
|
@dshadoff I immediately tested it.
|
|
@v9938 can you provide the context for each case, which device you use to test, and what you have done to reproduce the issue and how often it happens. 1 and 2 loom like you have unstable power or usb connection |
|
@hathach I re-tested it. Case1 PANIC occurred Case3: usbh_edpt_xfer 386: ASSERT FAILED occurred More information... |
|
@v9938 please put your log into its own txt and attached it instead of posting it here. Long log in the comment make it difficult follow the issue. Also please use above lsusb and hidrd to post your device configuration & hid descriptor. The log you post is not easy to read at all. If you are using windows try usbtreeview https://www.uwe-sieber.de/usbtreeview_e.html then post your device configuration and hid descriptor as attached txt. |
|
@hathach I tried with both of the mice, and the more-hid-host branch had problems; I have captured the logs. Mouse 1: Maxxster (wired mouse with side buttons):When connected, it did not appear to respond at all. Mouse 2: Logitech (unifying receiver):Connected, but "couldn't find report info" for any reports when the mouse moved. |
|
@hathach Thanks for the quick response. Firmware version 012.010.00032(Model No:C-U007) Firmware version 024.007.00030(Model No:C-U008) |
|
@v9938 thanks for the configuration descriptor, I would also need the hid descriptor as well. I don't know how to that on windows. Maybe you should try to run usbtreeview with administrator mode to see if it could. Since we have the txt file now, could you remove your super long log in above post to make this issue easier to follow. @dshadoff thank for the detail feedback, I will check this out later on. |
|
@hathach It seems to be difficult to dump the raw data of HID descriptor on windows. HID descriptor version 012.010.00032(Model No:C-U007) HID descriptor version 024.007.00030(Model No:C-U008) |
|
I looked again at this on the weekend (on the more-hid-host branch), also with a couple of other mice. When compiled with LOG=1, the reports from Logitech (and also another wireless mouse) seemed to be providing correct data in the reports, and consistent with boot mouse format (i.e. buttons, x, y, scroll wheel - each 8-bit signed values). The only problem in those cases was: (However, the Maxxster appeared not to produce any reports... but I don't care as much about this mouse if the others are working) |
|
I tested with several mice - including the two mentioned earlier in this thread - and they all seemed to work, and to provide consistent results. Thank You ! The only thing I noticed, was surrounding the disconnection and reconnection of mouse devices - but that appears to be the same as issue #483 opened by @v9938 , so it can be tracked there. I will continue to test with a variety of other devices I have; if I find any issues, I will open separate issues for tracking. |
|
thank for the feedback, look like I nailed it this time. For the release/update, it may take a bit of time, since I still want to do more tweak to host API but have been kept busy with other works. |
|
@v9938 let me know if the new code fox issue with your devices |
|
@hathach Sorry for the late feedback. Model No:C-U007 Model No:C-U008 |
|
@v9938 thanks for your feedback, seem like there is still issue :( . Could you also attach both log with |
|
@hathach The LOG files are attached below. Model No:C-U007 Model No:C-U008 |
|
indeed @v9938 this seems to be issue with connection, which can be either hardware and/or connection issue. To further troubleshoot it, I would suggest you to post picture of your hw set-up, also have shortest otg cable as possible etc... I don't see any abnormal connection issue with mine. I think people could then help you more with troubleshoot if it is hardware issue. I think my work here is done. Thanks both of you for testing out and giving feedback. Update: more-host-hid pr is merged to master. |
|
@hathach Sorry for the late response. There were several problems and it took a long time to prepare. The next picture shows the OTG cable. In both cables, the result was the same result. The experimental setup was as shown in the next photo. Maybe there is nothing wrong with the environment. |
|
I am not good at hardware, here is my set up that work relatively well. I use another pico as picoprobe (above) also providing 5V to target (below) via pin 40. |
|
SDK version 1.3.0 release and the corresponding TinyUSB version are working fine for this. |
|
cc @liamfraser |
|
Want to add my experience for anyone who is still facing this - I am seeing the exact same issue as the original post, but I think I figured out what my problem was (And I don't know if it was teased out in all the comments above). I was mostly following this example, and there seems to be an edge case where void tuh_hid_report_received_cb(uint8_t dev_addr, uint8_t instance,
uint8_t const* report, uint16_t len) {
uint8_t itf_protocol = HID_ITF_PROTOCOL_NONE;
uint8_t const* report_offset = report;
if (hid_info[instance].report_count > 1) {
// we know this is a composite report, so extract the id and start the reading the data one byte over
report_offset = report + 1;
uint8_t id = report[0];
// find the tuh_hid_report_info_t that matches the id of the report we just received
for (size_t i = 0; i < hid_info[instance].report_count; i++) {
tuh_hid_report_info_t info = hid_info[instance].report_info[i];
if (info.report_id == id) {
if (info.usage_page == GENERIC_DESKTOP_USAGE_PAGE) {
if (info.usage == USAGE_MOUSE) {
itf_protocol = HID_ITF_PROTOCOL_MOUSE;
} else if (info.usage == USAGE_KEYBOARD) {
itf_protocol = HID_ITF_PROTOCOL_KEYBOARD;
}
}
// TODO handle other usage pages, Consume Control, etc?
break;
}
}
} else {
itf_protocol = tuh_hid_interface_protocol(dev_addr, instance);
}
switch (itf_protocol) {
case HID_ITF_PROTOCOL_KEYBOARD:
process_kbd_report(dev_addr, (hid_keyboard_report_t const*)report_offset);
break;
case HID_ITF_PROTOCOL_MOUSE:
process_mouse_report(dev_addr, (hid_mouse_report_t const*)report_offset);
break;
default:
break;
}
//...
}I am testing with a little portable keyboard/touchpad like this, and it appears to send mouse and Consumer Control data via the same "instance", so report_id's are used to distinguish between mouse reports and CC reports. |
Some wired mice (such as the official Raspberry Pi mouse) work with the host_hid USB example code in pico-examples - in fact, it seems that at the moment, only wired mice are recognized (although this is not the issue I wish to report here).
At least some wired mice which have side buttons (i.e. back/forward) have displaced data:
(note: the mouse works fine on a RPi 400)
I am reporting this here as pico-sdk holds a non-current version of tinyusb, and it doesn't seem to be straightforward to test with the current tinyusb on pico hardware at the moment.
This may be solved with the newer version of tinyusb in pico-sdk 1.2.0 ... this issue can serve as a placeholder until that is available for test; if pico-sdk and tinyusb are in sync at that time (and if the issue is not yet resolved), I will be happy to report the issue upstream. I am also happy to gather any diagnostic information required (if the process is explained).
For the moment, the existence of a report may be helpful to other users, to indicate current known system limitations.
The text was updated successfully, but these errors were encountered: