On Fri, Sep 04, 2020 at 08:53:34PM +0200, Stefan Brüns wrote: > On Freitag, 4. September 2020 17:43:37 CEST Ludwig Nussel wrote: > > Stefan Brüns wrote: > > > On Freitag, 4. September 2020 14:25:37 CEST Ludwig Nussel wrote: > > >> Fabian Vogt wrote: > > >> to get rid of the otg descriptor. That's not the issue though. > > >> I found that when setting the hid subclass to 0 the device appears in > > >> u-boot. > > >> Still doesn't work though. It's not specific to the rpi3 either. > > >> Connecting a A10 olinuxino on the other side also gets no keyboard input > > >> either. > > >> Looking at "usb info" one can see that the gadget has two endpoints. One > > >> for input and one for output. Whereas real keyboards and also an Arduino > > >> pretending to be a keyboard only has an input endpoint. Could that be > > >> relevant? > > >> I couldn't find how to disable the second endpoint via configfs though. > > >> Any ideas? > > > > > > Although USB Keyboards all use the HID protocol, grabbing into the > > > > stack of > > > > > Keyboards I used when extending the Rpi1-3 dwc2 implementation: > > > > > > - USB low speed (1.5 MBit/s) and USB full speed (12 MBit/s) > > > - Control + Interupt IN is required, OUT is optional > > > - Devices may have one or multiple interfaces (e.g. Logitech Unifying > > > receivers). > > > > > > As the OTG device appears under some circumstances, physical layer > > > > problems > > > > > are unlikely. > > > > > > Does the OTG device only emulate an USB Keyboard > > > > (Class/Subclass/Protocol: > > > 3/1/1), or also a mouse (3/1/2)? U-Boot might be confused when a > > > > device has > > > > > interfaces with both protocols. > > You may try this patch: > https://build.opensuse.org/package/view_file/ > home:StefanBruens:branches:hardware:boot/u-boot/0001-usb-kbd-Also-accept- > keyboards-with-Interrupt-OUT-end.patch?expand=1 > > > It's complicated indeed. Fabian pointed me at > > https://github.com/u-boot/u-boot/blob/9bfb567e5f1bfe7de8eb41f8c6d00f49d2b9a4 > > 26/common/usb_kbd.c#L461 So u-boot doesn't even accept devices with more > > than one endpoint. Too bad usb_f_hid hardcodes IN and OUT. > > Also, u-boot requires the boot flag to be set but at the same time when > > the gadget has that it's not shown. > > So I've enabled debug in u-boot and see this: > > > > usb_control_msg() usb_control_msg: request: 0x9, requesttype: 0x0, value > > 0x1 index 0x0 length 0x0 > > usb_select_config() new device strings: Mfr=1, Product=2, SerialNumber=3 > > usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, > > value 0x300 index 0x0 length 0xFF > > usb_string() USB device number 3 default language ID 0x409 > > usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, > > value 0x301 index 0x409 length 0xFF > > usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, > > value 0x302 index 0x409 length 0xFF > > usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, > > value 0x303 index 0x409 length 0xFF > > usb_select_config() Manufacturer openSUSE > > usb_select_config() Product openQA > > usb_select_config() SerialNumber fedcba9876543210 > > usb_kbd_probe_dev() USB KBD: found set protocol... > > usb_control_msg() usb_control_msg: request: 0xB, requesttype: 0x21, > > value 0x0 index 0x0 length 0x0 > > > > usb_kbd_probe_dev() USB KBD: found set idle... > > usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, > > value 0xA00 index 0x0 length 0x0 > > usb_kbd_probe_dev() USB KBD: enable interrupt pipe... > > Timeout poll on interrupt endpoint > > Failed to get keyboard state from device 1d6b:0104 > > requesttype: 0x21 - Class specific request to interface > request: 0xA - Set_Idle > value: 0xA00 - 0xA * 4ms = 40ms report interval during idle, 0x0: applies to > all reports > > So according to the request, the OTG device should send report at regular > intervals even without state changes, but the keyboard poll code times out.
You can also try to press a key while u-boot is scanning for the keyboard. IIRC the dwc controller on the rPi has some issues that make it time out when other controllers would receive the packet. Thanks Michal -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
