It's the keyboard layout.


They all come from the right side of the US standard keyboard. If you use one, that will be where you instinctively look there to find them.
My thumb typing on tablets doesn't have any "muscle memory" from a full sized keyboard, just because a full sized keyboard does it that way is no justification for doing it on a smaller keyboard, potentially quite the reverse!
I agree with codifies when it's about "muscle memory": ten-finger muscle memory simply does not translate to two-thumb muscles. If it would, then you could only type spaces :)

I agree with Grench when it's about "knowing where to look".

Whatever we do, muscle memory is not going to be very useful for our purposes, but "mind memory" (which is just regular memory I guess ;) ) can still be exploited. That's also the reason why nearly all of us want to have QWERTY and standard shift+number symbols.
 
They all come from the right side of the US standard keyboard. If you use one, that will be where you instinctively look there to find them.
My thumb typing on tablets doesn't have any "muscle memory" from a full sized keyboard, just because a full sized keyboard does it that way is no justification for doing it on a smaller keyboard, potentially quite the reverse!
Not everyone is a touch typist.   For those of us who learned to type primarily through the hunt and peck method,  the "muscle memory" involved can simply be a matter of knowing approximately where to look, especially for the symbols one doesn't use frequently.

- Neelix

Edit: :ph34r: by _wb_
 
Last edited by a moderator:
Agree with Eight Bit and Comradekingu here about too many languages incorporated being too many languages in general. If French and Dutch are the gold standard to go by then Acute, Grave, Circumflex are the epitome of a functional dead key diacritic base. Many "foreign" Pyra users will need these three. Umlauts for all too obvious reasons as well. Rounding it out are letters for Å, Æ, Ç, Ñ, and a few others.

Sometimes the painting is more beautiful when you don't dip your brush into every color.  :)
Dutch and French need ë and ï probably more frequently than ü ä ö, so a dead umlaut is more useful to them than dedicated üäö keys.

Tilde as a diacritic is useful for ã and õ in Portuguese (and ñ if it is not already available).

Å and Æ are not that useful, they're only really used in Scandinavian languages.

With just acute, grave, umlaut, circumflex, tilde, caron/breve, cedilla/ogonek/comma, ring/dot and stroke (9 diacritic keys) you can in principle cover everything (except Æ Œ), but of course it's more convenient to have some of them as precomposed letters.

BQa1i3C.png
True, but the Dutch and French people could write ë and ï to one of the three umlauts, or ß, €, § in my layout. There's Shift + Fn + r, t, y, d, f, g, available also if those first six places aren't enough(highly unlikely for the average user). Å, Æ, Ç, Ñ, Ż and others each or all can be mapped there too. Being truthful here, most people will maintain only one nationality for the life of the device.  ;)

As I've expressed, loading up the layout with increased content isn't the only answer. I feel it's also a burden in some of these layouts to lose a dedicated Tab key, and to require Shift + Fn for ~ { } | : " and ? for all these extra diacritics most people will never on a per individual basis ever need. I realize it's a layout's selling point to fill it to the brim, but admittedly the user will fashion their layout according to their own specifications. In some cases it may be as simple as an å and Å at Fn + L and Shift + Fn + L. 
 
Last edited by a moderator:
Can I live with that? Yes. Would I rather have the tweaks noted above added? Sure, but I'm not going to harp on them at risk of having one of the other layouts highlighted.
At this point you and I are 'splitting hairs' over minor differences in layout and efficiency tweaks. I'm good with backing this one if you're willing to make it your 'primary' and push for it as well. If we can get a few more of the other keyboard builders on-board, I think this has a solid message to push up to EvilDragon.

There are a few typographic/formatting tweaks that should probably be fixed before presentation.

The '" key (left side) has two diacritic marks, should be reduced to 1 to match the format of the ones on the right side - it looks cleaner that way.

On the O key, the - of the Fn layer's -_ has fallen off the key.

Also, we should note somewhere that ALL non-modifier keys are expected to produce unique sanscodes for normal, shifted, Fn and Fn+shift values, regardless of whether there is or is not something printed on the key for those levels. Nobody panic - this isn't a hijack, it's to make sure that the keyboard produces a code for the end user to grab to map to whatever they want.

So, if we were to go with the _wb_ layout as listed above, who's in with us?
 
  • Like
Reactions: szr
So, if we were to go with the _wb_ layout as listed above, who's in with us?
As I've said before, I like it for the most part,  but there may be technical issues.  I'm not going to let myself get too attached to any layout unless I know the hardware will support it.

- Neelix
 
So, if we were to go with the _wb_ layout as listed above, who's in with us?
As I've said before, I like it for the most part,  but there may be technical issues.  I'm not going to let myself get too attached to any layout unless I know the hardware will support it.

- Neelix
As far as I understand, diodes can be put at the keys that will be used as modifiers, to avoid the potential masking/ghosting issues you were referring to. If that's the case, then we can basically freely design a layout without having to worry about those technical issues.
 
