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

Functional layout vs reduced layout

  • Total voters

In a game that uses the shoulder buttons and START/SELECT, there is no way at all to input the symbols ' " / ? - _ = + \ | ` ~

Putting (nearly) all symbols and F-keys on one heavily overloaded number row doesn't feel very efficient for coding. There is an inbalance in the number of functions per key.
Who codes with F-keys? I agree it looks cluttered, but thats because the placement is straight out of a horror-movie.

I do like _wb_'s first P+1 L+2 variant above. Because (unlike some other versions) it uses the 'normal' color scheme it makes it very easy to compare such a layout to the more densely labeled ones. I think one could remove all the orange 'F's (and 'F1', but probably not F11 and F12) and the dead diacritic labels, too, without loosing anything. Some further rearrangements (like moving - and = to replace the dedicated brightness controls) would give a layout that truly deserves to be called uncluttered. And still be usable for both code and text I think. As a German I'd be actually tempted to map öäü to meta-P+1/L+2 and ß to meta-backspace. For desktop gaming Grench's layout with lockable numeric keypad and F keys is obviously better suited, but that could be an unlabeled (typically there isn't much time to look at the keyboard labels while gaming) alternate layout to be switched to on demand.
Minimalist 'designer' keyboard:
I wonder if -= at the very top would be practical, though. Shouldn't be worse than the number row on the Pandora, so in principle it could work.
Still not a fan of those. It simply feels wrong.
Me neither: non-mashable Shift+Meta, Tab in a weird place, number row not aligned with QWERTY row. Personally I don't need the P+1, L+2, and I think they are only really useful for Scandinavians and Germans.
Moreover, minimalism is overrated; if we're going to pay for the printing of labels, then they better print some damn symbols on that keymat! ;)
Lets consider the non "feel" part of that argument. If something is really useful, or useful for scandinavians and Germans, by removing it, you are really disadvantaging them, or disadvantaging them. It is the former, but my question is why minimalize this group? Where else are you going to find those 100 million prospective users?

Specifically, _what do you gain_ by throwing them under the bus?

Dont blame minimalism. If you bring it down and the concepts are still complex, it means they were in the wrong place in the first place.
You cant clean anything if the institution it is in is what created the mess.

Hiding things by introducing visual chaos just means bringing the dissonance to an equal amount accross the board.

No shift+combos
No AltGr+combos (only / with meta+ lower right)
Its not possible to type a bracket without the use of two hands.
Paying more for additional colours and getting visual chaos in return is not a good tradeoff. It gets worse by the letter. 

I wonder why we are insisting on Alt being on a shoulder when AltGr will do:
Is your "AltGr" supposed to be a full-sized keyboard AltGr? Or are you using AltGr in the same way that comradekingu is?
If the former, then AltGr *is* alt. They are identical keys on a full sized keyboard. You have a left alt and a right alt but on international keyboards the right alt becomes AltGr, but it's still right alt. Putting two such AltGrs on your keyboard is problematic because there is only one "right alt" scancode to map it to.
If the latter... whyyyyyy?
International AltGr is just as AltGr as anything else. The reason for doing it is you can use 3 visual symbols on the numbers like European keyboards do. As for other options, you are left then with what no other keyboards do.

AltGr in two places is unproblematic for the user. As for the hack, yes, if linux had the option of having all three, there wouldnt need to be the under-the-hood hack to make it work.

You then have two scan-codes, if that should ever be needed.
For games to use anything other than the keycode, which is different anyhow, i dont know why that would be a thing, but its beside the point.

