Keyboard doesn't work after boot sometimes

Hello!

I have Ducky One2 Mini keyboard(60%) and it works fine on Windows, but not on Linux( I checked both Ubuntu and Fedora).
The problem is, when I boot it became not working in the middle of booting process in 50% of attempts. Unplug-plug doesn’t help, only reboot. If the keyboard wasn’t shut down during the boot process - it works just fine. I tried to look through the boot log but wasn’t able to find anything related.
Here is lsusb output when keyboard was loaded:
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 3233:6301 Ducky Ducky One2 Mini RGB
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0424:2744 Microchip Technology, Inc. (formerly SMSC) Hub
Bus 001 Device 003: ID 046d:c245 Logitech, Inc. G400 Optical Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Here are boot logs for two cases: good(kb was loaded) and bad(kb was not loaded)
good - boot_good - Pastebin.com
bad - boot_bad - Pastebin.com

Any help is appreciated!

Welcome @ami00 to ask.fedora.

You forgot to tell us which Fedora Linux you use and which kernel version.
Sorry … Linux version 5.11.10-200.fc33.x86_64

Have you checked the USB cable? Do you use a laptop or a desktop computer? I just ask because of the USB connector. As long you connect direct on the motherboard you can exclude power loss. Do you use the USB cable who came with the Keyboard? Do you use an extension?

I use the latest Fedora 33 on my desktop PC (AMD Ryzen + AMD Rx570 GPU). Also I tried every USB port at the back panel(both USB2 and USB3). I use factory cable and there shouldn’t be any issues with that, because it’s never reproduced during Windows boot.
What I found out so far: udev tracks events for my keyboard when it’s unplugged and plugged in both cases(when keyboard works after boot and when it doesn’t). I can prove that using udevadm monitor. So udev layer at least knows about the device, nevertheless, after re-plug keyboard didn’t start working. Not sure what to track next.

I made a cat good_boot |grep -i "ducky" of your good and bad bootlog. As i was thinking just good one sees your keyboard.

# Apr 01 23:26:54 starcloud kernel: usb 3-2: New USB device found, idVendor=3233, idProduct=6301, bcdDevice= 0.00
# Apr 01 23:26:54 starcloud kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 01 23:26:54 starcloud kernel: usb 3-2: Product: Ducky One2 Mini RGB
Apr 01 23:26:54 starcloud kernel: usb 3-2: Manufacturer: Ducky
Apr 01 23:26:54 starcloud kernel: input: Ducky Ducky One2 Mini RGB as /devices/pci0000:00/0000:00:07.1/0000:0c:00.3/usb3/3-2/3-2:1.0/0003:3233:6301.0001/input/input2
Apr 01 23:26:54 starcloud kernel: hid-generic 0003:3233:6301.0001: input,hidraw0: USB HID v1.10 Keyboard [Ducky Ducky One2 Mini RGB] on usb-0000:0c:00.3-2/input0
Apr 01 23:26:54 starcloud kernel: input: Ducky Ducky One2 Mini RGB as /devices/pci0000:00/0000:00:07.1/0000:0c:00.3/usb3/3-2/3-2:1.1/0003:3233:6301.0002/input/input3
Apr 01 23:26:54 starcloud kernel: hid-generic 0003:3233:6301.0002: input,hidraw1: USB HID v1.10 Mouse [Ducky Ducky One2 Mini RGB] on usb-0000:0c:00.3-2/input1
Apr 01 23:26:54 starcloud kernel: input: Ducky Ducky One2 Mini RGB as /devices/pci0000:00/0000:00:07.1/0000:0c:00.3/usb3/3-2/3-2:1.2/0003:3233:6301.0003/input/input4
Apr 01 23:26:54 starcloud kernel: hid-generic 0003:3233:6301.0003: input,hidraw2: USB HID v1.10 Keyboard [Ducky Ducky One2 Mini RGB] on usb-0000:0c:00.3-2/input2
Apr 01 23:26:54 starcloud kernel: input: Ducky Ducky One2 Mini RGB as /devices/pci0000:00/0000:00:07.1/0000:0c:00.3/usb3/3-2/3-2:1.3/0003:3233:6301.0004/input/input5
Apr 01 23:26:54 starcloud kernel: hid-generic 0003:3233:6301.0004: input,hidraw3: USB HID v1.10 Device [Ducky Ducky One2 Mini RGB] on usb-0000:0c:00.3-2/input3
Apr 01 20:27:01 starcloud systemd-logind[943]: Watching system buttons on /dev/input/event2 (Ducky Ducky One2 Mini RGB)````

On the internet i saw a picture of you Keyboard. It has switches on the bottom of it. Did you find out for what dis switches are ?

Not sure what these switches are supposed for :slight_smile:
Thanks for the hints, will dig into that!

That seems impossible. If the keyboard is not plugged in then it would not be able to provide signals for udev to process nor respond to any queries from udev. Udev may look for the keyboard, but cannot actually process any signals.

If you are saying that udev sees the plug in and unplug events, then certainly it does since that is its purpose.

What does dmesg and journalctl say (complete sequence) when the keyboard is plugged in and when it is unplugged.

Also, one thing just struck me. In your first post you said

If the keyboard wasn’t shut down during the boot process - it works just fine. 

Is this keyboard powered in some way other than by the usb cable? Maybe with batteries?
If so then turning it on after boot may give it an identity that is different than expected (or no longer parsed for) so it cannot be configured.

If Ducky is powered on at the time the usb cable is connected and udev configures it do you see different messages in dmesg and journalctl than you do when Ducky is powered off at the time it is plugged in.?