Durgod K320 USB Keyboard

I’m an Italian newcomer in the RISC OS world, with a brand new 4té.
I’ve bought a fancy new USB mechanical keyboard for a true retro feel, the Durgod K320.
Unfortunatly it doesn’t work, or crashes the system.

BUT (and that’s the interesting part) it works perfectly if I:

1. Start the computer with the keyboard disconnected.
2. Load the USBHID module from the !HID application.
3. Connect the keyboard.

If I connect the keyboard without the USBHID module loaded, or I load the module after connecting the keyboard, everything crashes.

There’s something I can do to help debug the issue? I’m a developer, but I’m not very familiar (yet) with RISC OS.

I noticed a lot of dprintf on the USBDriver source, but I suspect there’s no way to see the messages without recompiling the ROM, is it correct?

Stupid question: does it works OK without USBHID?
(technically, there is no reason to use USBHID for a keyboard with generic layout).

That’s the interesting detail, it doesn’t work without USBHID. If I connect the keyboard without loading USBHID, it just doesn’t work or creates strange side effects (usb drive not recognised, whole operating system crash).
If I connect it and then load USBHID it crashes 100% of the times.
If I load USBHID and then connect the keyboard, it works 100% of the times.
My impression is that USBHID overrides the USBDriver behaviour for HID devices, effectively preventing a bug.

usb drive not recognised, whole operating system crash

Ho ho… Is it plugged on an internal or external hub or directly to the Pi?
It seems to be a power issue. Quite common, especially with these kind of power hungry devices.

It’s not one of these keyboards covered in RGB lighting, so it shouldn’t be that power hungry. It might be worth looking at what !USBInfo has to say about it.

Thank you to both David(s) for help!
I tought that the issue was a power one, so I bought a powered USB hub, but the behaviour is the same.

I’m attaching the USBInfo report for the device, if it can help:

   Device:6
      DeviceFS  : USB10
      USB spec  : 2.00
      Class     : 0     (Defined at Interface level)
      Subclass  : 0     
      Protocol  : 0     
      MaxPacket : 64
      Vendor    : 2f68  Hoksi Technology
      Product   : 0082  DURGOD Taurus K320
      Release   : 1.04
      Speed     : Full speed (12 Mb/s)
      NumConfigs: 1

Config: 1
MaxPower  : 500 mA
Attributes: (Remote Wakeup)
Interfaces: 3

Interface: 0
Alternate: 0
Class     : 3     Human Interface Device
Subclass  : 1     Boot Interface Subclass
Protocol  : 1     Keyboard
Endpoints : 1

Endpoint: 1
Direction : IN
Transfer  : Interrupt
MaxPacket : 8
Interval  : 1 ms

Interface: 1
Alternate: 0
Class     : 3     Human Interface Device
Subclass  : 1     Boot Interface Subclass
Protocol  : 0     None
Endpoints : 1

Endpoint: 2
Direction : IN
Transfer  : Interrupt
MaxPacket : 16
Interval  : 1 ms

Interface: 2
Alternate: 0
Class     : 3     Human Interface Device
Subclass  : 0     No Subclass
Protocol  : 0     None
Endpoints : 2

Endpoint: 3
Direction : IN
Transfer  : Interrupt
MaxPacket : 64
Interval  : 1 ms

Endpoint: 3
Direction : OUT
Transfer  : Interrupt
MaxPacket : 64
Interval  : 1 ms

The USBDriver just uses Interface 0, Alternate 0. It doesn’t do anything fancy so can’t see why your keyboard would fail. It sounds like the crash is in detach_keyboard as it happens When HID loads which presumably would make riscos detach the keyboard. If HID is already loaded when you plug in the keyboard you won’t get the keyboard detach. but keyboard_detach doesn’t do much. It may be that HID is using the other interfaces.

I noticed a lot of dprintf on the USBDriver source, but I suspect there’s no way to see the messages without recompiling the ROM, is it correct?

yes

Probably time to get the RISC OS sources set up locally, so you can build your own USBDriver (the keyboard and mouse driver).

Then you can try making various tweaks, perhaps in the HID parsing, which will hopefully bring your keyboard to life.

You should be able to soft-load a new USBDriver without faffing on building an entire ROM.

There is no HID parsing. RISC OS uses the keyboard boot protocol – it just reads a simplified standard structure from an interrupt endpoint and sets leds when necessary – as simple as it gets really. It’s likely that HID is not using the boot protocol as I presume that HID can use any multimedia keys and that wouldn’t be possible with the boot protocol. That may explain why hid works and usbdriver doesn’t, there may be something quirky about the keyboard’s boot protocol.

Edit: Here’s the usbkboard file

Ah… Don’t know what I was thinking of there! It has been a while, but I did once read through the keyboard and mouse drivers. I had this vague recollection that there were some areas that were a bit simple. I am probably thinking of something else entirely!

I have never built an OS module with debug enabled, nor explored where the debug will appear. I imagine that you would need to do that to make any serious headway with something like USBDriver.

Is it sending multimedia key events? Unless RO now supports them, they certainly used to cause issues for the OS as it didn’t acknowledge them.

You might need to code a bespoke HID driver for it, as I did for the pi-top keyboard in which case you could use my HID handler Module as a starting point. I cheated somewhat though as I didn’t code a USB attach/detach handler – something I do plan to add soon.

If you want to attempt to read the HID data from the various endpoints, there’s some example BASIC code in this

Good news: I’ve solved the issue.

The problems with this particular keyboard (but may be applicable to other non-working keyboards as well) were twofold:

1. It has two interfaces, one used for Boot Protocol, the other for the standard Report Protocol. Unfortunately, probably due to its super-fancy macro recording capabilities, on the HID Report it declares itself as a kebyoard/mouse/whatever. So RISC OS matches the keyboard two times: one as a keyboard (with boot protocol) and one as a mouse (with report protocol, as RISC OS doesn’t support keyboards with report protocol). Using the USBHID driver solved the issue, as it matched on a single interface.
2. On the boot protocol, as soon as the IN port interrupt are enabled, the keyboard answers “STALL”, and it will continue to do so until the first key is pressed. The USBDriver send a “HALT Clear” message when it recives a STALL, and resets the interrupt, that causes another STALL, another “HALT Clear” and so on… After about one hundred of cycles, the keyboard becomes grumpy, and stops responding on the control port. Unfortunately USBDriver (even if it seems to have a 5 seconds timeout on control port messages), doesn’t honor the timeout, and the port hangs.

Now I’ve solved the issue softloading a patched USBDriver that ignores the keyboard on the mouse driver, and ignores the STALL on the keyboard one.

I don’t know if it could be useful for other people.

In the meantime, I’ve learned how to compile the kernel, how to compile a specific module in debug mode, how to use DADebug, and that the file and printf backends of the debug library cause the funniest effects when used on a driver that operates in interrupt mode: if it’s useful I could write a short note on the wiki about it.

Thanks to everybody for the insights and support!

In the meantime, I’ve learned how to compile the kernel, how to compile a specific module in debug mode, how to use DADebug, and that the file and printf backends of the debug library cause the funniest effects

debug_set_device(REPORTER_OUTPUT);

can be useful as it redirects the output to a Reporter window and you can see the debug output in real time.

Well done! Delighted that you solved your problem, and impressed you have gone from zero to kernel/USBDriver developer! :)

In my opinion, this would be most welcome on the wiki.