It's the keyboard layout.


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.
 
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...
 
Last edited by a moderator:
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 { } | _ + : ?. ;)    
 
Last edited by a moderator:
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.
 
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.
 
Last edited by a moderator:
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.
 
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'.
 
Last edited by a moderator:
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
 
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.
 
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? :P
 
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.
 
Last edited by a moderator:
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. 
 
Last edited by a moderator:
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...
 
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
 
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...
I meant for when the Power button is used for SysRq. 

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
It's not my solution Neelix. It worked on the Pandora. Press Shift + Fn + , for : that is, according to the wiki.

-Saber 
 
On the other hand: At least to me, the main point of the keyboard is to work as a device for, you know, typing stuff. And of course, it is useful when i emulate things with keyboards, like my dear old spectrum, or Atari ST, or C64, or Archimedes, or most anything of the sort. All which has emulators that does manage, funnily enough, to take the differences between the emulated keyboard and the existing keyboard into account. And yes, I do gather that for some reason, dosbox does not do that. I still fail to see that as a failing of the device that dosbox run on, rather than a lack of functionality in dosbox, but there you go.

I, personally, can't imagine anything duller than old PC games, when there does exist, like, good games out there. I've never ever started up dosbox, and if I'd ever felt the urge, then Grench has completely killed it for me by now. That's me, though. I see that there are other for whom old PC games inspire almost religious fervour, filling up post page after post page with repeated requests that the keyboard must be designed around dosbox' lack of input flexibility. That in a volume that almost makes it seem that it is some sort of majority opinion.

So, I'd just like to politely register my opinion to the contrary: I don't care the least bit about dosbox. I find this whole fixation around a single application with apparently rather ill-designed input mapping preposterous, as is the fixation with the crappy US-ASCII layout. My view is that if there is any need to compromise general usabilty of the device in any way, in order to accomodate the needs of the single application that is dosbox, then screw dosbox.

But, then again, I do trust ED to have his priorities right.
 
Last edited by a moderator:
I meant for when the Power button is used for SysRq.
I don't understand what the problem is.It is both. It is a power button and it is the SysRq at the same time, or at least it can be. If the power is off and you press the button the PWM signals a wakeup, just like on the Pandora. If it is on then the PWM ignores the signal and instead the OS handles it. If you simply press and release it then it goes to sleep, and the next time it is pressed the PWM will see the signal and wake up, just like on the Pandora. If you hold it down for 4 seconds it triggers the shutdown process, just like on the Pandora. It'd be pretty simple to add some additional functionality so that it could poll the game buttons or keyboard hardware directly to figure out if there are any magic SysRq keys being pressed and do the expected thing. If you hold it for more than 9 seconds it sends a hard off signal to the PWM, just like on the Pandora (actually I think that's part of the PWM design so assuming we have a similar module that'd come to the Pyra for free)

Currently on the Pandora this is all handled in user space but there's no technical reason it can't be done in kernel space where it would act as an interrupt.
 
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.
 
An input daemon that automatically transforms Meta+P to faked Shift+' events would be good enough though.
Asking because interested: How would this work? I understand how generating additional keypresses based on existing input works, but how do you stop the existing keypress event from propagating and ensure the daemon is the first one to get it?
 
Back
Top