I'm trying to see how CK's layout looks in the "standard" colors.  (I think it would help CK to get a better score, at least from the keyboard designers who are trying to make their keyboards easy to grasp ;) .)  But I couldn't help myself to move some things around.
visible keyboard symbols:
Compared to CK's original, I moved F11, F12 up top instead of on Q and W (though I don't have a strong preference here).  I also shuffled some of the AltGr+Number symbols.  I wanted ' closer to S for possessiveness (Bob's apostrophe), moving `~ further in (to less prime territory).  I also put / on AltGr+8 (mnemonic divide is the "opposite" of asterisk, or multiply); + on AltGr+7 (making + next to & for "and").  
I also made it so there's only one AltGr (right Alt), compared to CK, to avoid WizardStan's confusion.
hidden symbols for a default AltGr:
I tried to put slanty-accents up in a nice direction from their vowel (e.g. ú is up and to the right of u).  The exceptions are the accents on E, which correspond instead to the ', ", and ` AltGr marks.  For people who would actually use those accented vowels, they should probably make the default template, but this is my suggestion.
I also moved CK's {[]} to {}[] so that {} would be next to each other, and [] would be closer to i, j, and k (for my own coding combos).  But here no big preference.  I also put ç on C instead of Shift+AltGr+0 or wherever CK had it.  IMO this makes most sense.
For most of these non-visible changes (besides ç) I don't have a huge preference, so I don't mind CK's original positions.
Any people have qualms with no AltGr on the main keyboard?  Does Ctrl+Alt suffice for AltGr?  Certain symbols aren't available without it:  | ' " ` ~ \ + / - = _ ?
These are the standard colours  
http://www.keyboard-layout-editor.com/#/layouts/35471c73f550767fb502165e06e7bc31 all black
http://www.keyboard-layout-editor.com/#/layouts/5a7310c2837b4d173f0e4eddffcaad47all white

 http://www.keyboard-layout-editor.com/#/layouts/56e24b8fd0a8ae77ec09da2a5fdd216bis the space, far out - edition

http://www.keyboard-layout-editor.com/#/layouts/d91c2d1042813a7aa7b505a1e6babc3eall black

http://www.keyboard-layout-editor.com/#/layouts/30661d4441a6b48f8131eb369e820a5aall white  (i dont know if shift+space works, and FN+space isnt obvious, so i changed it up)

 http://www.keyboard-layout-editor.com/#/layouts/290dc2cab3340a92d913d1bb21f62565 Current AltGr layer.
Last edited by a moderator:
I specifically like the "Who codes with F-keys?" remark.

@_wb_: Numbers are overloaded, yes. I was just offering a suggestion within the constraints (?) that comradekingu is using. I'm not very fond of these constraints (which is why it's not my main proposal). You do make an important point however, that you're not going to get certain symbols if you want to type when playing certain games with CK's layout. Though our layouts get around this (by having a keyboard Shift and meta), it's not always convenient to use keyboard modifiers for certain keys on the same side as the modifier. So it's possible, but not easy, to get certain modifiers in yours or mine (in games which make use of shoulders and start/select).

I was just trying to put CK's layout into colors which help guide the eye as to what symbol is achieved with what modifier. Then I changed some things. Any thoughts on the changes?
Hold on, explain.

How are you not getting all symbols with keyboard shift and keyboard AltGr?

The way i see it, you get even more symbols, because you get keyboard FN in to those on the keyboard. Which still works in games.

You modified wbs layout, not mine.

What did you intend to improve? My thoughts here.
Last edited by a moderator:
Your layout has two AltGr's, which doesn't seem possible (two right alts?) according to WizardStan. Would they both give the same keycode? Or how would that work?

