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
repeated requests that the keyboard must be designed around dosbox' lack of input flexibility
As I've said several times, I want so called DosBox compatibility because I think making use of the fn+shift combos to maintain common character pairs is the right thing to do. Calling it "DosBox compatibility" is just naming convenience, the fact that it actually makes DosBox easier to use is a side effect of the layout.
It's not my solution Neelix. It worked on the Pandora. Press Shift + Fn + , for : that is, according to the wiki.
It's not a solution at all, it's just a description of the problem. What _wb_ described above is a possible solution, it would
solve the problem. (assuming it works, and doesn't cause more problems than it solves)
You're not offering a solution though, you're effectively denying that the problem exists in the first place, and calling it solved.
-Neelix
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.
And we're back to re-stating the ISSUE and calling it a fix.
Clearly anyone smart enough to use DosBox, QEMU or ANY of the upcoming wave of Linux on PC games that will become playable on the Pyra should memorize the US QWERTY key pairs and remember which key was paired with which - AND while they're at it remember that the paired form of that key's LABELED key IS WRONG.
That isn't a fix. THAT is the issue. The Pandora exacerbated the issue by not only breaking up the symbol pairs from the standard keyboard, but also breaking up the symbol pairs on the number keys.
Look at the Pandora's '4' key. It's labeled shifted value is ~. If you're in DosBox and want to type a ~, you have to shift+fn+J, because that is where the ` key got thrown. The key labeled as ~ does nothing.
This is the problem, not a solution.
DosBox, QEMU and beyond are going to be big use cases on the Pyra. Android Virtual Machines, running through QEMU may/likely/could have the same issue. Any software written for very low latency - reading directly from keyboard actions - will experience this issue.
We can 'fix' this by simply maintaining the standard key pairs, both in label and function. We don't have to put the numbers on the Fn layer to 'fix DosBox'.
http://www.keyboard-layout-editor.com/#/layouts/467f092b9169fe6c6b411baa5a39beeb
The numbers on Fn layer thing is all about:
+What happens when Fn-lock is on and turning the top half of the keyboard into a giant bank of hot keys for gaming.
+Native German support without compromising English
+German keys create a logical expansion of the 6 button game pad into a 9 button game pad for the rest of us.
+Symbols on top - they're more commonly used than numbers.
+Symbols on top yields EASY diacritics.
+Easy to remember where everything is on the Fn layer. Numbers / F1-F12 / Foreign stuff.
+Esc IS a top key WHILE in game mode (Fn-Locked)
That is why THIS layout exists - DosBox compliance is an independent solution. Numbers on Fn is an extension of that idea to maximize usability for ALL uses, DosBox included, but FAR more than that.
http://www.keyboard-layout-editor.com/#/layouts/ee8d3bc8b446f99c027105d3810f8d07