Sorry, the on-screen keyboard is not really a keyboard. It only resembles one with its shape, but was never meant to have “keys”. It’s better to think of it as a program that emits letters.
I wrote about it more here: https://dcz_self.gitlab.io/posts/not_keyboard
The short answer is, you need to find something else if you want to have keyboard emulation. I wrote virtboard but I no longer maintain it (I think the sway project might be). Otherwise a physical keyboard might be a solution for you.
Aha. Is this the reason why keybindings in my game does not do anything?
I have programmed my game with Qt and bound some keys. For instance I capture key-press on space to start and stop the game clock. But nothing happens if I use space on the Squeekboard.
However if I in-game focus on a input field, the Squeekboard of course just works.
In second thoughts, if it should work, it could also have something to do with which Qt widget that is active. 
and therefor does not capture the key press.
It doesn’t need to be full size.
or
In some cases it may be possible to reconfigure the application that requires a Super key combination in order to bind a different key to that function.
Kind of, yes. We do fall back on keyboard emulation for toolkits which don’t accept text, but I’m not sure if Qt supports it yet. If the panel pops up on its own, then you don’t get keyboard emulation. If not, then your game could be confused about keycode mappings, which we assign dynamically.
So maybe a future update of the phone will have things like Super key?
There are two ways to get there:
A keyboard emulator is not a goal of the Librem 5 team at the moment.
Interesting points. I have just tried to launch the game and the panel does not pop up automaticly.
So the next thing i’ll try is to see if I capture the key press event, and if so, I can see which keycode I get.
I’m btw not satisfied how I made the key press capture in the game as it is right now. it should be another widget where i do this. But yeah, I didnt knew much back then. haha. so there is a possibility that this could be the problem, although it works on the computer.
I might just make a simple qt example to test it out with key presses. Just to see how qt reacts.
Make sure to restart squeekboard and check again. Hint: it may be different. Squeekboard cares about characters, not keys.
Thanks. Will do. 
Please share if you find a work-a-round for the Super key. I think that is what the Mac’s call their power key and M$soft calls it Windows key?
Tnx
~s
A Purism developer employee told me I could write an app to get this done, because Purism has not doe it yet. If they have not done it, meaning not included a keyboard layout that includes a super key, why is the keyboard short cut, that requires a super key, even mentioned in the help section for short cut key combinations? Put things in the phone that actually mean something, and function, not stuff that may be used, sometime in the distant future?
I have got my Qt test application working. I’ll post something about it later today. However it has unfortunately not really something to do with super key.
What are you trying to achieve with the super key? Shotcuts for…?
Probably a bug. Where was it mentioned?
Yeah [citation needed]
but it might be that the shortcut actually works when the Librem 5 is docked. Without more specific information, who can say?
Sorry if this is on the edge of the topic, however still seems relevant, and maybe useful for someone.
(The second last video is about the super-key)
So I made a small Qt app, and it of course works as expected. So the problems I had with my game is that I do not handle it properly.
As I suspected it has something to do with the way the widgets are in focus in Qt:
Standard use of my app printing key codes:
This shows how space can have different roles depending on which widgets that are focused.
Really not anything new or interesting. Although important for me, to make my game work properly.
As @dcz mentioned the way the Squeekboard works, a “key” can have different key codes depending on which layout is used etc.
In Qt it overall seems that the “keys”/“letters” has the same code. But when looking at what Qt calls “native virtual code” the letter “v” in this example has three different codes; one with the Danish layout, one with the English layout and one with the terminal keyboard. And actually a fourth with a physical keyboard as in the video bellow. I did not manage to get different results by restarting either Squeekboard or the phone. But I guess that somehow the “native virtual code” could change regard order of keyboard layouts and number of layout activated.
Now back to the topic. If a physical keyboard is attached it is no problem to use the super key.
But I do not know how complicated it would be to add this to a Squeekboard layout.
I have not investigated this at all and have no real knowlegde about the Squeekboard.
In all of this I experienced that when I have made a desktop entry for my “app” it take a long time for it to load. However if I executes it from the terminal it just start right away.
Anyone know why this is the case?
Looks like your desktop file tells phosh that your app supports startup notifications so it shows a splash screen, but the application doesn’t actually handle it properly so phosh doesn’t know when to hide it and only does so after a 5 second timeout.
Ahhh. Silly mistake.
It works now. Thanks.
I think what’s being called virt-code may be what others call keysym, which is not going to change. The nat-code is called keycode in other places.
If you know the keysym of the super key, you can take a look at Squeekboard’s layout engine and assign the keysym to a button explicitly. Or a modifier, but modifiers are more hardcoded so you might need to change the sources.
I should have the keysym. I can take a look to see how much effort it takes to fix.
@kazmroz is it here that you find the super key mentioned?
and is it this that you want to use the super key for?
