Open tmbutcher opened 3 years ago
Stanley00
commented
3 years ago 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
_Originally posted by @Codetector1374 in https://github.com/OpenAnnePro/qmk_firmware/issues/23#issuecomment-764429147_
BachoSeven
commented
3 years ago @tmbutcher Perhaps also this has been solved by https://github.com/OpenAnnePro/qmk_firmware/pull/41
1Conan
commented
3 years ago @tmbutcher Perhaps also this has been solved by #41
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.
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.