host_hid mouse data displaced

dshadoff commented 3 years ago

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:

button presses appear in the (hid_mouse_report_t).x element rather than (hid_mouse_report_t).button;
x movement appears in (hid_mouse_report_t).y rather than (hid_mouse_report_t).x .
(hid_mouse_report_t).button remains 1 (i.e. left button pressed)

(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.

kilograham commented 3 years ago

please try with tinyusb-0.10.0 branch of this repo

dhalbert commented 3 years ago

Tagging @hathach

dshadoff commented 3 years ago

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...

kilograham commented 3 years ago

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.

dshadoff commented 3 years ago

To be clear, do you mean to: cd (base)/pico-sdk/lib/tinyusb/examples/device and then

cmake -B build
cd build
make

...Because this had problems during the cmake step:

CMake Error at cdc_msc_freertos/CMakeLists.txt:19 (message):
  Invalid FAMILY specified:

-- Configuring incomplete, errors occurred!

kilograham commented 3 years ago

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.

kilograham commented 3 years ago

cmake -DFAMILY=rp2040 -DBOARD=raspberry_pi_pico' -B build

you can use -DBOARD=pico_sdk too to just follow PICO_BOARD setting

dshadoff commented 3 years ago

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:

Using PICO_SDK_PATH from environment ('/home/pi/devel/pico/pico-setup/pico/pico-sdk')
PICO_SDK_PATH is /home/pi/devel/pico/pico-setup/pico/pico-sdk
Defaulting PICO_PLATFORM to rp2040 since not specified.
Defaulting PICO platform compiler to pico_arm_gcc since not specified.
-- Defaulting build type to 'Release' since not specified.
PICO compiler is pico_arm_gcc
-- The C compiler identification is GNU 7.3.1
-- The CXX compiler identification is GNU 7.3.1
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-gcc
PICO target board is pico.
Using board configuration from /home/pi/devel/pico/pico-setup/pico/pico-sdk/src/boards/include/boards/pico.h
-- Found Python3: /usr/bin/python3.7 (found version "3.7.3") found components: Interpreter 
CMake Warning at ../../../../src/rp2_common/tinyusb/CMakeLists.txt:14 (message):
  PICO_TINYUSB_PATH specified but content not present.

Using PICO_EXAMPLES_PATH from environment ('/home/pi/devel/pico/pico-setup/pico/pico-examples')
-- Configuring done
CMake Error at net_lwip_webserver/CMakeLists.txt:16 (add_executable):
  Cannot find source file:

    /home/pi/devel/pico/pico-setup/pico/pico-sdk/lib/tinyusb/lib/lwip/src/core/altcp.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

dshadoff commented 3 years ago

Actually I realized... The example I was looking to use is found in host, not device (host hid mouse device, as per the issue title). So building in examples/device would appear to be incorrect.

When building in examples/host, it also failed (but in a different way): cmake was fine But make failed:

Scanning dependencies of target raspberry_pi_pico-cdc_msc_hid
[ 20%] Building C object cdc_msc_hid/CMakeFiles/raspberry_pi_pico-cdc_msc_hid.dir/src/hid_app.c.obj
/home/pi/devel/pico/pico-setup/pico/pico-sdk/lib/tinyusb/examples/host/cdc_msc_hid/src/hid_app.c:26:10: fatal error: bsp/board.h: No such file or directory
 #include "bsp/board.h"
          ^~~~~~~~~~~~~
compilation terminated.
make[2]: *** [cdc_msc_hid/CMakeFiles/raspberry_pi_pico-cdc_msc_hid.dir/build.make:63: cdc_msc_hid/CMakeFiles/raspberry_pi_pico-cdc_msc_hid.dir/src/hid_app.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1631: cdc_msc_hid/CMakeFiles/raspberry_pi_pico-cdc_msc_hid.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

kilograham commented 3 years ago

I don't think i realized you were building the standalone "tinyusb way" from within the tinyusb submodule of pico-sdk. I assumed you were building from a standalone tinyusb depo pointing at a standalone pico-sdk via PICO_SDK_PATH

in any case, there pico-sdk->tinyusb did not have the latest submodule commit reference; i have updated

dshadoff commented 3 years ago

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: First, I am now able to build the pico-sdk/lib/tinyusb/examples/host sources.

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).

----------------------------------------------------
TinyUSB Host Example
If you find any bugs or problems, feel free to open
an issue at https://github.com/hathach/tinyusb
----------------------------------------------------

This Host demo is configured to support:
  - RTOS = Raspberry Pi Pico SDK

*** PANIC ***

ep 0 in was already available

hathach commented 3 years ago

@dshadoff can you clone the upstream and cd to https://github.com/hathach/tinyusb/tree/master/examples/host/cdc_msc_hid then

make BOARD=raspberry_pi_pico all

then copy the uf2 to pico to test with.

dshadoff commented 3 years ago

OK, I interpreted that as:

cd (parent of pico-sdk)
git clone git://github.com/hathach/tinyusb
cd tinyusb/examples/host/cdc_msc_hid
make BOARD=raspberry_pi_pico all

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 The execution does not crash as my previous attempt did. 1) Raspberry Pi official mouse works as well as the previous pico-sdk examples did. 2) Logitech wireless mouse is still not recognized at all. 3) The wired mouse with forward/back side buttons works better than the previous release, but still not completely correctly:

all 4 buttons now are recognized correctly and do not cause any confusing 'X' or 'Y' movements
'X' movements appear fine, except that the 'Y' value is either "0" (for positive X movement) or "-1" (for negative X movement)
'Y' movement is not reported in the report->Y, but rather in the wheel value So for some reason, this mouse appears as though it may be reporting 16-bit X and Y values ? In any case, it works fine on Windows and Linux machines...

hathach commented 3 years ago

sure there is a bug, now let test with the logitech mouse

can you uoload its report descriptor as txt file. If you are in linux you could dump it with sudo usbhid-dump -d cafe | grep -v : | xxd -r -p | hidrd-convert -o spec replace cafe with logitech vid

now run compile again with log enable (need to clean first)

make BOARD=raspberry_pi_pico clean
make BOARD=raspberry_pi_pico LOG=3 all

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.

dshadoff commented 3 years ago

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:

001:011:002:DESCRIPTOR         1622608876.558106
 06 00 FF 09 01 A1 01 85 10 95 06 75 08 15 00 26
 FF 00 09 01 81 00 09 01 91 00 C0 06 00 FF 09 02
 A1 01 85 11 95 13 75 08 15 00 26 FF 00 09 02 81
 00 09 02 91 00 C0 06 00 FF 09 04 A1 01 85 20 95
 0E 75 08 15 00 26 FF 00 09 41 81 00 09 41 91 00
 85 21 95 1F 09 42 81 00 09 42 91 00 C0

001:011:001:DESCRIPTOR         1622608876.565384
 05 01 09 02 A1 01 85 02 09 01 A1 00 95 10 75 01
 15 00 25 01 05 09 19 01 29 10 81 02 95 02 75 0C
 16 01 F8 26 FF 07 05 01 09 30 09 31 81 06 95 01
 75 08 15 81 25 7F 09 38 81 06 95 01 05 0C 0A 38
 02 81 06 C0 C0 05 0C 09 01 A1 01 85 03 95 02 75
 10 15 01 26 FF 02 19 01 2A FF 02 81 00 C0 05 01
 09 80 A1 01 85 04 95 01 75 02 15 01 25 03 09 82
 09 81 09 83 81 00 75 06 81 03 C0 06 BC FF 09 88
 A1 01 85 08 95 01 75 08 15 01 26 FF 00 19 01 29
 FF 81 00 C0

001:011:000:DESCRIPTOR         1622608876.569854
 05 01 09 06 A1 01 95 08 75 01 15 00 25 01 05 07
 19 E0 29 E7 81 02 81 03 95 05 05 08 19 01 29 05
 91 02 95 01 75 03 91 01 95 06 75 08 15 00 26 FF
 00 05 07 19 00 2A FF 00 81 00 C0

dshadoff commented 3 years ago

Here is the capture with Logitech unifying receiver. The HID example initializes, but does not react to any mouse movement or clicking (with or without logging on), but there was some useful-looking log output of the initialization.

logitech_pico_log.txt

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).

hathach commented 3 years ago

What do you mean "logitech vid" ? How would I find that ?

@dshadoff run lsusb will give you a list of your attached device to your PC. Then run

lsusb -v -d cafe:

to get the configuration descriptor of your logitech then following command to get the report descriptor in readable format

sudo usbhid-dump -d cafe | grep -v : | xxd -r -p | hidrd-convert -o spec

Both are required for further troubleshooting.

dshadoff commented 3 years ago

OK, lsusb provides the following:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 04d9:0007 Holtek Semiconductor, Inc. 
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

