It's the keyboard layout.

[Grench]

I suspect you may be seeing only one side of this coin. The Pandora's layout is a broken compromise. The symbol key pairs are all broken and the symbols themselves are scattered around pretty much at random in order to make them fit on the Fn layer. The shift and Fn buttons are on opposing sides, making chording them difficult. Yes, we can and should do MUCH better than the Pandora. Fixing this symbol pairs breakage and allowing keys to hold a more natural position should be paramount.

I do think that having non-primary numbers is an option worth considering, but in my mind, it has one important downside:

it means the layout is not strictly better (that is, better in every single respect) than the Pandora layout.

I do think that having primary numbers is an option worth considering, but in my mind it has one important downside:It means the layout is not strictly better (that is, better in every single respect) than the Pandora layout. It forces the symbol pairs to break and assignments to be randomly scattered on the Fn layer JUST LIKE THE PANDORA, resulting in us repeating the same mistakes.

Since we have more keys available than on the Pandora, it is possible to have a layout that is strictly better: every key that is a primary key on the Pandora can also be a primary key on the Pyra, we just have keys in better positions (number row more reachable), some keys that used to be on the Fn-layer on the Pandora can now become primary keys, and some keys that were not available at all on the Pandora (e.g. üöä) can now become available.

Since we have more keys available than on the Pandora, it is possible to have a layout that is strictly better: every key that had it's pairs split and scattered aorund on the Pandora can be a primary key on the Pyra, we just have keys in better positions (symbol keys more reachable), some keys that used to be on the Fn-layer on the Pandora can now become primary keys, and some keys that were not available at all on the Pandora (e.g. üöä) can now become available.

So I want to go back to "numbers on primary keys" for now, and also "no Shift+Fn/Meta symbols", because that also breaks the "has to be strictly better than Pandora" principle (yes, you can argue that Shift+Meta is an "easy mash", but even if the difference is little, it is still worse than just one modifier; "DOSBox compatibility" is an orthogonal issue that should be fixed by fixing DOSBox or with a global input translation daemon).

