Sergey Vlasov

This change does not seem to be needed, because both `defaultNix` and `shellNix` are already based on `result` (only the value for the `default` key is changed, and `default` is...

Using `inherit` to shorten the code results in something like this (it still hardcodes `github.com`, but at least you can fork the `flake-compat` project and use that fork without any...

The standard practice in QMK is to squash commits when merging a PR, so you don't need to worry about that — use separate commits if it's easier for you.

The original problem is most likely caused by X11 not applying the XKB settings to a hotplugged keyboard. Some desktop environments may reapply those settings automatically, but in some simpler...

There is a pending PR that does a similar thing: * #9126 Maybe that PR should be moved forward (there are some concerns that it also changes the behavior of...

One possible reason to create separate HID interfaces is that various USB APIs may prevent concurrent usage of the same HID interface by different apps, therefore running an app which...

> I implemented this HID usage on my firmware, but unfortunately Windows API (UWP) "eats" the device and prevents normal USB HID enumeration. You can access it through the UWP...

Probably this piece of code does not work correctly when a modifier keycode comes from a combo: https://github.com/qmk/qmk_firmware/blob/06a7a1c205f43c0c4c435d48de5ab3893398b19d/quantum/action_tapping.c#L228-L250 The intent of that code is to process key release events immediately...

> `HOLD_ON_OTHER_KEY_PRESS` applies globally to _all_ dual-role keys, not just mod-taps. Actually now I remembered another reason why I did not like a global `HOLD_ON_OTHER_KEY_PRESS` — it also affects the...

So it seems that some people really want this feature: - #18349 - #18353 The suggested implementation in #18353 does things in a different way — it does not touch...