ere - if this is an open platform where's the proposed keyboard circuit (the layout of the switch matrix would a great help alone)....
 
As far as I understand, diodes can be put at the keys that will be used as modifiers, to avoid the potential masking/ghosting issues you were referring to. If that's the case, then we can basically freely design a layout without having to worry about those technical issues.
I'd be interested to find out if that's true, but until and unless I hear confirmation on that from ED or Nikolaus, my position stands.

- Neelix
 
@Neelix, I was actually given an early schematic of the keyboard wiring as I'm actually planning a big project of making a working mock-up of the Pyra keyboard for my Devboard using Cherry MX key switches. I was warned that the design isn't final, but I could use it as a guide on how to start. EvilDragon didn't want me publicly sharing the design as it's not final. I can assume that the final keyboard design will finalize how it's truly wired. In my project I'm attempting to make it easy to re-wire to try different layouts until a final design is chosen.  

Currently from what I saw of the design there are schottky diodes on the modifiers keys. Also to note the four shoulder buttons are using GPIOs directly connected to the SoC, and not the I2C chip that the keyboard matrix is tied to, so I assume that reduces some of the issues for those buttons when hitting multiple keys. 
 
 
Last edited by a moderator:
@Neelix, I was actually given an early schematic of the keyboard wiring as I'm actually planning a big project of making a working mock-up of the Pyra keyboard for my Devboard using Cherry MX key switches. I was warned that the design isn't final, but I could use it as a guide on how to start. EvilDragon didn't want me publicly sharing the design as it's not final. I can assume that the final keyboard design will finalize how it's truly wired. In my project I'm attempting to make it easy to re-wire to try different layouts until a final design is chosen.  

Currently from what I saw of the design there are schottky diodes on the modifiers keys. Also to note the four shoulder buttons are using GPIOs directly connected to the SoC, and not the I2C chip that the keyboard matrix is tied to, so I assume that reduces some of the issues for those buttons when hitting multiple keys.
I realize that you're not able to give out full information, but can you define which keys on the board design have the diodes? I.e. which keys are "modifier keys"?

That would go a long way towards understanding the constraints that would define this entire exercise.
 
Last edited by a moderator:
Good to know there is some flexibility there.  Though to be honest I don't understand how the diodes would help with the masking problem.

FWIW I'm happy with that mapping as a default if it is technically feasible.    (This one, to be clear)   I would probably add œ to it somewhere, but there is room to do that, so that's not a problem.

- Neelix
 
I'll leave this minimalistic US lay-out here to see what people think about it.

Plenty of room for private binds / mappings I'd say. :)

http://www.keyboard-layout-editor.com/#/layouts/41f99bfc92a39d632638cfd53d8ca3d3
Maybe move Backslash and Pipe to J which allows you to slide the other pairs in that row one key to the right. Not a fan though of where comma and period are hidden or Tab but it is manageable. Two keyboard Meta's is a nice touch.  :)

Good to know there is some flexibility there.  Though to be honest I don't understand how the diodes would help with the masking problem.

FWIW I'm happy with that mapping as a default if it is technically feasible.    (This one, to be clear)   I would probably add œ to it somewhere, but there is room to do that, so that's not a problem.

- Neelix
Even though the symbols are compressed over to the right edge like they usually are on a full size keyboard, I don't understand how requiring the user to press two keys(Shift and Fn) together for ~ { } | _ + : " ? is not intolerable to some of you. That's abhorrent as how I've seen it done so far in some of these layouts.

So, if ED jumps all over this to bring happiness to this here kingdom, I alternatively propose we have a custom keyboard-only key that merges a Shift and Fn into one unique key. We then cluster the three modifiers all on the left side's corner. One Shift, one Meta(or Fn as we might call it), and one "S.Meta", which is a composite of Left Shift and Right Meta. Once more, this is just in case if ED wants the main punctuation all heaped to the right. :)     
 
Last edited by a moderator:
Even though the symbols are compressed over to the right edge like they usually are on a full size keyboard, I don't understand how requiring the user to press two keys(Shift and Fn) together for ~ { } | _ + : " ? is not intolerable to some of you. That's abhorrent as how I've seen it done so far in some of these layouts.
I don't understand why it would be.  With Meta and Shift on adjacent keys it's just as easy to press both at once with a single finger as it is to press just one. 

If you don't believe me,  try it in the Pandora Input Tester. (the keys on the Pyra are the same size horizontally)

- Neelix
 
They all come from the right side of the US standard keyboard. If you use one, that will be where you instinctively look there to find them.
My thumb typing on tablets doesn't have any "muscle memory" from a full sized keyboard, just because a full sized keyboard does it that way is no justification for doing it on a smaller keyboard, potentially quite the reverse!
I think this is an interesting point.

The letters are definitely muscle memory. There is no exception to dedicated letters in any language. Try switching I and G on a pandora. Or replace I with AltGr+8 and G with AltGr+7 Even if you think you are a visual QWERTY user, it is initially very detrimental to change to for example COLEMAK.

And as a general rule, I think with the least of visual clutter presented, you maximize the goodwill for any changes. It shouldnt be easy to point to troublesome areas, or things that are clearly compromised. That is the first thing people see, and it throws me off in a major way.

Where things differ, is with efficiency. Relating to the punctuation and heatmap, some changes can be made here. A 2 thumb layout becomes more efficient if , and . is at either side of space. From thereon logistics can be optimized quite a bit without appearing otherworldly.

With that covered, you wont really get a whole lot of efficiency out of symbols either way. On the whole, its more important that the international users can have letters that arent effectively symbols.

However i also think there is such a thing as mental mapping. I expect a certain amount of conventions. And i expect things in places i know them to be, as do we all. With that in mind, if we try to keep things within reason, its also the most familiar to everyone.
 
Last edited by a moderator:
Even though the symbols are compressed over to the right edge like they usually are on a full size keyboard, I don't understand how requiring the user to press two keys(Shift and Fn) together for ~ { } | _ + : " ? is not intolerable to some of you. That's abhorrent as how I've seen it done so far in some of these layouts.
I don't understand why it would be.  With Meta and Shift on adjacent keys it's just as easy to press both at once with a single finger as it is to press just one. 

If you don't believe me,  try it in the Pandora Input Tester. (the keys on the Pyra are the same size horizontally)

- Neelix
I know and I'm not saying you can't press two keys at once for say a Tab key, on the Pandora, but I am saying it will grow old really fast for that many symbols(nine by my count) for other people.   
 
Last edited by a moderator:
@Neelix, I was actually given an early schematic of the keyboard wiring as I'm actually planning a big project of making a working mock-up of the Pyra keyboard for my Devboard using Cherry MX key switches. I was warned that the design isn't final, but I could use it as a guide on how to start. EvilDragon didn't want me publicly sharing the design as it's not final. I can assume that the final keyboard design will finalize how it's truly wired. In my project I'm attempting to make it easy to re-wire to try different layouts until a final design is chosen.  


Currently from what I saw of the design there are schottky diodes on the modifiers keys. Also to note the four shoulder buttons are using GPIOs directly connected to the SoC, and not the I2C chip that the keyboard matrix is tied to, so I assume that reduces some of the issues for those buttons when hitting multiple keys.
I realize that you're not able to give out full information, but can you define which keys on the board design have the diodes? I.e. which keys are "modifier keys"?


That would go a long way towards understanding the constraints that would define this entire exercise.
Well it could all be totally irrelevant when the official keyboard layout is chosen... But what I see in the schematic... 


ALTGR, MENU/ESC(assume like Pandora button), SELECT/CTRL(doesn't specify if left or right), RIGHT SHIFT... There are three other Diodes that must go to switches not on the two schematic pages I was given, they are just labeled DROW5,6 and 7...  I assume two may be going to the smaller auxiliary game buttons as they are on the other page(connectors are labeled different so not 100% sure), as for the third not sure... Nikolaus warned me of the unfinished state of the schematic, I noticed there is even a breakage in the circuitry I'll need to figure out when I get to building my project.


But I'll repeat again, the schematic is irrelevant as it's not finalized and most likely will change once an official layout is chosen, I was just given a glimpse of how to start my project.  


Edit: cleaned up writing.
 
Last edited by a moderator:
I would really like to get some clarification something.

Most of the layouts I see have PrtScn and SysRq split into two separate keys. I would really like to understand the logic behind this, given that on most full-size keyboards they are on the same key, just like how Pause and Break usually share the same key as well.

Also, many such layouts (except for a couple) also lack a Pause/Break key.

Is there really a good reason to not move the SysRq key to be together with PrtScn on layouts like _wb_'s latest and change the foremr SysRq to Pause/Break? The Pause/Break key I feel should not[ be underestimated as there are many emulators that I've used that use it to pause emulation, which is separate from the typical Start button pause in which the emulation is still using CPU cycles and thus power, where as pausing the whole emulation effectively suspends it, so the emulator process uses minimal system resources (and battery power.)

At least this has been the case for me on desktop emulators. I do not own a Pandora so I don't know if Pause/Break was ever used in it's console and such emulators.
 
ALTGR, MENU/ESC(assume like Pandora button), SELECT/CTRL(doesn't specify if left or right), RIGHT SHIFT... There are three other Diodes that must go to switches not on the two schematic pages I was given, they are just labeled DROW5,6 and 7... I assume two may be going to the smaller auxiliary game buttons as they are on the other page(connectors are labeled different so not 100% sure), as for the third not sure... Nikolaus warned me of the unfinished state of the schematic, I noticed there is even a breakage in the circuitry I'll need to figure out when I get to building my project.
Are you sure those keys are actually part of the keyboard matrix?  On the Pandora all the gaming buttons including Start/Select/Pandora had their own input lines. 

-Neelix
 
Back
Top