From the above, I am assuming that instead of "cafe", I should be using the "046d" portion of the Logitech device ID ? The output from that is in this file:
lsusb-Logitech.txt

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 ?

dshadoff commented 3 years ago

Never mind, was able to locate it and get it with: sudo apt-get install hidrd usbutils

The output is attached here: hidrd-Logitech.txt

v9938 commented 3 years ago

Hi hathach

I have the same problem. tinyusb-0.10.1 didn't fix it.

I used the USB packet analyzer.

It seems that GET_DESCRIPTOR(DEVICE) did not receive the requested size. I think it misjudged the length of the IN packet of Raspberry Pi Pico.

If there is anything we can do to help, please request it.

dshadoff commented 3 years ago

@v9938 To clarify, when you say "the same problem", are you referring to: a) The original problem, where a wired mouse with side buttons has offset data in X/Y reports ? or b) The issue where a wireless mouse (in my case, Logitech) does not process data at all (which @hathach asked for more information, roughly 36 hours ago) ? These should probably be separate issues (but now that we're here, I'm not clear on how to split/splice them). My original thought had been to wait for pico-sdk v1.2.0 to be released, and then go upstream to tinyusb, once they were roughly in sync.

v9938 commented 3 years ago

Hi dshadoff My answer ’B’. I am trying to get this problem solved with pico-sdk branch tinyusb-0.10.1.

Of course, I can discuss it on another topic. If possible, I would like to wait for hathach's judgment.

dshadoff commented 3 years ago

@kilograham and @hathach should decide how to proceed. I just wanted to clarify your comment.

hathach commented 3 years ago

@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.

logitech dongle use 8 bytes control endpoint in Full speed mode, which is different than 8 bytes control endpoint in Low speed mode fixed by https://github.com/hathach/tinyusb/pull/862
some of https://github.com/hathach/tinyusb/pull/862 need to be reverted, since submitting more than maxpacket_size per buffer ( 64 instead of 8) does not work with FS device (although it work with LS)
RP2040-E4 walkaround need more fix: e.g https://github.com/hathach/tinyusb/blob/master/src/portable/raspberrypi/rp2040/rp2040_usb.c#L211 transferred_bytes should be extracted after buf_sel adjust
RP2040-E4 walkround somehow still cause an additional IN token which the dongle responded with STALL, if it is just NAK we would be fine. But we cannot blame it since we send more IN than needed

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.

lurch commented 3 years ago

Is https://github.com/raspberrypi/tinyusb/pull/7 relevant here @hathach ? Or should that PR be closed already?

hathach commented 3 years ago

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.

dshadoff commented 3 years ago

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: Bus 001 Device 005: ID 18f8:1286 [Maxxter]

The hidrd output for the device is here: wired_4button_hidrd.txt

And the output from the special (LOG=3) build of the host example is here: (For movements, I moved left, then right, then up, then down, then pressed left button, right button, back button, and forward button). wired_4button_pico_log.txt

hathach commented 3 years ago

Thanks any data available in advance is good when I switch back to work on tinyusb (on other work just now).

hathach commented 3 years ago

@dshadoff https://github.com/hathach/tinyusb/pull/891 should fix issue with your logitech receiver, please check it out to see if that works for you. It is still WIP, and need more testing.

v9938 commented 3 years ago

@hathach Some of the problems were solved. But a new problem occurred. HID open fails. I have attached the debug.log

Please let me know if there is any other information needed.

dshadoff commented 3 years ago

@hathach thank you for your progress ! I git-cloned the host-rp2040-double-buffer branch of tinyusb and built from that (it includes a few more updates than just PR 891).

