You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 16, 2024. It is now read-only.
Seems to be very similar to Issue 23 (the media keys)—basically, when I use unicode input while the keyboard is plugged in, everything works smoothly. But as soon as I switch to bluetooth mode it starts sending the hex codes instead of using WinCompose.
(Just to be clear, I do have my config and rules files set to enter Unicode characters through the Wincompose method.)
It also, weirdly, makes it so that the keyboard enters DFU mode when it's plugged back in if the bluetooth is off, although this can be exited by flipping the bluetooth switch on then off while the keyboard is plugged in.
For example:
Plugged in: 🙂
Bluetooth: u1642[enter]
(Just to be clear, the keyboard is sending a enter keystroke, not the characters "[enter]")
Getting the keyboard reconnected to the USB (in the on-off fashion described above) does fix the unicode issue, so perhaps this is a problem of the bluetooth connection just dropping characters? But it seems like if that were the case then it would work sometimes, instead of never. That being said, it's a little inconsistent in exactly what gets sent: sometimes the "u" makes it in, sometimes it doesn't; sometimes the hex code only has some of the characters; sometimes the enter key is apparently sent multiple times.
For example, here's what I get when I push the key 5 times in a row (with enter keystrokes removed for ease of reading):
u1642 u1642 1f42 1642 u164
System Information
Keyboard: AnnePro2 C18
Operating system: Windows 10
Any keyboard related software installed?
AutoHotKey: yes, but it doesn't work even when all scripts are turned off
Karabiner
Other: Wincompose
Sorry about the initial title, I started typing this while having "H" mapped to a unicode character for diagnostic purposes, and then promptly forget about it.
The text was updated successfully, but these errors were encountered:
Thanks for your detail report, but sadly, it has the same root cause as in #23
This is a "won't fix" since we are currently simply delivering the HID code to the bluetooth controller. Unless we can see how is the stock firmware is doing it, or is it supported at all? we can't really fix this
Nope. That PR is solely for media key support. Though I tested unicode entry over bluetooth and it works for me on linux. ツツツτツツτツττツ
It's not perfect and sometimes fails but it works.
* add initial support for Redragon K580 (resolvesqmk#33)
* [Redragon K530] Initial support for Redragon K530 Draconic
* updated keymaps
* add k580 to build script
* updated chconf & halconf
* sync upstream, move side leds to default keymap
* [Redragon K580] Condense LED matrix configuration
* [Redragon K580] Add side leds to rgb matrix
* [Redragon K580] Fix side LED channel mismatch
* fixed macro key LEDs and removed side LED control (as they are part of the matrix now), thanks @jath03
Co-authored-by: Adam Honse <[email protected]>
Co-authored-by: jath03 <[email protected]>
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
bugSomething isn't workinghelp wantedExtra attention is needed
Describe the Bug
Seems to be very similar to Issue 23 (the media keys)—basically, when I use unicode input while the keyboard is plugged in, everything works smoothly. But as soon as I switch to bluetooth mode it starts sending the hex codes instead of using WinCompose.
(Just to be clear, I do have my config and rules files set to enter Unicode characters through the Wincompose method.)
It also, weirdly, makes it so that the keyboard enters DFU mode when it's plugged back in if the bluetooth is off, although this can be exited by flipping the bluetooth switch on then off while the keyboard is plugged in.
For example:
Plugged in: 🙂
Bluetooth: u1642[enter]
(Just to be clear, the keyboard is sending a enter keystroke, not the characters "[enter]")
Getting the keyboard reconnected to the USB (in the on-off fashion described above) does fix the unicode issue, so perhaps this is a problem of the bluetooth connection just dropping characters? But it seems like if that were the case then it would work sometimes, instead of never. That being said, it's a little inconsistent in exactly what gets sent: sometimes the "u" makes it in, sometimes it doesn't; sometimes the hex code only has some of the characters; sometimes the enter key is apparently sent multiple times.
For example, here's what I get when I push the key 5 times in a row (with enter keystrokes removed for ease of reading):
u1642 u1642 1f42 1642 u164
System Information
Sorry about the initial title, I started typing this while having "H" mapped to a unicode character for diagnostic purposes, and then promptly forget about it.
The text was updated successfully, but these errors were encountered: