A propos plugin capabilities:
https://github.com/keyboardio/Kaleidoscope-Unicode – I wonder if you can confirm it works on Linux/KDE Plasma 5? I am currently using XKB layouts for switching between scripts (Latin and many Indic) that I use. Would be interesting if I could directly use the keyboard’s firmware capabilities for that!
Most likely, yes. It works under GNOME3, can’t see why it wouldn’t with KDE. Behind the scenes, it uses an unicode hex-input thing, so when you input, say 👪, it sends Ctrl+Shift+u hexcode SPC to the host.
then it won’t work with Qt/KDE applications: https://bugs.freedesktop.org/show_bug.cgi?id=26747
Would it be possible for the plugin to input the surrogate pairs? That works with Qt/KDE which uses UTF-16 all through.
IIUC from your page on the Focus plugin it is possible for the keyboard to know what is the active window. In that case, it could shift from direct UTF-32 input to UTF-16 if that is possible.
Hmm just realized that that’s not the point at all. If there is no way to input arbitrary codepoints other than sending scancodes, then it doesn’t matter whether it is UTF-32 or UTF-16, it can’t be done.
@algernon @algernon @algernon please pretty please can you look into fixing this X bug like you fixed the warp one? 
…1008!
It might be slightly easier to write a little program that intercepts the C-S-u key & reads the codepoint…While the normal input works for me most of the time, Emacs intercepts the C-S-u keys, so I taught it how to treat it the same as Gnome: https://github.com/jamesnvc/dotfiles/blob/master/emacs.d/user.el#L290. Could probably generalize that with a little daemon process. I’ll have a try implementing that.
I hope you mean for KDE… I mean something that works on KDE whether it uses the KDE libs or not…
Right, make the Gnome-style input work on KDE (since that’s how the Unicode plugin works).
Well, the warp one was eventually fixed in firmware, the original issue is still present in libinput… 
As for doing this in Xorg… I worked with Xorg (then XFree86) code before, not looking forward to do it again. But a small tool that intercepts C-S-u should be doable. I’ll see what I can do, but this is going to be pretty low on my todo list for now, I’m afraid, so if anyone else gets there first, so much the better! It shouldn’t be too hard.
I have a very hacky solution here…it sort of works, but the main problem is that the C-S-u still goes to the underlying application (so, for example, when typing in a terminal, it will delete the line before typing the unicode char).
I’ll try to look into a more complete solution, but I think that will mean actually using Xlib.
FWIW, there is a daemon linked to in the bug report above, I just updated that to support xdotool3, and it works like a charm so far. Will push it to GitHub in a bit. It will need a little shaking up, because it currently expects Ctrl+Shift+u to remain held.
Anyway, quick hack is going up in an hour or two (babies need me now, so will finish later).
Current code is up on GitHub:
It doesn’t work with the Unicode plugin yet, but I’ll get there soon. It may have issues, as this is code someone hacked up some 4 years ago as a proof of concept.
Update: I just tested it, and when using the C-S-u codepoint SPC sequence by hand, it works. When using it via the Unicode plugin, it does not seem to. Not quite sure why, perhaps some timing issue. May debug later, but patches are - of course - more than welcome. Testing too. 
Hmmm but:
So again my question: is it possible to emulate scrolling by the M01 firmware alone?
Hmm perhaps this Unicode thing should be split out into a separate thread? I sorta got frustrated with the “only so many questions on your first day” else I would have initially started on a separate thread. Can someone do it? Thanks!
OK I’m testing on Kubuntu Xenial which has:
libx11-dev:amd64 (2:1.6.3-1ubuntu2) libxdo3:amd64 (1:3.20150503.1-2)
But a few things I’m not clear about:
The code XKeysymToKeycode(dpy,XK_U) seems to indicate that U is a necessary part of the input sequence. Yet the readme says only:
- Press Ctrl
- Press Shift
- Type the hexadecimal code, e.g. 3b4 for Greek delta δ
- Release Ctrl and Shift
I guess the README needs to be updated (and I’ll send in a pull request once the following problem is solved).
Anyhow, it is not clear whether the U should be continuously pressed as well or only Ctrl and Shift. From the GNOME official help and this SuperUser post it only seems as if Ctrl and Shift should be held down. I am assuming the same has been implemented by this applet. So that is what I am trying now,
But I am trying both GTK and Qt apps on my platform: I press Ctrl Shift U, release U while holding down Ctrl Shift and I observe that my current application loses focus i.e. the text cursor disappears. I presume this is the “grab”. Then I input the 3b4 suggested in the README followed by space, but nothing happens except that my application gets back the focus i.e. the text cursor reappears.
I tried prefixing it by 0 but that doesn’t help either. I tried putting it in my autostart and rebooting but no fruit there too. I tried loading from a terminal to see if there are any error messages printed but nothing there either.
I tried on both GTK (Firefox) and Qt (KWrite) applications.
Please advise!
The sequence seems to be “press Control, press Shift, press U, release Control, Shift, U, type the hex, space”. That works for me, at any rate.
Hi what Linux/version are you using? This still doesn’t work for me.
Ubuntu 16.04.3 LTS, with i3wm under lightDM. I should clarify that I mean the keysequence is what works for me using the standard Gnome input thing (and is what the Kaleidoscope plugin uses); I haven’t tried the tool algernon linked.
Yeah, I have not touched the readme. The code requires Ctrl+Shift+U all held at the same time to trigger the daemon’s functionality. You can release them after, though.
Yep.
I’ll add some debugging to the tool next time I have some capacity, to help us see what is happening.
Hi can I ping you on this issue?