So I want to stick with "numbers on Fn" for now, and retain the logical "Shift+Fn/Meta symbols" on the number row, because that allows us to make a layout that "is strictly better than Pandora" principle (Shift+Meta is an "easy mash", but even if the difference is little, it is still BETTER than having the symbols broken up and scattered around; "DOSBox compatibility" is hardware issue that should be fixed by ensuring our keyboard mapping matches the DOSBox, QEMU, etc. convention. It is EASY to do IF we allow the number row to be on the Fn layer..

Layouts like this:

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

are far -better- than the Pandora layout -because- of what it allows on the symbols keys that the other layouts want to break up and scatter.

~ should be on shift+`. They should share a primary key labeled `~ such that Fn+`~ is the related diacritic. This same rule should apply to all of the 'native' symbol pairs on a US standard keyboard:

`~

-_

=+

[{

]}

\|

,<

.>

/?

Symbols are more used than numbers.

Symbols are more likely to be used in sets of 1-2 where in other layouts it is modifier+symbol then release both.

Numbers are more likely to flow in longer strings where in this layout it is modifier+numbernumbernumber... then release. The modifier only has to be depressed once for a long string of numbers.

Symbols have a logical 3rd+4th layer Fn+key definition as dead key diacritics.

The numbers 1234567890 should be available top side at the same time as F1-F12 for gaming. Having them both on the Fn layer allows them to be Fn-locked to the forward layer at the same time. This effectively makes a 'game mode' where the Pyra will have:

D pad (4)

Nubs (2)

Right game pad (6)

Numbers 1-0 + Ü (11)

F1-F12 (12)

For a total of 12+11+6+2+4 = 45 key game pad ideally situated and set up for PC gaming on the Pyra.

Clearly we should emphasize having the symbol pairs retained for greater software compatibility AND easier diacritics AND faster typing AND faster coding. The fact that in the process we also gain the most awesome game layout ever seen - that's just a real big bonus.

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

 

[Saber]

So, in my humble opinion, you gave up a LOT to have those numbers on the top layer. I like numbers, but I like them a lot more when they're on the same Fn layer as F1-F12 AND freeing up space for the punctuation and bracket keys AND getting simple diacritics AND retaining symbol key pairs AND become capable of making a 33 key PC gaming control pad at the push of two buttons without loosing any letters AND while in Fn-Lock (gaming) mode, the Esc key becomes top-level (dedicated).

 

I’d also like to state that as much as some really dislike it and disagree with having two keyboard Shifts, and I do understand their side of it, that there are your fellow members who don’t concede the shoulder trigger Shift key in text entry tasks at all, and that if we do have two keyboard Shifts as in my layouts with Left Shift on the right side and Right Shift on the left side(and also reflected on L1), this arguably disposable Left Shift key could become at the user’s discretion by remap any key or keys they’d like it to be: Å, Ç, Ñ, /, \, |,  , Tab, SysRq, Pause, Menu, Super, all three of å, æ, ø, the Compose key, or even a dedicated Escape key should they want it there.    

3 shift keys is a complete waste - and why on earth would left be on the right and right on the left and right exists twice...? Logic fails.

I've said this before that not everyone who will buy a Pyra will use it to code, or play MORPG/DOSBox games, and I haven't given up anything by retaining numbers as primary. They are primary on keyboards because they are used by most general users quite often, yours truly included.

My layout though is viable even with one keyboard Shift key. It is up to ED to decide if he wants to keep two of them, and I hope that he does for symmetry, but as I've explained, with one Left Shift key placed on the right side half, we are given an opportunity to remap this key to anything we want as an owner should we choose to, and those who don't use the shoulder button Shift can have an easy time of forming capital letters while texting. Again, if ED says he wants only one keyboard Shift, then Left Shift will move back over to the left side, CAPS would then become Fn + L.Shift, and we have another key, unassigned as of yet and maybe to Compose, over on the right to play with. That's if he says he wants only one keyboard Shift, which I hope he doesn't.  :mellow:

As for symbols in my layout under Fn(Meta), with one of these modifiers on a shoulder and the other on the opposite side with the keyboard, it should be a breeze to output them, but again as I've repeated, with two keyboard Shifts, the as you say redundant one on the right side(Left Shift) could be remapped to any primary key the user may choose after ownership.   

 

[Saber]

I suspect you may be seeing only one side of this coin. The Pandora's layout is a broken compromise. The symbol key pairs are all broken and the symbols themselves are scattered around pretty much at random in order to make them fit on the Fn layer. The shift and Fn buttons are on opposing sides, making chording them difficult. Yes, we can and should do MUCH better than the Pandora. Fixing this symbol pairs breakage and allowing keys to hold a more natural position should be paramount.

I agree some of the Pandora layout is a mashup but I don't think removing the numbers as primary is an improvement over it. In my most recent layouts in my sig, symbol pair arrangements are better, brackets { [ ] } in particular. Symbols for - + = _ as well are in more effective locations too. 

 

[Urben]

I meant: less ambiguous specifically for the key "-_". Since the main difference between minus and underscore is their position, it is hard to tell which is which if you use the superscript convention. In fact, doing superscript on underscore brings it roughly to the level of minus, or even lower, depending on which symbol exactly you use for the dash key: hyphen (‐), en dash(–), em dash (—), minus (−), or hyphen-minus (-).

So for clarity it might be better to use a double (nested) superscript, or does that make it even worse?

One superscript:    -_ 

Two superscripts:   -_

No superscript:       -_

Why not make - the shifted key? Its easier to identify the _ if its actually at the bottom, which is possible when being primary.
_- or _-

EDIT: Oh I see its like you do on the default qwerty layout...

 

[Saber]

^

I think - and + should be on the same primary, Shift or Fn level. 

 

[Grench]

I agree some of the Pandora layout is a mashup but I don't think removing the numbers as primary is an improvement over it.

The Pandora REMOVED the symbol keys as primary, broke the symbol pairs and scattered them all over. My layout doesn't REMOVE the numbers, it REINSTATES the symbols in their proper pairs as primary keys. Numbers, being naturally ordered, don't get messed up and scrambled like symbols do when placed on a Fn layer. Numbers naturally occur as strings, where symbols naturally occur in singles and pairs. It is LESS onerous to have numbers on the Fn layer VS symbols on the Fn layer.
I have listed the benefits repeatedly. You see no benefit in:

Fixed symbol pairs so DosBox, QEMU and others don't have issues.

Symbols on top means SIMPLE diacritics.

Numbers and F1-F12 on the same Fn layer means that we get a 45 key PC gaming system with Fn-Lock engaged.

Symbols on top frees up keys for P+1 L+2 unencumbered German use WITHOUT encumbering English.

It isn't 'taking away numbers'. It is 'reinstating and allowing' everything that the Pandora LOST when they put the physical number row above the nubs.

In my most recent layouts in my sig, symbol pair arrangements are better, brackets { [ ] } in particular. Symbols for - + = _ as well are in more effective locations too.

They're still not properly paired. Better arranged, but still just as broken as the Pandora's.{ should be on shift+[, not Fn+W.

 

[codifies]

DOSBOX is a software issue period the reason its not already fixed... who cares... seriously it would have been fixed long ago if DOSBOX was vaguely an important issue.

Putting so much emphasis on what is barely a minority issue is harmful and holds back the design of the keyboard.

Symbols should be grouped by frequency and ease of finger accessibility and almost no other reason, or you'll end up with something that everyone will have reason to curse at one time or another...

 

[Saber]

I agree some of the Pandora layout is a mashup but I don't think removing the numbers as primary is an improvement over it.

The Pandora REMOVED the symbol keys as primary, broke the symbol pairs and scattered them all over. My layout doesn't REMOVE the numbers, it REINSTATES the symbols in their proper pairs as primary keys. Numbers, being naturally ordered, don't get messed up and scrambled like symbols do when placed on a Fn layer. Numbers naturally occur as strings, where symbols naturally occur in singles and pairs. It is LESS onerous to have numbers on the Fn layer VS symbols on the Fn layer.

I have listed the benefits repeatedly. You see no benefit in:


Fixed symbol pairs so DosBox, QEMU and others don't have issues.


Symbols on top means SIMPLE diacritics.


Numbers and F1-F12 on the same Fn layer means that we get a 45 key PC gaming system with Fn-Lock engaged.


Symbols on top frees up keys for P+1 L+2 unencumbered German use WITHOUT encumbering English.


It isn't 'taking away numbers'. It is 'reinstating and allowing' everything that the Pandora LOST when they put the physical number row above the nubs.

In my most recent layouts in my sig, symbol pair arrangements are better, brackets { [ ] } in particular. Symbols for - + = _ as well are in more effective locations too.

They're still not properly paired. Better arranged, but still just as broken as the Pandora's.
{ should be on shift+[, not Fn+W.

I've stated before that these pairs as a panacea could be mapped secondarily under Shift + Fn for DOSBox and QEMU where say [ ] \ - = ; / become by holding Shift + Fn with them, as it was done I presume on the Pandora for another Colon, to { } | _ + : ?.    

 

[WizardStan]

It's a good point you've brought up so I'm curious to know if the keyboard driver isn't working, then how do we utilize any low-level command combos, which is why we'd want SysRq in the first place?

If I'm right, and I'm 99.3% certain I am, even if the keyboard driver crashes into oblivion, pressing the power button will still trigger an interrupt in the kernel which can do low level reading of the GPIO for at least the game buttons if not the entire keyboard matrix.Just in case you aren't aware, an interrupt is basically a function call that is tied to the hardware and always happens, unless the kernel itself has crashed within a previous interrupt, in which case everything is so far beyond broken that recovery is not possible, but that usually doesn't happen.

 

[Grench]

DOSBOX is a software issue period the reason its not already fixed... who cares... seriously it would have been fixed long ago if DOSBOX was vaguely an important issue.

Putting so much emphasis on what is barely a minority issue is harmful and holds back the design of the keyboard.

Symbols should be grouped by frequency and ease of finger accessibility and almost no other reason, or you'll end up with something that everyone will have reason to curse at one time or another...

 

I agree some of the Pandora layout is a mashup but I don't think removing the numbers as primary is an improvement over it.

The Pandora REMOVED the symbol keys as primary, broke the symbol pairs and scattered them all over. My layout doesn't REMOVE the numbers, it REINSTATES the symbols in their proper pairs as primary keys. Numbers, being naturally ordered, don't get messed up and scrambled like symbols do when placed on a Fn layer. Numbers naturally occur as strings, where symbols naturally occur in singles and pairs. It is LESS onerous to have numbers on the Fn layer VS symbols on the Fn layer.
I have listed the benefits repeatedly. You see no benefit in:

Fixed symbol pairs so DosBox, QEMU and others don't have issues.

Symbols on top means SIMPLE diacritics.

Numbers and F1-F12 on the same Fn layer means that we get a 45 key PC gaming system with Fn-Lock engaged.

Symbols on top frees up keys for P+1 L+2 unencumbered German use WITHOUT encumbering English.

It isn't 'taking away numbers'. It is 'reinstating and allowing' everything that the Pandora LOST when they put the physical number row above the nubs.

In my most recent layouts in my sig, symbol pair arrangements are better, brackets { [ ] } in particular. Symbols for - + = _ as well are in more effective locations too.

They're still not properly paired. Better arranged, but still just as broken as the Pandora's.{ should be on shift+[, not Fn+W.

I've stated before that these pairs as a panacea could be mapped secondarily under Shift + Fn for DOSBox and QEMU where say [ ] \ - = ; / become by holding Shift + Fn with them, as it was done I presume on the Pandora for another Colon, to { } | _ + : ?.

And we're back to the spot where neither one of you understand what the 'DosBox issue' IS.

DosBox and others monitor keyboard hardware actions - NOT the OS keycodes. There is no software fix. Many VERY smart people have tried - and failed.

On your US standard keyboard, type in a { symbol. The actions you took were to:

1. Press and hold shift.

2. Press the [ key.

DosBox (and others) read that at a very near to hardware level then interpret the result of shift+[ as {.

If you have a key labeled as {, DosBox (and others) have no idea of how to interpret it.

DosBox is not broken. It is doing exactly what it was meant to do. The layout on the Pandora - and nearly every layout proposed in this thread - THOSE are broken by inventing their own symbol pairs (or lack thereof).

You're effectively saying that we should fix all of the non-broken software, using means unstated and unknown, to adjust to an intentionally broken keyboard layout.

 

[_wb_]

The thing is, you can emulate US-QWERTY shift-pairs on a non-standard keyboard like the Pandora's, just like you can emulate a Commodore 64 keyboard on a US-QWERTY keyboard. It takes some extra effort, but it can be done. And some extra effort will be needed anyway, because DosBox does not know about Fn/Meta either, so if it's just reading raw scancodes, it will most likely just ignore the Fn/Meta modifier.

Numbers behind Fn/Meta is not a huge problem for me, but ! * ( ) behind two modifiers is not so nice. Not a huge problem either, but at least mildly weird that [ ] are at the primary layer while ( ) are only at the fourth layer.

 

[Eight Bit]

My full sized keyboard has the curly brackets on altgr+8. I guess it's no good as it's not dosbox compliant.

 

[Grench]

The thing is, you can emulate US-QWERTY shift-pairs on a non-standard keyboard like the Pandora's, just like you can emulate a Commodore 64 keyboard on a US-QWERTY keyboard. It takes some extra effort, but it can be done. And some extra effort will be needed anyway, because DosBox does not know about Fn/Meta either, so if it's just reading raw scancodes, it will most likely just ignore the Fn/Meta modifier.

Nope. You still aren't understanding the issue.Please re-read this post from Mr Confusion and give it more thought.

http://boards.openpandora.org/topic/17881-its-the-keyboard-layout/?p=383251/URL]

Numbers behind Fn/Meta is not a huge problem for me, but ! * ( ) behind two modifiers is not so nice. Not a huge problem either, but at least mildly weird that [ ] are at the primary layer while ( ) are only at the fourth layer.

I didn't invent the US QWERTY layout. ( has been on 9 and ) has been on 0 longer than most of the forum members here have been alive. We can't change that fact. What we CAN do is ensure that our keys are paired up the same way so that software reading directly from the key presses will work properly.

My full sized keyboard has the curly brackets on altgr+8. I guess it's no good as it's not dosbox compliant.

Correct. As far as DosBox, QEMU and any other application or emulator that expects to find a US QWERTY keyboard, your keyboard's mapping is seen as illogical and 'broken'.

 

[Eight Bit]

What if a single modifier lay-out is made to have hidden (not printed on the key) copies of the US QWERTY keys as well as their single mod companion...

a US key with ' and " would be printed as Meta+L and Meta+P but Meta+Shift+L would give the same key as Meta+P.

Meta+Shift+P would do nothing or can be mapped I guess?

Would that solve the dosbox troubles? All you have to do is remember which keys are un-shifted

 

[_wb_]

What if a single modifier lay-out is made to have hidden (not printed on the key) copies of the US QWERTY keys as well as their single mod companion...

a US key with ' and " would be printed as Meta+L and Meta+P but Meta+Shift+L would give the same key as Meta+P.

Meta+Shift+P would do nothing or can be mapped I guess?

Would that solve the dosbox troubles? All you have to do is remember which keys are un-shifted

That's essentially how it already is by default, e.g. on the Pandora. It's not good enough.

An input daemon that automatically transforms Meta+P to faked Shift+' events would be good enough though.

 

[slaeshjag]

 

Correct. As far as DosBox, QEMU and any other application or emulator that expects to find a US QWERTY keyboard, your keyboard's mapping is seen as illogical and 'broken'.

And I suspect that your perfect US Qwerty mapping will JustWork™ when I change the keyboard in windows 95 to swedish, like it does on my desktop comp?

 

[_wb_]

The thing is, you can emulate US-QWERTY shift-pairs on a non-standard keyboard like the Pandora's, just like you can emulate a Commodore 64 keyboard on a US-QWERTY keyboard. It takes some extra effort, but it can be done. And some extra effort will be needed anyway, because DosBox does not know about Fn/Meta either, so if it's just reading raw scancodes, it will most likely just ignore the Fn/Meta modifier.

Nope. You still aren't understanding the issue.
Please re-read this post from Mr Confusion and give it more thought.

http://boards.openpandora.org/topic/17881-its-the-keyboard-layout/?p=383251/URL]

I do understand all possible issues that are referred to as "DosBox compatibility". It's actually a collection of issues, some of which are just impossible to fix (like typing Swedish easily in DOS in a simplistically coded DOS program that ignores the actual DOS keyboard/codepage), some of which take work to fix (like emulating US-QWERTY on something that is not a full US-QWERTY keyboard), some would be fixed by having all US-QWERTY standard shift keypairs plus a "hardware" Fn key (at least from the point of view of DosBox), some are simply a consequence of physically not having a full ISO keyboard and cannot really be fixed either.

 

[Saber]

It's a good point you've brought up so I'm curious to know if the keyboard driver isn't working, then how do we utilize any low-level command combos, which is why we'd want SysRq in the first place?

If I'm right, and I'm 99.3% certain I am, even if the keyboard driver crashes into oblivion, pressing the power button will still trigger an interrupt in the kernel which can do low level reading of the GPIO for at least the game buttons if not the entire keyboard matrix.
...

You're probably right but then again how do we keep the power button from behaving like the power button so the unit doesn't shutdown or sleep? Hold it down until another key we're sure we want to press for the MagicSysRq combo on the keyboard is pressed?

And we're back to the spot where neither one of you understand what the 'DosBox issue' IS.

DosBox and others monitor keyboard hardware actions - NOT the OS keycodes. There is no software fix. Many VERY smart people have tried - and failed.


On your US standard keyboard, type in a { symbol. The actions you took were to:


1. Press and hold shift.


2. Press the [ key.


DosBox (and others) read that at a very near to hardware level then interpret the result of shift+[ as {.


If you have a key labeled as {, DosBox (and others) have no idea of how to interpret it.


DosBox is not broken. It is doing exactly what it was meant to do. The layout on the Pandora - and nearly every layout proposed in this thread - THOSE are broken by inventing their own symbol pairs (or lack thereof).


You're effectively saying that we should fix all of the non-broken software, using means unstated and unknown, to adjust to an intentionally broken keyboard layout.

Is there any reason we can't preassign these pairs under Shift + Fn too using the U.S. standard? My understanding here is that for the Pandora when the individual hits Shift + Fn and , they get : in DOSBox, which is the Shift value for ; on a U.S. keyboard and which is the Fn value on the , key, again on the Pandora. This worked for DOSBox on the Pandora according to what I've read, so why can't we do this same workaround, as you've called it previously, for the Pyra where all of these: - = [ ] \ ; ' / ` when combo'd with Shift + Fn produce these: _ + { } | : " ? ~ symbols? Except for having to remember U.S. pairings, I don't see why this wouldn't be possible, again. 

 

[WizardStan]

how do we keep the power button from behaving like the power button so the unit doesn't shutdown or sleep?

Literally however we want. Press and release with no other key: sleep; press and hold for 4 seconds: initiate shut down process; press and hold for 9 seconds: hard power down; press and then press 'R': hard reset. Etc...

 

[Neelix]

Is there any reason we can't preassign these pairs under Shift + Fn too using the U.S. standard? My understanding here is that for the Pandora when the individual hits Shift + Fn and , they get : in DOSBox, which is the Shift value for ; on a U.S. keyboard and which is the Fn value on the , key, again on the Pandora. This worked for DOSBox on the Pandora according to what I've read, so why can't we do this same workaround, as you've called it previously, for the Pyra where all of these: - = [ ] \ ; ' / ` when combo'd with Shift + Fn produce these: _ + { } | : " ? ~ symbols? Except for having to remember U.S. pairings, I don't see why this wouldn't be possible, again.

 "How it 'worked' on the pandora"  is the problem to be solved.  Your solution is the problem.  Please stop dressing it up as a solution, it's getting tiresome.  

-Neelix