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
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.
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.?