I modified one of my old layouts, to make it look like yours, but with colors that help organize the information. (I know you don't like colors, but they help greatly when you label 3 things on a key.) If I change my Super button (in the center) to an AltGr, we get a keyboard AltGr like yours. But that is not an easy to hit button IIUC. And it may not be very ideal to have two AltGr's if they both give the same keycode.

Putting a (software) Fn button on the shoulder makes it possible to get all F-keys without any strange movements (unlike your layout, where it is not easy to hit e.g. F7 [edit] or is it F1 now? You moved your Fn).
Last edited by a moderator:
Thanks for exploring this aspect. AFAICT there are few systems having both gaming controls and a keyboard. So applications that use both the shoulder buttons and main keyboard input are either made specifically for the Pandora/Pyra or have already been remapped during porting. I can't think of a reason why these should be a concern when designing the dedault layout.
The problem occurs when you want to say that your game uses right shoulder, but that the other keyboard equivalent shouldnt be a gamebutton. If they are just duplicated, there is no way to distinguish between the two.

With the help of B-zar. The problem happens because linux doesnt have AltGr, it only has R_alt, which can do language modification, or thirdlevelshift.

The scancode is different anyway, to allow the nr2 to be different, the one AltGr that isnt R_alt  can be made into something else.

Both of which can trigger thirdlevelshift.

#define BTN_SELECT 0x13a

#define BTN_START 0x13b

These two are buttons already, this one is unused:

#define BTN_MODE 0x13c

If you use that, you avoid all problems. The only problem is if you have a pre-made program that for some reason has BTN_MODE written in to do something.

You have to do this for one of the two Alts aswell.

If AltGr is coloured, then why not shift? Both of which aren't coloured on a normal keyboard. Adding colour makes it look unprofessional, to some that is
an issue, but the inverse isn't true, i don't think people have problems with non-toy? Or?

Edit: Right now it doesnt look like shoulders will be labeled. I think its wise to propose the extra functionality on shoulders is something you turn on, and that it is by default off. Same with Home/end/pageup/pagedn. Atleast have a way to turn functionality for those two off or on.
Last edited by a moderator:
Edit: Right now it doesnt look like shoulders will be labeled. I think its wise to propose the extra functionality on shoulders is something you turn on, and that it is by default off. Same with Home/end/pageup/pagedn. Atleast have a way to turn functionality for those two off or on.
Why do you think shoulders will not be labeled?

When you say Home/End/PgUp/PgDn should be by default off, what exactly does that mean? What keycodes should those action buttons produce when Home/End/PgUp/PgDn functionality is "off"? How would you code or configure games to use them? What happens to your games if you suddenly turn Home/End/PgUp/PgDn functionality "on"? Do you have Home/End/PgUp/PgDn mapped elsewhere in case you need it when it is "turned off" on the action buttons?
They arent labled on the prototypes, so maybe they wont be on the final unit.

I was thinking that not specifically labled keys is a problem overall, that can be avoided.

People seem to have forgotten how little sense BXAY made when they first picked up a pandora or Gp2x, so worst comes to worst you have something that is unlabeled.
They arent labled on the prototypes, so maybe they wont be on the final unit.

I was thinking that not specifically labled keys is a problem overall, that can be avoided.

People seem to have forgotten how little sense BXAY made when they first picked up a pandora or Gp2x, so worst comes to worst you have something that is unlabeled.
How could they be labeled on the prototype if there's no agreed layout yet?

I think it would be best to label all keys/buttons with what they do. That's the point of a labeling. To make sure that you can figure out what a key/button actually does, without having to read manuals, do a series of experiments, or memorize things. It's a device that aims to be useful and usable. It's not a puzzle game where most of the fun is figuring out all the hidden easter eggs. At least that's my opinion.
Im not disagreeing with you, im saying there could be potential trouble labeling the shoulderbuttons. Or it could be not part of the plan. Citation needed as they would say on wikipedia.

I have used the "blind" method to great extent to figure out if things work or not.

The combined Ctrl/select is one of those "if you cant explain it simply, you dont understand it well enough" So i opted for an easier solution that has no complexity.
Last edited by a moderator:
I am pleased with the result and the response, so  easykeyboard.png is going into the final layout thread.
Your German layout has no ß.

Your French layout has no é and ç. Also it has no keyboard Shift.

Your Belgian layout has no áéíóúàèç. Also it has no keyboard Shift. I wonder why it has two tildes and asterisks.

In your Italian layout, do you have no capital versions of those letters? Also it has no keyboard Shift.

Your Spanish layout is OK, except that it has no keyboard Shift.

In all of these layouts, the symbols [ ] { } < > are missing. Also you are (effectively) using a single-width space, which gives you one more key to play with than what is actually available.

So far, I'm still convinced that your approach only works well for Scandinavian languages.
I dont understand the point of being convinced.

A doublewide space could be used too, it just doesnt make sense.

The italian, Belgian and French layout is difficult to understand.

Curiously on the Italian one, the only way i could get èé (which is done with regularpress and shift to the right of P

to be ÈÉ was to do the same with caps lock enabled.

The italians have altgr {  and shift altgr {   on the same button.  If that works for them, maybe it can be used to reinstate the letters on there, without moving them to a hidden area, and without using Fn. Then you wouldnt have to move F11 and F12 either.

Advanced symbols align better with advanced use, shift and AltGr is on the same side shoulders, I think i would prefer that over learning a new position. The reason why i was willing to is because re-learning new positions for letters is by far the worst. Having numbers on shiftrow seems like a minor inconvenience compared.

Little bit unsure how it works with dedicated dead-diactrics-keys.

With the Norwegian ^ i get  ä if i press it with something else    ã  if i shift+ the ^ and  ǎ if i shift+AltGr+ the ^


You would be limited to just the one if shift+ and AltGr+ needed to be available.


Truth be told i think maybe the German layout has enough buyers, with AltGr international placement of ß  AltGr+S. They use no diactrics, so they are fine there. There is very little use of diactrics in scandinavia (dont know about finland), but we are on QWERTY, not AZERTY, so i imagine the default is maybe better, unsure.

Would be interesting to know if only a little bit of the keymat can be produced, and how easy it is to cut into it.

Additional idea, If shift+  and shift+altGr works to re-implement, there are enough spaces on the AltGr layer to enable at least all letters French uses by default.
Last edited by a moderator:
So far, I'm still convinced that your approach only works well for Scandinavian languages.
I dont understand the point of being convinced.
My point is as follows:

  • You want specially made keymats for specific languages/regions.
  • You fail to convince me that a specially made keymat for France, Belgium, etc is any better than what the multilingual proposals already have to offer.
  • So why bother with specially made keymats?
For Scandinavian languages and German (without the ß) it would be a bit more efficient and familiar, at the cost of being less multilingual.

I think it's better to go for one default, multilingual keymat and keep things simple, even if that means a slight loss of efficiency for those who can type faster with the dedicated P+1, L+2 keys.
Personally the idea of keymats isnt needed, im advanced enough to use any ANSI or ISO-type keyboard. For sufficiently advanced Germans, Swedes, Danes, Norwegians its the exact same.

While i speak Spanish, and imagine finnish works too, im not sure, and am not going to make any claims about Belgian and French and Italian. Only that its closer to what they are used to. I dont understand why you would want to get away from that. In my head its about making it as close as possible, for as many as possible. With as little drawback for each as possible. Basic optimization-math / game-theory.

And i dont mean that all these keymats have enough buyers to warrant them, just that this is a possible alteration you can adjust to. Its much harder to adjust to typing A on one letter to the left of A, after you learnt how to type the rest. Much easier transition. Software-wise its a minor change too.

There is a considerable benefit. 100 million+ users in western nations are now able to type as if on a typewriter/keyboard. Since we pick from the advanced people by default, that is great.

The keyboard-proposals with orange colours already differ enough from a regular keyboard to make that treshold the same without the benefit. Novice users, other than English, arent in with only one default anyhow. (Allthough i am of the opinion, if you have ever used a keyboard, you have some preference for fuller layout.)

Keymats can only bring the treshold of entry down. For the people already above it, its not crucial. But the alignment of the whole thing is, because that group, if there is one, isnt as big.

You are then making it a 'beside the point'-argument. Setting the scope for international users up, is worse, if it doesnt come with benefit for English users, then i dont understand the point.

Taking a English-only keymat and putting letters all over it, doesnt make it multilingual. It makes it interlingual, at the cost of annoying English users. Thus scaring away a portion of those.

Not making it by default, a hidden real option, leaves one with no option but to put it either as a hidden default option, which is good enough for interlingual use, which its used for already, or, since there is no real option, spread letters for different languages all over the keyboard. Only translation-handhelds used that, and they have gone away from it.

Some keyboards have dual-option, i have a russian-norwegian keyboard. Though these dual-things all have fuller layout, and you will find them in some regions, it never caters to languages the user doesnt speak. Nixing that by limiting it to few languages, then you dont have as wide support.

Consider this, not a single laptop or keyboard in the regions you acknowledge to work are sold without also having severe drawbacks in other areas. If you want to make it a laptop, make it a real keyboard.
Last edited by a moderator:
`123456^ 7890-=+

qQ wertyuiop[]}

asdfghjkl;: '\|

\zxcvbnm,.> /?

Is the shift+row of US-layout

`dead 1¹ 2² 3³ 4¤ 56dead 8dead 90-¥ =×

qä wå eé rë tþ yü uú ií oó pö [« ]»

aá sß dð ff gg hh jï kœ lø ; '\¬

\\ zæ xœ c© v® bb nñ mµ ,ç .dead. /¿

This is the AltGr options for  setxkbmap -layout us -variant altgr-intl

It doesnt have all the deads, it has some junk, a lot of letters arent even used, i think it features the most complete interlingual set of alternateGraphics.

What i think makes sense is to have 5thlevelshift as ctrl+alt as all the dead-keys

Do German, French, Spanish and Italian

And facilitate the need for extra things they use (like «») in that order.

We can then maintain the US default as much as possible without putting symbols on language-keys, and at the same time get the benefit of US-international language support.
Last edited by a moderator:

Has complete interlingual support for













Start and start+select is one way, problem is that was reset on gameboy.

That leaves AltGr+letters and Shift+AltGr+numbers fully free. http://www.keyboard-layout-editor.com/#/layouts/640ce5623efaed55d2ebb435930d1245

The rest can be extensive symbols, or another set of dead keys, or the most important interlinguals.
Last edited by a moderator:
Has compose and the language layer.
Its a bit strange, albeit convenient, to use a different shift with the language layer. I dont think the speech bubble is good, but a diactric mark on start can be.
I suppose unmarked language layer should be farthest away.
There are ways to compose runes with it too, which means iceland and old-english has a way to type.
Also i think there might be unforeseen problems with using ctrl+alt. Using select and start is a

Edit: just somewhere to store all the defunct information:

older layouts
Here is a post about F-keys losing mainstream appeal, (for anyone more advanced, they can remember where they are.) laptops and chromebooks) Which is also why the importance of F-keys is fading as mobile applications make their way to desktop and laptops/desktop keyboards start losing their F-keys or become mediakeys by default.




Link to layout editor
Natural language can be typed using only shift,(no need to use AltGr
Lefthand coding symbols to the left, mathematical symbols on the right. Most used accentuation in the middle. One accentuation symbol per number-row key.
Press F-ing+'something that is also purple' is used to get the combination. Press F-ing+5 to go to refresh a page (F5)

Regular combinations like

Alt+F4 to close a window is Alt+F-ing+4
On a standard gamepad [start] is the farthest away and [select] is closer for people that are right-handed. More importantly this also means Alt+F* (which is more common than ctrl+F*) is a hold-combo, because touching down once can produce Alt+F-ing.
Power buttons:
controls brightness on [screen], [keyboard] and [rgb led] on the back of the lid.

Logitech uses "mode F". Some use "F1-F12" Leopold uses Fn as description of the invoker-key. It is a meta-key. Fn usually means there are no powertoggles, so that is confusing and Fn is a key people dislike because its always a poor implementation of hardwareswitches, numpads, or its in the place ctrl should be in.
Ideas are many here, but button could toggle brightness of the screen from medium to high to low, then back to medium. High is default for when you are plugged in
Hold keyboard button and ☀, to illuminate keyboards, or again to turn of keyboard LEDs.
F-ing+brightness turns on/off the RGB-led on the back where it illuminates the lid/logo.
An alternative idea is to hold ☀ for 2 sec to bring up an onscreen powermenu with three sliders for screen brightness, Keyboard illumination, and multicolour LED
⌁ Brings up an onscreen powermenu for turning on/off [ 3G ], [ WiFi ] and [ Bluetooth ] [HDMI-out] and [usbhost].

This saves power, and is still considerably easier than having to mouse over to the tray to enable something. I would argue that HDMI and USBhost should be default on. With a setting in powermenu to have it default off. This covers most use-cases and is less confusion. It just works.

They dont cost a lot of battery, which we have a lot of. And they can be disabled for standby.
(It is possible that the scaling chip can be used for dynamic brightness-scaling.)
^ pageup v pagedown > insert < delete Home end on the rest
.Think of the white lines as paper, or a screen.
>< is delete. Easy to remember because they point in the direction they are located.
They can also be referenced as W M Σ (sigma) or E and X Easy to type in plain ASCII.
The house is home, and the ... is end.
Also, for android, The house is home, < is back and ... is menu.
These buttons also work as game buttons.
Escape is on the same row as printscreen.



My idea is to have something that Works like real keyboards do. With the most efficiency and support. Divided into functional areas.

Show the layouts to casual computer users. Report back with findings.
Last edited by a moderator: