Final keyboard layout proposals - Discussion thread


Thanks Askarus & ED for clarifying we will indeed be having a double sized space bar. Take it we should be looking at the keymat Photos here to see the base layout.

My general philosophy for a keyboard / button layout will be to attempt to find a combination of making the most frequently used keys / actions easy to execute (mouse buttons as buttons etc.) and having something that looks like a 'normal' qwerty keyboard. Should be a fun puzzle. :)

It would be useful to know if any plans have been made for the placement of a power button, or will that be on the keymat?
That looks just like the Pandora's keyboard more or less.  Same mistakes.  Same compromises.  We can do much better.  Hopefully it's not 'locked' to that case and keymat layout.  It's a sad thing if it is.  This is a great opportunity to make a big improvement.
 
Last edited by a moderator:
I agree.  I think we should vote on the placement of the spacebar.

Relying on shoulder buttons for modifiers isn't a solid solution.  Using the Pandora, try quickly pressing Ctrl+F6 in game with the shoulder buttons mapped and in use for the game.  Next vision doing the same action on any of the above layouts.  In all cases assume that the shoulder buttons are already in use by the game - which is what they're there for.
Doesn't your game allow you to change your keyboard controls?  Why do you need to press Ctrl+F6 in game?  Could you map it to F6?
 
I think we should vote on the placement of the spacebar.
On the Pandora I like on the right because it also doubles as the tab button in fn mode. I'm also right handed.. If it's dedicated without the tab button or other vital key, I could live with it in the center.
 
I agree.  I think we should vote on the placement of the spacebar.

Relying on shoulder buttons for modifiers isn't a solid solution.  Using the Pandora, try quickly pressing Ctrl+F6 in game with the shoulder buttons mapped and in use for the game.  Next vision doing the same action on any of the above layouts.  In all cases assume that the shoulder buttons are already in use by the game - which is what they're there for.
Doesn't your game allow you to change your keyboard controls?  Why do you need to press Ctrl+F6 in game?  Could you map it to F6?
Then what would I map the control that's on F6 to?  Seriously.  I have games where I've mapped all of the F1-F12 keys in unshifted, shift+Fkey, Alt+Fkey and Ctrl+Fkey to different actions - and others that use 1-0, alt+1-0, ctrl+1-0.  It's important to have -any- logical key combination at close reach.  No, they're not all games that have been ported.  I have high dreams and aspirations for this device though.

I think we should vote on the placement of the spacebar.
On the Pandora I like on the right because it also doubles as the tab button in fn mode. I'm also right handed.. If it's dedicated without the tab button or other vital key, I could live with it in the center.
Note - my suggested layout is 100% ambidextrous.  Cheers to the lefties.
 
Then what would I map the control that's on F6 to?  Seriously.  I have games where I've mapped all of the F1-F12 keys in unshifted, shift+Fkey, Alt+Fkey and Ctrl+Fkey to different actions - and others that use 1-0, alt+1-0, ctrl+1-0.  It's important to have -any- logical key combination at close reach.  No, they're not all games that have been ported.  I have high dreams and aspirations for this device though.
Couldn't the same be said about just about any primary key? I'm sure there are examples for each that rely on them being primary keys. The fact of the matter is we can't have them all as primary keys, as we're working with less keys as you surely are aware. Application keys can usually be rebound as needed. In the cases they can't you can use something like xmodmap to remap keys or even inputty (search developer's corner) for complex cases to fake the key presses.
I'm just saying you can't have it all. Your layout to me seems below average in cases some other layouts seek to optimize. It's a sort of jack-of-all-trades-master-of-none approach. I'd rather have the common use cases optimized and do case-by-case configuration in software for the corner cases.
 
