[Bug] Keychron Q2 default config has some issues on Linux #16097
Comments
|
Reproduced this without any changes to the source: > rm -rf ~/.config/qmk
> rm -rf ~/qmk_firmware
> qmk setup
> cd qmk_firmware
> nix-shell
> qmk config user.keyboard=keychron/q2/rev_0111
> qmk config user.keymap=ivarwithoutbones
> qmk compile -kb keychron/q2/rev_0111 -km ivarwithoutbones
> qmk flash -kb keychron/q2/rev_0111 -km ivarwithoutbonesI've tried different USB ports, and all other revisions of the keyboard in this repo as well. Flashing log: |
|
The key event issue may be related to a ChibiOS bug in the STM32L432 chip support: https://forum.chibios.org/viewtopic.php?f=35&t=6012 (apparently the rightmost matrix column on Keychron Q2 uses the However, there might be something else at play here, because the current code for |
Thanks for the quick response! I'll see if I can try and see if I can hack anything together to make this work, although this seems a bit beyond my skill level 😅 I tried adding the GPIO flags myself, with no luck. Also, i can confirm #16034 caused the knob issue, after reverting only this file from 62cd02d it works again! Should i open a PR for that? There's still a few issues, for example when pressing the knob button mutes your volume as expected, but it still inputs some random numbers. Still better than nothing though :) |
|
A few more things: when i quickly spam the right (broken) column, the entire keyboard seems to crash. No input will be accepted until I reboot it, and the RGB hangs. Is there some kind of debug log / stacktrace for QMK? Might help identifying this issue. I can reproduce this on master as well. |
The issue that commit fixes is that the codeblock being edited was not properly formatted when submitted to QMK. If you compile from a branch that includes 16034, you need to move the keycodes intended for the encoder rotation action to either side of the keycode assigned to the encoder click (e.g. Volume Down, then Mute, then Volume Up). Sadly, the rest of your issues strike me as some sort of hardware problem (either component failure, or some bug in a dependency somewhere). |
The Does the encoder rotation still misbehave if you try the As for your problems with the right column, I unfortunately don't have any hardware with the STM32L432 chip, but I tested the
dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D ~/Downloads/Keychron-Q2-ANSI-Knob-Version-Firmware_V1.0.2.bin
|
|
Just wanted to chime in that I'm hitting the same issue as @IvarWithoutBones where the arrow keys are inserting garbage (which makes it less likely to be a hardware failure). The stock firmware has no such issue. |
|
I am experiencing this issue too. I have tried using the keyboard, compiling and flashing the firmware on Window/Linux/macOS, and this bug occurs on each platform. Stock firmware does not have this issue. |
|
I can report this behavior as well on rev_0110 (ansi, no knob) |
|
Thanks for the help everyone, I really appreciate it.
Oops, I shouldn't have used that as an example. I only tried that macro when debugging to see if it magically fixed everything. I've never used via or its keymap, and ill avoid it in the future. Thanks for the advice. I actively use the default keymap, where all issues occur exactly the same.
Aha, I never considered that before. After checking all my switches though, they all seemed fine. I tried putting in a few switches I've never used before on the problematic keys, but that didn't seem to change anything. I tried the stock firmware as suggested, and there everything works as expected. On keychrons repo https://github.com/Keychron/qmk_firmware the issue occurs as well. This definitly seems like a qmk issue.
That makes sense, Thanks! This issue occurs with the default generated keymap file though, any chance we could get a fix in master? |
|
I believe PR #16200 fixes the issues with the arrow keys activating the entire lower row - all it does is re-add |
|
Also, I only added the file to rev_0111 (ansi, knob) as that's the only board I can test with. It'd be good if someone could confirm it works with the other revisions as well. |
|
To be honest, at the beginning of release, we used our own matrix scanning code (matirx. C) in the master branch, maybe someone had optimized the code and deleted "SRC += matrix.c" in the rule.mk, so the firmware compiled with the master branch will produce this bug #16097. You can get the code from q2-keychron or replace R7 from 10K to 100k, then the PH3 (boot0) can be used as a general I/O and we don't need change the current code , Thank you~ |
|
@tzarc I can confirm that commit fixes the issue on my rev_0111 Q2. |
|
Thanks for the fix, this works perfectly! The knob issue also seems to stem from my environment, as it works perfectly fine on the stable branch of my distro. |
Describe the Bug
A few keys on my keychron Q2 (rev_0111) do not seem to be interpreted correctly with the stock config on Linux.
Some keys output a lot of seemingly random keycodes, instead of the expected key. See this log from
sudo evtestwhen pressing the right arrow key once:The up arrow key outputs
ZXCVBNM<>?, and sometimes selects some text in my terminal. The down and left keys work fine though.Happens on both the mac and windows profiles. Note that i have only tested this on linux.
The rotary knob used to control volume perfectly as it should, but after rebasing my repo to commit 0f0e909 it seems to have regressed. My previous checkout was from the 26th, there the knob functioned as expected. All other issues were present there as well though.
outputs the text:
1234567890-. There's even more key events from a single press, but I think you get the point. Rotating the knob doesn't seem to do much either anymore. I haven't had the time to bisect this yet, but perhaps #16034 may have something to do with this?The two function keys below the knob also suffer from this issue where a lot of key events are send.
The only change I made locally was rebinding
KC_ESCtoKC_GRAVE, andKC_CAPS->KC_ESC. here are the relevant lines:// Everything above and below this has been unchanged. [WIN_BASE] = LAYOUT_ansi_67( KC_GRV, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_MINS, KC_EQL, KC_BSPC, KC_MUTE, KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, KC_LBRC, KC_RBRC, KC_BSLS, KC_DEL, KC_ESC, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, KC_SCLN, KC_QUOT, KC_ENT, KC_HOME, KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, KC_UP, KC_LCTL, KC_LGUI, KC_LALT, KC_SPC, KC_RALT, MO(_FN2), MO(_FN3), KC_LEFT, KC_DOWN, KC_RGHT),The mac layout didn't make a difference.
I also could not seem to get
KC_PRINT_SCREENbound to any key, it wouldn't even show up inevtest.System Information
I am not extremely familair with QMK, apologies for the noise if this is because of an issue in my env.
Additional Context
The text was updated successfully, but these errors were encountered: