Explaining keyboard layout proposals. Fn hotkeys updated, language switching, powertoggles etc

Functional layout vs reduced layout

  • Total voters


This is how i see it, tell me if im forgetting someone, or improvements could be made with the expectations a group brings along. Feel free to diversify.

English users, all good.

International users (that need extra letters), remap/select language away.

Advanced international users (that need extra letters) . Learn how to type [] {} <> with language layer.

Novice international users Make the keymat where the changes to the language area is visible for said language.

People that need diactrics. Find compose symbol, type letters. Difficulty with the , and . button since they have many symbols.

                                                OR   learn to use language layer.

I think this covers the market where the pyra can hope to sell any quantities. It is as good as it gets with respect to what the amount of keys and placement constitutes.
Last edited by a moderator:

Image for reference.

My thoughts on why mixing things into one assumption is bad:

Mixing many things into one modifier means second spot on a key is sometimes for shift, and sometimes for respective input from the mixing-key. You end up having to do colour-codes to differentiate because the placement is the same. Real keyboards use position, and another problem is created with colours. They are the first thing the mind is drawn to, something that one a keyboard looks toy-like.

The user-demographic for the pandora is adults. A certain segment of users want it to be professional-looking. There is no such benefit to be had from people wanting more colours. Colours add cost too. And they take away from contrast with the back-lighting.

One mixing-modifier as mentioned means a lot of 2 prints per key. 2 prints per key is at its very nature a non-ideal use of area. 1 and 3 is better with the given space, since it utilizes it better, and more standard since you will moreso find that on a regular keyboard.

AltGr is an expected third-level-shift modifier for half the userbase, and its important, which means taking it away is already a loss. Making the most of including it, instead of running out of places to put symbols, they can with the use of AltGr be on third position numbers, as per how the key called AltGr works.
AltGr+the rest of the keyboard, the alternate graphics, is an expected way to produce region-specific symbols for each region. In the opposite case, having no way to produce these, they have to be implemented where they compete with the regular set of alternate graphics symbols, that is a lesser option. Given the scale of differences, its actually no options, because you cant even fit one of them properly.
And most importantly, nobody expects to see symbols on letters. The clutter this introduces is a big deal to some people, and very much so for the perception of novices thinking that this is a regular keyboard. A very important idea to hold onto as it colours the perception of the whole device.

Putting symbols on letters also means you cant use AZERTY by cutting and moving the keys easily, because then you get symbols moving along with it. The reason for putting the symbol on the key wasn't necessarily the letter, its from what I've seen often about the position.
If the layout is reduced to A-Z, that means even less ways to behave like expected, and that really hurts, obviously since efficiency and habit for everyone is thrown away.
I think a lot of sales are thrown away too, its not like interlingual and international users can be relegated to hacks, they actually aren't faced with this burden at all, they are scared away by it, and are then less likely to pick up a device, which is when you have to deal with it.

Even so, some will undoubtedly do it, and if you hack, you lose assumptions made in software. Its much easier to have everything stay simple if as little change is planned as possible to accommodate as many as possible from the design-stage.
Having no fuller layout also hurts the default, because then it becomes a pressing issue that these symbols have to go into the one-key mix. Its only OK to have things not printed if those things are where they should be. For full interlingual coverage with language-layer, where you would have to learn placement, it is much sleeker to do this with an interlingual key. The neo layout already has this behaviour. We can do it with select, because if its not encumbered, its not a problem, The issue with French is they type their keys on the number row, which is solved on a best-effort basis with that key. Importantly now they can type big vÉrsals too (without compose).
While a smaller loss, even English users expect to find their things in this area. [ {  and ] }. The number one gripe people have with ANSI keyboards (104) is the lack of <> key. Having all together, means easy shift+combo access to all brackets, and ( ) close by, also at shift.
For others, If there is no dedicated way to type dedicated letters, the need to print them on the visual layout for everyone increases. Even though its only a few languages, its still a detriment to English users, since they are largely monolingual.
A truly multilingual feature is the compose button, chording it isn't as good, and its a good addition to dedicated special language-modifiers in the fuller layout area.
Yes, sometimes they are even on the two keys to the left of space, but we don't have those keys, so adjustments will have to be made. Same with ß, but that doesn't mean öäü has to go.
Putting each languages special language-modifiers in places they definitely don't belong, with strange looking symbols, is not good for anyone. It is the downfall of the commons.

For the people that use them, its not what they are used to, and for those that don't, they look foreign. The latter is a big issue.
The full set of US diacritic-symbols can be included, but as a neccecity born out of limitation, not in the standard places, this is the only conclusion to be drawn. Doing more things in new ways, is more of something that isn't good.
Same as with the typewriter support, just because there isn't room for many non-western-european layouts, doesn't mean the western-european layouts that do fit shouldn't reap the rewards. Fortunately this is also where the demographic that for the most part buys pandoras come from. (!) And where the pyra can attain a larger marketbase because of the greater support.
For keyboards that don't have F-keys, a key called "Fn" is the most common, as seen on 60% layouts. Its possible to say it doesn't apply because this is a game-keyboard, but then the question becomes, when was that ever better? Isn't it something to avoid?

People may not want F-keys, for these people it is a small price to pay for the ones that do need them, for them not to be printed. More modularity and more choice.
Printing them can't be ideal, either they are slanted with regards to the number-row if on QWERTY, or F11 and F12 stands out looking like a disaster when they are on numbers.
With a dedicated Fn-button 4 mediakeys on the shoulders can be triggered at all times, that doesn't work at all, or only with 3 shoulders if you have meta to do both in both places.
Making something pyra-specific means chances are taken getting it to work for the first time. Keyboards are famously a conservative geschafft. Improving on the typewriter has been attempted, and it fails mass market every time. Doing something less, has no chance at it. You can sell it via other means, but not being a true keyboard drags you down.
A bar key space that isn't centralized, nor stabilized, is a misnomer. The people who have designed keyboards overwhelmingly see this issue, since they have acquired insight. Its not the wobbly nature, nor the non-symmetrical side of it, its that it doesn't do anything. The important part of it is the left side, the other side is not needed. You press space on the side that matters. The middle isn't a quality feel, because its not the middle of a button, its in between two that actuate independently of each-other. Take the pandora. The tab could have been dedicated, yet the two buttons register as one, so you have wasted your shift+ combo.

If the keys are too small for accuracy, then that is a problem with the size of the singlewide buttons. While this may or may not be true for some users, i'd like to think it makes more sense to design for those that are comfortable using it.

My dad has fingers too big to use the TOHKBD, if that happens, it doesnt matter that ctrl (or space) is wider. We were aware of this in design-stage, and it is a ultimately a design-feature that isn't utilitarian.

This or this is the difference that single key makes. Variation over same theme on other layouts. For both of them it means:

  • Having to hurdle to get from dot to enter, before that was a straight connection.
  • Its farther to get to dot since its less central.
All users suffer, and there is no way to get around (heh) the issue.

  • All languages that require +4 non A-Z buttons aren't possible. (French, Italian etc)
For the former it means:

  • You need to shouldershift even if you want +3. (German)
For the latter it means: 

  • You dont have to move space at all, but familiarity of [ {   ] } is lost for english users.