A previously non-working wireless mouse ( https://www.adafruit.com/product/1738 ) is now working, however as @v9938 stated, the Logitech one is still not yet working. Logs attached. logitech_pico_log_20210611.txt

P.S. no change to the wired mouse with side-buttons, but I expect this is not yet a focus.

hathach commented 3 years ago

@dshadoff @v9938 ah this one is simple, the logitech dongle has 3 HID interfaces, the example only configure to work up to 2. I have increased CFG_TUH_HID = 4 in example. Please try again.

@dshadoff mouse report format can be different from mouse, the example only parse using the boot mouse format. Which is common used enough. If it does not match, you should look at its report descriptor (hidrd), test its report sent to PC and parser accordingly. i.e hid_mouse_report_t is not always correctly mapped to all mouse report.

v9938 commented 3 years ago

@hathach @dshadoff Thanks for the nice support. I have tried changing the sample to 'CFG_TUH_HID = 4'.

I found that there is still one problem.

HID_Open problem fixed.
1st-time connection has no problem.
After the second time connection, USBH DEVICE ATTACH and REMOVE are repeated.

The debug log as follows. logitech_pico_log_20210612.txt

The test scenario followed the steps below.

Connect Logitech receiver.
Power ON [LOG L1-]
Type 123456790 on the keyboard [LOG L743-]
Press and release the left mouse button.[LOG L1023-]
Press and release the right mouse button.[LOG L1053-]
Disconnect Logitech receiver [LOG L1083-]
Connect Logitech receiver [LOG L1092-]

hathach commented 3 years ago

try to run with LOG=1, or 0, too much printf can somehow cause some issue. If it still exists, it is entirely new bug, and should be filed as separated issue.

dshadoff commented 3 years ago

I have tried the new version and it is now reacting to the Logitech mouse, but there are two items: 1) In the same way as my earlier report about the wired mouse with side buttons, the X/Y data is offset (although it is different here). Log level 1 of this :
logitech_pico_log_20210612.txt

mouse report format can be different from mouse, the example only parse using the boot mouse format. Which is common used enough. If it does not match, you should look at its report descriptor (hidrd), test its report sent to PC and parser accordingly. i.e hid_mouse_report_t is not always correctly mapped to all mouse report.

I basically understand what you are asking me, but it seems I need deeper knowledge of how the library works. The example is certainly not showing how to do this. Where can I look for more information ?

2) as @v9938 mentioned, removing the receiver and reconnecting it, it recognizes the receiver but does not reconnect to the mouse. Log level 1 of this:
logitech_pico_log_20210612_disconnect_reconnect.txt

dshadoff commented 3 years ago

Looking at the reports at the LOG=1 level, I have determined the following:

Simple wired mouse (like RPi standard mouse): byte 0 = buttons (8-bit, bitmask) byte 1 = X (8-bit value, signed) byte 2 = Y (8-bit value, signed) byte 3 = scroll (8-bit value, signed) bytes 4-7 = apparently unused

My example Wired mouse with side buttons: byte 0 = literal value of 01 hexadecimal byte 1 = buttons (8-bit, bitmask) byte 2 / 3 = X (16-bit value, LSB followed by MSB) byte 4 / 5 = Y (16-bit value, LSB followed by MSB) byte 6 = scroll (8-bit value, signed) byte 7 = apparently unused

Logitech mouse: byte 0 = literal value of 02 hexadecimal byte 1 = buttons (8-bit, bitmask) byte 2 = apparently unused (or perhaps unused buttons ?) byte 3 = X (LSB of 12-bit value) byte 4 = Y least-significant nybble + X most-significant nybble (i.e. 0x1F: Y = 1, X is negative) byte 5= Y (MSB of 12-bit value) byte 6 = vertical scroll (8-bit value, signed) byte 7 = horizontal scroll (8-bit value, signed) ** The 12-bit encoding is hard to explain, but if X=-3 and Y = 3, this would show as bytes 3/4/5 = FD 3F 00

But I would like to know: a) how to differentiate between which one to parse b) where to obtain these values as raw data so that I can map them properly c) why the mouse report uses only 8-bit variables for X/Y if reported values from the mouse can be larger... or are there perhaps multiple mouser report structures I should be aware of ?

v9938 commented 3 years ago

@hathach @dshadoff I created #483 about the connection problem with Logitech USB receiver. Please comment if there are any problems.

hathach commented 3 years ago

I basically understand what you are asking me, but it seems I need deeper knowledge of how the library works. The example is certainly not showing how to do this. Where can I look for more information ?

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 tuh_hid_mount_cb()

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.

hathach commented 3 years ago

@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.

v9938 commented 3 years ago

@dshadoff I immediately tested it. It was an improvement over the previous version. It was a case of three things.

PANIC occurred


....
A device with address 1 is unmounted
HID device address = 1, instance = 0 is unmounted
HID device address = 1, instance = 1 is unmounted
HID device address = 1, instance = 2 is unmounted

PANIC

ep 0 in was already available


2. RESET? occurred

.... A device with address 1 is mounted

TinyUSB Host Example If you find any bugs or problems, feel free to open an issue at https://github.com/hathach/tinyusb

This Host demo is configured to support:

RTOS = Raspberry Pi Pico SDK

TinyUSB Host Example If you find any bugs or problems, feel free to open an issue at https://github.com/hathach/tinyusb

This Host demo is configured to support:

RTOS = Raspberry Pi Pico SDK

TinyUSB Host Example If you find any bugs or problems, feel free to open an issue at https://github.com/hathach/tinyusb

This Host demo is configured to support:

RTOS = Raspberry Pi Pico SDK HID device address = 1, instance = 0 is mounted HID has 1 reports and interface protocol = Keyboard HID device address = 1, instance = 1 is mounted HID has 4 reports and interface protocol = Mouse HID device address = 1, instance = 2 is mounted HID device address = 1, instance = 0 is mounted

usbh_edpt_xfer 386: ASSERT FAILED occurred

....
- RTOS = Raspberry Pi Pico SDK
HID device address = 1, instance = 0 is mounted
HID has 1 reports and interface protocol = Keyboard
HID device address = 1, instance = 1 is mounted
HID has 4 reports and interface protocol = Mouse
HID device address = 1, instance = 2 is mounted
HID has 3 reports and interface protocol = None
A device with address 1 is mounted
A device with address 1 is unmounted
HID device address = 1, instance = 0 is unmounted
HID device address = 1, instance = 1 is unmounted
HID device address = 1, instance = 2 is unmounted
HID device address = 1, instance = 0 is mounted
HID has 1 reports and interface protocol = Keyboard
usbh_edpt_xfer 386: ASSERT FAILED
HID device address = 1, instance = 1 is mounted
HID has 4 reports and interface protocol = Mouse
usbh_edpt_xfer 386: ASSERT FAILED
HID device address = 1, instance = 2 is mounted
HID has 3 reports and interface protocol = None
usbh_edpt_xfer 386: ASSERT FAILED
A device with address 1 is mounted
A device with address 1 is unmounted
HID device address = 1, instance = 0 is unmounted
HID device address = 1, instance = 1 is unmounted
HID device address = 1, instance = 2 is unmounted

hathach commented 3 years ago

@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

v9938 commented 3 years ago

@hathach I re-tested it. It seems to depend on the version of the Logicool Unifiy receiver.

Case1 PANIC occurred Firmware version 024.007.00030

Case3: usbh_edpt_xfer 386: ASSERT FAILED occurred Firmware version 012.010.00032

More information... When each receiver was connected to a Windows PC, the USB packets were as follows The max size of EP0 for GET_DESCRIPTOR(device) differs between Ver012 and Ver024.

hathach commented 3 years ago

@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.

dshadoff commented 3 years ago

@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. I am attaching the device descriptions you mentioned previously (vid, usbhid), a capture of output by normal build (NOLOG), and a capture with output from build with LOG=3 (LOG3): maxxster_vid.txt maxxster_usbhid_18f8.txt maxxster_out_NOLOG.txt maxxster_out_LOG3.txt

Mouse 2: Logitech (unifying receiver):

Connected, but "couldn't find report info" for any reports when the mouse moved. I am attaching the device descriptions you mentioned previously (vid, usbhid), a capture of output by normal build (NOLOG), and a capture with output from build with LOG=3 (LOG3): logitech_vid.txt logitech_usbhid_046d.txt logitech_out_NOLOG.txt logitech_out_LOG3.txt

v9938 commented 3 years ago

@hathach Thanks for the quick response. I have attached logs from usbtreeview.

Firmware version 012.010.00032(Model No:C-U007) Unifiying_012_010_00032.txt

Firmware version 024.007.00030(Model No:C-U008) Unifiying_024_007_00030.txt

hathach commented 3 years ago

@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.

v9938 commented 3 years ago

@hathach It seems to be difficult to dump the raw data of HID descriptor on windows. I have dumped the HID descriptor using usbhid-view. If there is any other missing information, please reply.

HID descriptor version 012.010.00032(Model No:C-U007) HIDdescriptor_for_C-U007.txt

HID descriptor version 024.007.00030(Model No:C-U008) HIDdescriptor_for_C-U008.txt

dshadoff commented 3 years ago

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: "Couldn't find the report info for this report !" So if this issue can be corrected, it should work with most mice I think.

(However, the Maxxster appeared not to produce any reports... but I don't care as much about this mouse if the others are working)

hathach commented 3 years ago

thanks @v9938 and @dshadoff for providing more info and log, I am currently switched to other work. Will check this out again later on whenever possible.

hathach commented 3 years ago

@dshadoff @v9938 I have fixed an bug with host hid set protocol, and also update example to better use boot protocol. This should work with all keyboard/mouse with boot interface. Let me know if this would work for you.

raspberrypi / pico-sdk