Last edited by a moderator:
I do like Grench's ideas to make it easy to hit mouse buttons without clicking nubs.  I don't know about the Pandora nubs, but clicking an Xbox analog stick always felt tricky to me.  (Not that I've had much practice.)

There are certain situations where it would be nice to have Mouse3 (e.g. Blender), but I suppose even there you could (hopefully) map that to meta++ or something else handy.
 
I do like Grench's ideas to make it easy to hit mouse buttons without clicking nubs.  I don't know about the Pandora nubs, but clicking an Xbox analog stick always felt tricky to me.  (Not that I've had much practice.)

There are certain situations where it would be nice to have Mouse3 (e.g. Blender), but I suppose even there you could (hopefully) map that to meta++ or something else handy.
We can have that, I already explained this earlier but I'll repeat it here (that will be easier than trying to find the old discussion).

L1, L2, R1 and R2 can be both modifiers and mouse clicks (say L1=left, R1=right, L2=middle, R2=Mouse4).

How?

The software has to be smart enough and use some context to determine intention. Basically it has to postpone producing a keydown event until the context disambiguates the intention.

This would be the way it would work. I'll give the example for L1 being Shift and left mouse click.

Scenario 1: simple click

Press L1 down -> nothing happens.

Release L1 -> a "left click" event happens (actually two: one button press event immediately followed by one button release)

Scenario 2: simple modifier

Press L1 down -> nothing happens.

Press any other key, e.g. the letter "a" -> first a "Shift keydown" event happens, immediately followed by an "letter a keydown" event. L1 is now in "Shift" mode.

[perhaps press more keys, Shift is still held down]

Release L1 -> a "Shift keyrelease" event happens.

Scenario 3: dragging

Press L1 down -> nothing happens.

Mouse nub gets touched to move mouse cursor -> first a "left mouse button down" event happens, immediately followed by a "mouse moved" event. L1 is now in "Left Mouse Button" mode.

Release L1 -> a "left mouse button release" event happens

There are only two things that are not possible with these mechanics:

- Software that uses modifier taps as actions (e.g. Ubuntu does something when you tap Left Alt) would not see the modifier tap if done with the shoulder modifier; they would see a mouse click instead

- Modified clicks or drags (Shift-click, Ctrl-click etc) are perhaps only possible if you use the keyboard modifier, not with the shoulder button modifier

That is a relatively small price to pay. And even that small price can be mostly avoided if we are fine with having only two mouse buttons on the shoulder buttons (instead of the theoretically possible four). Because then we can keep L1, R1 as dedicated modifier keys (Shift and Ctrl), just like on the Pandora, and only do the overloading trick with L2, R2. Since L2 is Meta, which is a Pyra-specific modifier, there is no software that relies on Meta-tapping or Meta+click. R2 is Right Alt, so we still lose shoulder-only Alt-clicks and Alt-taps. Actually Alt-clicks/drags could still be done (tapping/holding L1 while R2 is held could do that).

To avoid accidental clicks I would make it so that

- when the lid is closed (that is Right Super is held down), the shoulder buttons are not clicks (they could be media buttons if you like)

- if the time between pressing down and release (without any intermediate input events) is above some threshold, it does not produce a click. In those cases, it is more likely that you actually intended to use the shoulder button as a modifier key, but you changed your mind.

So I propose:

L2 = RMeta and LeftMouseClick

R2 = RAlt and RightMouseClick

The nub clicks are Mouse3 and Mouse4, and can be mapped to left/right/middle/whatever mouse buttons.
 
Last edited by a moderator:
That is actually a pretty neat solution, _wb_. However, it doesn't fit into the unix philosophy (do one thing and do it well) and we can't use it because of that.  :rolleyes:

jk
 
It eliminates the good ones as far as im concerned.

Edit: im unsure who i answered, but i agree having a doublespace means less choice. Especially since you then make a case thats missing a set of dividers.

With a case that has all dividers, It would be possible to file away the seperator between two buttons and doing a doublewide keymat. But once the case is doublewide, its much harder to do a single-width solution. Or move the space at all.
 
Last edited by a moderator:
That is actually a pretty neat solution, _wb_. However, it doesn't fit into the unix philosophy (do one thing and do it well) and we can't use it because of that.  :rolleyes:

jk
Not an argument.

I would not want _wb_'s idea as default for inexperienced users but it's really good :) .

Only downside is I don't like an action to happen when the button is released but when it's pressed but that's how this one works and gives it more uses.
 
Joining this discussion only now - sorry, if I should have brought this to the discussion earlier... ;-)

Given the keymapping problems with DOSBox on Pandora, I would really like to have a keyboard which has only commonly used combinations of (special) characters on each key, so that normal keyboard drivers (i.e. also DOSBox mapper) won't have problems with it.

For example, on Pandora it was not possible to map the ":" correctly, because (as far as I understood the problem) there is no common keyboard layout that has the ":" on the ">" key, as the Pandora has. So, each keyboard drive can either map the ">" OR the ":" correctly, but not both. The DOSBox mapper could only re-map entire keys with all their meanings, and not the different characters on one key separately. 

So, at least for the more common characters and special characters, it would be good to have only common combinations on keys, preferably similar to the US keyboard layout probably, to keep it international. 

As "more common characters" I would count:

- alphanumeric characters of course

- standard punctuation (":" is immensely important in DOS!)

- hyphen and underline

- mathematical operators

- all kinds(!) of parentheses, also <> {} [] for programming

- Backslash (in DOS and for escape sequences, and of course in general programming)

- characters commonly used to prefix variables and pointers, comments etc in programming, such as $, %, §, &, *, #

- Tilde (not for DOS, but for Linux)

- pipe

hmm... well, there is not much which I would consider less common I fear ;-)

Maybe all the accents. But then I'm German and don't need accents too much. Maybe people from France, Greece, Czech republic and other countries will need them also in common places for the above reason.

