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.

Maybe an interval is not supported by the gadget code, while U-Boot requires 
it. Would be interesting what a "Get_Idle" request returns.

Kind regards, Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034     mobile: +49 151 50412019

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to