Right there is enough of a reason why it isn't better for more people. Dualwide isn't a big deal to anyone. This is a big deal.

  • It is worse for efficiency (more distance travelled, see firstpost for ideal solution)
  • functionality is spread  (brackets are no longer spread out over an array of keys, but <> is condensed where it isn't supposed to be) (coding <xhtml /> is a nightmare on euro keyboards)
  • availability of shift, (less shift+combos)
  • It makes the keyboard appear non-standard. (Stepped {[ and ]} keys)
When presented with the question, people did not consider the ramifications it brings, and to no-ones surprise, gimping a key when there is a shortage to begin with, isn't pretty. You have to make amends which best case means less dedication, less efficiency, and more non-standard look. Then you are truly done considering it to be what it isn't, a 10-finger button. It can here only be reached with one thumb, by going to the left side of it, never can it be pressed with the left thumb, or anything else. It isn't faster, nor more precise. It has been done before, and is known to work. If you present a layout where the space isn't doublewide, nobody has an issue in my experience of showing it to a lot of people in various stages of technical aptitude. Try it, and see the bigger picture.

The purpose of the shift is primarily threefold. 1 type big letters 2. type symbols 3 type 4th level modifer along with AltGr

Notice the three fade in relevance 1 is more important than 2 is more important than 3.

Big letters are only typed after space and enter, so it should be close.

There is another way to get efficiency too, its to make both hands do more at once, it seems practical, but what its really doing, is tying both hands up at extreme left and right. It also slaloms motorical attention and visual focus. Instead putting all on the right, which is also good for efficiency since its the dominant hand, means you are free with the left to start a sentence. You are free to start a sentence with the right thumb too, if you shouldershift.

Advanced and newcomer alike, it works. Putting it here also provides an avenue of opportunity to get an extra letterkey on the keyboard for the languages that need 4 non A-Z keys instead of 3.

There is no meaningful effect of having the left side shift for typing symbols on the right. Since for that shouldershift is better. And if the shift on keyboard is dead, this argument is further weakened.

buttoncluster arrangement, mixing Sega, with Snes means at best being confusingly wrong half the time. Introducing a third, means its almost always wrong. From the repo we can see that emulators are more popular than native games using the pandora-style BXAY. That is just the nature of the beast, people want their nostalgic retro games, no matter what. Being right half the time is a good option, but if we look closer we see that its actively confusing the other half.
BXAY looks like a cheap knock-off thing to avoid getting sued.
Which brings us to the solution to many problems. Which button are you talking about? And where is it?  < ^ v > is a easy system both to grasp, and type.
Position translates a lot easier when you consider the cognitive nature of the mind. Attributing letters to what is essentially positions anyway, isn't fast, nor intuitive.

It is as arbitrary as Latin letters are. What there was of a unity once, which is how it came to be, is now a mess that cant be saved. Doing it one way with letters only benefit the big companies that only cater to themselves. To the pyra it is the opposite.

BXAY is effectivly dead, the only people who will support it, are the ones exposed to it, a subset of a subset. And even they disliked it when they were introduced to it. I am one of the people that never forgot about that.

<^v> also references its function, pageup, pagedn, home end. When you call it by those names, they are no longer irrelevant, they have meaning and purpose, as opposed to building a mental map of A being a button and where it is and when.

Mixing select with ctrl, means one of two things, neither of which is good.

It could mean that you cant use ctrl when you want to type select. Ctrl+p for example and other things are useful and expected to work even within things that use select. Or,

if its really just a ctrl branded with select, it means your application wont pick up on that its select by default, and you have to configure it. Not a big deal, but still.

Visually, putting "Select Ctrl" on one button, makes it the worst of the bunch for visual clarity. Going with only select makes it a lot better.

More importantly, Start and Select are not meant to be vertical, (and if vertical, with select on top (unlike the pandora)), they are meant to be horizontal, as SELECT START. Like it is on a snes-controller. Etymologically it may be start  and then select, but thats the wrong order to do things in, it feels right because start is closer to your right hand.

The 4key buttoncluster <v^> along with shoulders, are on dedicated gpio. It also has a functionally different purpose than the rest, they can be seen as two different things. When you have modal switching of them, it means you never have any issues, even if you want to use the keyboard along with it. From a developer point of view, it is a very pure approach. If gamepad keys do gamepad actions, a lot of things work out of the box without configuration.
Last edited by a moderator:
I can't believe the selfishness and 'everyone for themselves' mentality on the threads. I think alot of the people on there would have an english-only-and-to-hell-with-the-non-english-speakers keyboard if they could. Does no one care for other people's languages?

Tis arrogance, in my opinion
Unless you speak many languages, it should moreso boil down to people, on account of empathy. Other than that there is a direct benefit to monolingual english-speakers in selling more units.

The US layout, being the one to replicate if you dont want to consider compatibility, only does so for software, that is broken. Its not good for language.
Second languages fine, first languages other than english, not so much. Unless you switch layout. And for that, the amount of keys and placement matters.

Going with the english default, there is no loss to be had. Regular typing wins. For everyone.

Luckily now the secondary keypairs of US layout are irrelevant with WizardStans FnKeymmnemonics.
The argument of a employing a layout resembling something akin to a US layout, is not compatible with throwing symbols all over the letters.

Then there is the pandora layout, its not good, and its an even worse for the pyra if you want to get anything done.

Its just as futile to try and invent a keyboard as it is to implement a broken one.

ED has good insight of his audience, but he thinks too lightly of trying to balance a keyboard. Poor guy overworked enough as it is.
Last edited by a moderator:
So I tried coming up with a compromise to be able to type F-keys with shoulders.


Whether functionality implemented by  Isoshiftlevel3, groups, Fn, xmodmap or loadkeys, or other means, the shoulder isn't marked, so the actual keysym relevance to what is on the key isnt important. At the same time its a change only people using shoulders will notice.

This however means no alternate graphics on the QWERTY row, unless you use the AltGr on the keyboard that is, which is fair.

Accidental Alt+F4 is a problem though, maybe a little less than if it was on numbers.
Last edited by a moderator:
I was finally able to make something that works better as a default for more people, _without_ any change. In essentially the same 12-wide space.


Ortholinear layout. The drawback is it has less shift+ combos, since its not possible to lure that in without stepped keys, but if you use shoulders, all is fine again.

I like that all punctuation is back and forth on the same bottom 5 keys.

However for this to work, the case would have to flex to hold the PCB, and click together with the underside rather than rely on screws.
Last edited by a moderator:
I too think that a nonstaggered layout may work better for a mobile thumb keyboard. But as you say, non trivial reengineering of Pyra board and case would be necessary. ED has stated that he could be contracted to work on Pyra modifications. While dreaming of a keyboard modded Pyra, ultimately I'm too lazy to start such a project myself, but if someone wants to do it, I might be interested to invest some of my savings in it.
I was finally able to make something that works better as a default for more people, _without_ any change. In essentially the same 12-wide space.

However for this to work, the case would have to flex to hold the PCB, and click together with the underside rather than rely on screws.
Yes, that exactly is the issue.

You couldn't assemble the case, it would be too flimsy.

The top key would also get in conflict with the Wifi Antenna.
I like staggered keyboards and I don't like non-staggered ones. Non-staggered looks cheap to me, and it makes it much harder to find keys. Z directly below Q, while it should really be roughly below W, that just feels wrong.

I don't care much if the staggering is standard (0.25 key between QWER and ASDF, 0.5 key between ASDF and ZXCV) or like on the Pandora (0.5 key between all rows). I think I like the Pandora way of staggering slightly more, because it's more symmetrical.
I'm with _wb_ on this one... non-staggered keyboards just feel wrong to me, to the extent that I'll steer clear of such a keyboard unless there's no better option.

(Ed any everyone in my thread, I am honoured: )

Considering there is no gap in between the keys, the deviation to a regular board is not that bad with ortholinear, while being more symmetrical.

Thought it depends what you are measuring, Q-Z is actually aligns perfectly on a pandora (if you only consider the usable keycap space), from Q-A its slightly in favour of ortho.

It all depends how much you value familiarity with desktop keyboards against symmetry and the use of spacial real-estate. Would be interesting to know why the stepping is the way it is in the first place. Ortho and pandorastepping are both ideal in a sense.

Overall pandorastepping wins out on those criteria, and the arrangement of rows on pyra lend itself to advanced users, since you have to switch buttons to do international input, but it works out because you get combo-presses for clusters in return.

Notably only with singlewide space.

That being said, its all about what is possible to arrange, and then how it fits the users, if you deem advanced users to be able to use shoulders, you get both the efficiency for the advanced and the ease for the novices with ortho. Im just thinking that middle segment is really the great bulk here.

Edit:  Updated the argument for singlespace above, the links to the layout editor were incorrect.

Lets say efficiency isnt everything, then this or or this is the right kind of idea. Depending on your preference for brackets, (none of which are ideal because the whole thing belongs after P)

English takes a loss of efficiency, comparable to the rest, and brackets are moved, but it has one upside, if you switch back and forth to german, (and other +3 languages) there is no issue with moving shift/or incorrect symbols/incorrect arrangement of üöä on the keymat.

Again, if you wanted to make a strict +3 consider this or this (again with two styles of brackets, i prefer the latter)

It comes down to a question of economics, is it better for +3 to be able to switch back and forth at the cost of no +4 being possible?

French is the loser here, but that layout makes no sense, and the people who use it are, in my limited experience, quite ok with many things other than a straight copy.

Italian and spanish can be worked into +3 just fine.
Last edited by a moderator:
So with the "Fn labels to be decided" missing from my entries, along with the strict +3 layout. We learn that a lot of things fail if you dont expect them to be there. Which is a blessing, and tells us two things.

1 That they need some sort of labeling.

2. English default works, because that is what people assumed it was.

With none of the any other layouts coming anywhere close to a sensible english default, maybe its just me thats obsessed with efficiency and correctness.

We assume henceforth that English people are ok with moved brackets, because this is better than the alternative for this group. 


Unlabeled is also the language layer on select, and the language switching on Fn+L, which also failed to register even as a concept, so that needs some labeling too.


Its now impossible to do diactrics with Fn (since numbers are the F-row, and not optionally on QWERTY)

However the language layer can be dual duty, diactrics on the letters punctuation and < >, and predefined letters for the rest.

So who loses? Its the french. They were the only big +4 langauge, and it means they dont get their predefined letters on 2490. It can however be reinstated with shift+altGr, but its problematic for 0, since that is the position for ¿

So it all boils down to the French having to use shoulders, and the english getting less efficiency. Its not going to win any design-awards, but it will work.  Thoughts?
Last edited by a moderator:
And there still simply are not 4 Alt keys in the available mappings.

2nd AltGr simply does not exist.

AltGr can only exist IFF the right Alt key is switched/changed/sacrificed to AltGr.

The layouts you keep suggesting with "Two Alt AND two AltGr" keys, regardless of how many times you suggest them, are still and will remain impossible.
Its a question of employing the same meta (L and R) to do so.

What makes doing the same, only mixing F-keys into the mix possible? Since AltGr isnt a under the hood term in linux, but you can make anything function like it.

You can have as many AltGr keys as you like, ive set up 5. Same thing as if you plug different keyboards in. Key, scancode, keysym, event modfier, its all different all the way up.

Which doesnt answer the question of why you wouldnt use keycode in shoulder games or emulators, but ok, if you wanted a problem, it is now avoided.

Anyhow, this is the german layer. Which could be done as a special keymat.
Last edited by a moderator:
After some good feedback i made this happen:

Tried adding a lot of of Fn things:  http://www.keyboard-layout-editor.com/#/layouts/9d2475ebb7135844f0082d123cfbaa6d

If you count nub directions as keys, you have 29 less possibilities like this

in return for being able to type F-keys on shoulders.  Even more if you want to be able to use numbers in games. Which, if you are doing F-keys on numbers, is like begging to get an Alt+F4 or leaving the user in a different TTY with no explanation whatsoever.

I am thinking scroll in all 4 directions is nice on the right nub.  Middleclick is another contender for the right nub click, but some people just want super
Today i found someone unable to grasp typing in the international area when the letters werent right.

It was on this sort of thing, courtesy of Toshiba:


Why they are red and green is a mystery, that might be what does it.

The green up top is probably a way to accomodate all.

But the thing is, I know how to use an english keyboard, i know how to use a german one. I just cant see who wants both instead of eventhe "wrong" one.

Truth be told, if you want to bring it down to known to work, i think it follows this sort of pattern, from good to perfect.

Correct buttons, wrong marking

Correct buttons, german marking

Correct buttons, multilingual marking

Correct buttons, native marking

Misleading, and other conventions, just don't do it for me.
Last edited by a moderator:
You think that's confusing? Try this one :)

Pffft, that's easy. To get ">" you press the key in the top left corner, ">" in the bottom left, etc.I'm unfamiliar with the "IMPACT500" key though, what does it do?


/me glances at my Happy Hacking Pro (not posting links or images, just Google it)... so much fuss for this ****...

Anyway, I though these threads were headed back to General talk where things generally tend to get buried faster?-)