So... I didn't check this, but isn't it possible to just use the US keyboard layout, place its keys on the Pyra keyboard as close to their original position on a US keyboard, and, where necessary, just move the keys a bit away from their original position?

I see the number of the keys may not match, so some changes may need to be made. But I strongly vote for making those changes only on keys that are... well... less common ;-)
 
Joining this discussion only now - sorry, if I should have brought this to the discussion earlier... ;-)

Given the keymapping problems with DOSBox on Pandora, I would really like to have a keyboard which has only commonly used combinations of (special) characters on each key, so that normal keyboard drivers (i.e. also DOSBox mapper) won't have problems with it.

For example, on Pandora it was not possible to map the ":" correctly, because (as far as I understood the problem) there is no common keyboard layout that has the ":" on the ">" key, as the Pandora has. So, each keyboard drive can either map the ">" OR the ":" correctly, but not both. The DOSBox mapper could only re-map entire keys with all their meanings, and not the different characters on one key separately. 
If I read this correctly, there was a workaround on the Pandora: left shoulder Shift(Right Shift) + Fn + ; to get : symbol. This may not be the problem it was on the Pyra if we have two keyboard Shifts.

For : in the mapper, you'd single press Fn, then hold the keyboard(or L1 shoulder) right Shift, then hit the ; key.  

Maybe the order won't matter if Fn isn't the hardware modifier it was. It seems to make a difference before
 
Last edited by a moderator:
Ah Saber, now that you mention that workaround, I remember it. But see, I forgot it before. And that will happen to most users, who use DOSBox rather occasionally on the Pandora or Pyra. It's not exactly obvious. ;-)

DOSBox may not be the only software that has problems with non-standard keyboard layouts. In general, I would prefer to rather comply to standards, where it is possible, to avoid such problems and workarounds. 

Probably it wouldn't even be a big deal to someone who has deep enough knowledge of the DOSBox code and of keyboard mapping, to modify the source of DOSBox in a way that DOSBox exactly fits the Pandora keyboard. But who could be that person?... Also, as I said above, DOSBox may not be the only software having problems.
 
Last edited by a moderator:
That is actually a pretty neat solution, _wb_. However, it doesn't fit into the unix philosophy (do one thing and do it well) and we can't use it because of that.  :rolleyes:

jk
By that reasoning, we can't have Meta-keys either, and perhaps the whole concept of a handheld that can be used for both gaming and general-purpose computing also kind of contradicts the unix philosophy ;)
 
That is actually a pretty neat solution, _wb_. However, it doesn't fit into the unix philosophy (do one thing and do it well) and we can't use it because of that.  :rolleyes:

jk
 By that reasoning, we can't have Meta-keys either, and perhaps the whole concept of a handheld that can be used for both gaming and general-purpose computing also kind of contradicts the unix philosophy ;)
What are you two doing, both writing and thinking. Do one thing and do it well!
 
Here's my attempt at a keyboard. I based the top portion of it on Grench's but the alphanumeric portion below is different. And don't worry, I've placed it in the layout thread for reference as well.

21918.png


There are several things I tried to do:

  1. Not have any key have more than 3 different characters
  2. Spacebar centered but not dividing up the bottom row letters
  3. Use of a Pyra/Super key (the star in the mockup) as a modifier instead of Control which could cause problems with some programs
  4. Make all symbols and numbers generated by a pressing only one modifier key (Fn or Pyra) and a letter/symbol. This should make things nicer for thumb typing.
  5. Retain right-side modifier keys as much as possible
  6. Retain general similarity to English layout as much as possible for most common punctuation
 
Last edited by a moderator:
I think you should run the supers as space and the bar as super. Getting from space to , is quite far now. Also as TrashyMG mentioned, there is no F11 or F12
 
Last edited by a moderator:
I think you should run the supers as space and the bar as super. Getting from space to , is quite far now. Also as TrashyMG mentioned, there is no F11 or F12
Here it is with F11 and F12:

21919.PNG


I'm not quite understanding your suggestion, comradekingu. Could you please re-explain for me?
 
Interesting! I find it a little less crazy than Grench's layout, due to standard keys being about where you expect them. (For instance, I like the number keys/shifted number key symbols being in the top row.)

One challenge. IIRC, ED says he doesn't want more than one modifier (i.e. Fn and Purple-Star in your layout). I guess you say Purple-Star is the Super (Window) button, though. So how would you do something like Super+1 in your layout? (Fn+Super+Q?) I use the Awesome Window Manager, which uses such combinations to navigate to different desktops, among other things. Of course, the "Window" key can be modified in AWM, so it's not that big of a deal I suppose.
 
I think you should run the supers as space and the bar as super. Getting from space to , is quite far now. Also as TrashyMG mentioned, there is no F11 or F12
You're apparently thinking in one finger hunt&peck.  Right thumb , left thumb space.  No huge distance traveled.
 
Back
Top