17EF:6019 Lenovo MSU1175 mouse

[hanshuebner]

Hey,

I have two Lenovo mice of the same type (MSU1175) which are not working when I start my SPARCstation IPX. If I unplug and re-plug them, they work. I hear one confirmation tone when the adapter initially starts - Would I head two separate tones for keyboard and mouse if they'd both be recognized upon power-up?

I have suspected that the problem might be a startup-up timing issue, but adding a second of delay in setup() or loop() did not solve the issue.

On one occasion, I found that only the mouse was enumerated, but not the keyboard: I re-plugged the usb3sun with both USB devices connected and heard one device confirmation tone. The keyboard did not work, however. When I unplugged and re-plugged it, it worked.

Does enumeration of both the mouse and keyboard at startup usually work, or is this a known issue?

Thanks,
Hans

[delan]

The confirmation tones can overlap, depending on USB enumeration timing, so you may only hear a longer-than-usual low tone followed by a high tone when multiple devices are connected.

The underlying USB stack has often had bugs that cause problems when enumerating some devices. For example, the Microsoft Wired Keyboard 600 (045E:0750) and 400 (045E:0752) needed a delay to work, while the WMO 1.1a (045E:0040) still fails to enumerate occasionally. Do you have the same problems with a different mouse and/or keyboard?

By the way, can you connect your keyboard and mouse to a Linux machine, and attach the output of sudo lsusb -v?

[hanshuebner]

I've verified that the problem only occurs with the Lenovo mouse, no matter what keyboard is connected. I found a couple of other mice and those tested fine.

Here's the lsusb output for the Lenovo mouse that has the problem:

Bus 001 Device 028: ID 17ef:6019 Lenovo M-U0025-O Mouse
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x17ef Lenovo
  idProduct          0x6019 M-U0025-O Mouse
  bcdDevice            1.00
  iManufacturer           1 PixArt
  iProduct                2 Lenovo USB Optical Mouse
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0022
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      46
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)

[delan]

Thanks! I’ve added this to the compatibility list. To help me diagnose the problem, can you flash the firmware below and attach the output you see on the UART_TX header? Set your UART to 115200 8N1, and be sure to connect both UART_TX and GND. If flashed correctly, your display will say “5a88d79f53.01” and the Sun keyboard interface will be disabled.

https://bucket.daz.cat/usb3sun/5a88d79f53.01%5B115200%2C8N1%2CUHID_VERBOSE%2CCFG_TUSB_DEBUG%3D3%5D.uf2

[hanshuebner]

Here is the log file. WIth the debug firmware, the timing seems to be different enough to make the enumeration at power-up somewhat work, although the tones don't sound quite right to me. I recorded videos with the debug and the non-debug firmware for comparison:

ZOC2311__dev_tty.usbserial-1221200309.log

https://photos.app.goo.gl/pNuCwReeYDb4q52j6 (debug firmware)
https://photos.app.goo.gl/WJcabqi5TXRbQhb89 (non-debug firmware)

[hanshuebner]

Hi Delan, I'm seeing the same issue with other keyboard/mouse combinations, so it does not seem to be a specific incompatibility. How can I help diagnosing this further?

[delan]

This smells like a previous tinyusb bug with the Microsoft Wired Keyboards 600 and 400, which I found by removing TU_LOG2 and TU_LOG3 lines until I could reproduce the problem, then inserting a delay there (see tinyusb2.patch).

Upgrading tinyusb and pico pio usb may improve compatibility, but they are currently held back due to an unknown tinyusb issue (adafruit/Adafruit_TinyUSB_Arduino#296). In the meantime, you can try binary searching the log messages until you find a place where we can try inserting a delay, like I did for those Microsoft keyboards.

If you haven’t already tried the prebuilt firmware 1.5, be sure to try that first in case that solves your problem.

[hanshuebner]

I've tried the 1.5 release binary and with that, the problem does not exist. That puzzles me because I have built the firmware from the default branch, and there are no differences in the firmware compared to 1.5. I'm using a Mac, but I'm not sure how that'd matter. In any case, I think the problem is solved for me now.

[delan]

Did you remember to apply the two patches in the firmware docs? You may be affected by hathach/tinyusb#1786, which has been fixed in newer versions of tinyusb, but with our version needs tinyusb1.patch.

Otherwise there may be a gap in our build process causing a reproducibility problem. Can you tell me:

• the sha256 of the firmware.uf2 or firmware.elf you built
• what commit you built it from
• the output of pio pkg list

Either way, great to hear you got it working!

[hanshuebner]

I'm more inclined to think that I have a gap in my documentation reading process. With the two patches applied, the firmware I built works just fine. I feel particularly stupid because of this:

Thank you for your help!