It's the keyboard layout.


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?
 
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
 
Last edited by a moderator:
Like a number of other people I don't care about dosbox compatibility, but I'm happy that a small but verciferous few are helping us achieve the 100 page goal....
 
I don't think having standard US-QWERTY symbol shift-pairs is important enough to make us put printable ASCII characters on the fourth layer (Shift+Fn/Meta), and it makes little difference to me whether it is {}:"|_+? or !@#$%^&*() that ends up on the fourth layer. We can make a layout that only uses three layers (primary, shift, Fn/Meta), at least for the printable ASCII characters — I'm not talking about Shift+F5 or capital Ü here.

But I want to point out that having standard US-QWERTY symbol shift-pairs might be (very slightly) useful for other reasons than just DosBox. A lot of modern software still assumes a keyboard to have a certain layout. For example, in Firefox, I can use Ctrl + and Ctrl - to zoom in and out. But I can also use Ctrl = instead of Ctrl +, which is easier because = is an unshifted symbol, namely the one that is to the right of - and which has + as a shift-value. This makes sense only because = and + are on the same physical key on standard US-QWERTY keyboards.

So it is quite likely that some software kind of makes the assumption (in a subtle way) that those shift-pairs are what they are.

Note that I still don't think this is reason enough to abandon the "at most one modifier per symbol" principle (all printable ASCII symbols on the first 3 layers). After all, there are many people who don't use a US-QWERTY keyboard (e.g. the Germans, the French, etc.), so if software is making hidden assumptions about keyboard layouts, that is going to be somewhat problematic anyway, not just on the Pyra. Having a layout that is as simple and efficient as possible, is the important thing. Making some important symbols like ( ) or : " harder to type, just as a workaround for flawed software, is not the way forward.

That would be like fixing a software bug by modifying the CPU to misbehave in specific ways just to avoid triggering the bug, even if that means that bona fide software might get results like 1 + 1 = 2.034817 as a side-effect.
 
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.
Thanks for explaining. As much as I know of SysRq and after reading this I'm inclined to add an Alt together with Power if it's going to act the part of SysRq too.   

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
I presume you're speaking of this post. If it's doable as opposed to moving the numbers behind Fn(Meta) then it's great.   
 
Last edited by a moderator:
Thanks for explaining. As much as I know of SysRq and after reading this I'm inclined to add an Alt together with Power if it's going to act the part of SysRq too
Yeah, that's totally acceptable, preferable even. Maybe even more, L-trigger and R-trigger, just so there's less chance of accidents.But we can decide on the specifics later, the important thing is to make sure the Power button really is on a hardware interrupt (it should be) and agreeing that it makes some kind of sense to use it that way.

And then finding someone to actually write the code, of course.
 
Here is another variant, with a centered QWERTY row again, but with some interesting changes:

http://www.keyboard-layout-editor.com/#/layouts/ca64e4e86233f302a7d52150ec0909d5
I like the centered one, the del and backspace idea makes sense and putting insert on meta space is good too.
Not many people have replied yet, so I'm asking explicitly now: instead of having Ins/Del on the extra action buttons, we could make them Del/Backspace. That means we have one more key in the main keyboard part. What do you think? Good idea or not?
 
Here is another variant, with a centered QWERTY row again, but with some interesting changes:

http://www.keyboard-layout-editor.com/#/layouts/ca64e4e86233f302a7d52150ec0909d5
I like the centered one, the del and backspace idea makes sense and putting insert on meta space is good too.
Not many people have replied yet, so I'm asking explicitly now: instead of having Ins/Del on the extra action buttons, we could make them Del/Backspace. That means we have one more key in the main keyboard part. What do you think? Good idea or not?
Being impartial here. I would place Backspace at Meta + Spacebar so it is at/closer to the keyboard, keep Delete where it is.  

B)
 
Last edited by a moderator:
Here is another variant, with a centered QWERTY row again, but with some interesting changes:

http://www.keyboard-layout-editor.com/#/layouts/ca64e4e86233f302a7d52150ec0909d5
I like the centered one, the del and backspace idea makes sense and putting insert on meta space is good too.
Not many people have replied yet, so I'm asking explicitly now: instead of having Ins/Del on the extra action buttons, we could make them Del/Backspace. That means we have one more key in the main keyboard part. What do you think? Good idea or not?
Being impartial here. I would place Backspace at Meta + Spacebar so it is at/closer to the keyboard, keep Delete where it is.  

B)
No dedicated backspace key? That is not acceptable to me.

The bottom extra game button is very close to the keyboard, just above the O key on the Pandora. Compared to where backspace is on the Pandora (very top row), I think that's still an improvement. Not having backspace as a dedicated key would be a step backwards compared to the Pandora.
 
Here is another variant, with a centered QWERTY row again, but with some interesting changes:

http://www.keyboard-layout-editor.com/#/layouts/ca64e4e86233f302a7d52150ec0909d5
I like the centered one, the del and backspace idea makes sense and putting insert on meta space is good too.
Not many people have replied yet, so I'm asking explicitly now: instead of having Ins/Del on the extra action buttons, we could make them Del/Backspace. That means we have one more key in the main keyboard part. What do you think? Good idea or not?
Being impartial here. I would place Backspace at Meta + Spacebar so it is at/closer to the keyboard, keep Delete where it is.  

B)
No dedicated backspace key? That is not acceptable to me.

The bottom extra game button is very close to the keyboard, just above the O key on the Pandora. Compared to where backspace is on the Pandora (very top row), I think that's still an improvement. Not having backspace as a dedicated key would be a step backwards compared to the Pandora.
On my laptop Delete is Fn + Backspace. I'm not fond of it but it does the job. In your layout, with Fn(Meta) both on it's left half, placing Backspace under Fn + Spacebar would've been at least an improvement to the Pandora's location for it and not too difficult to do.

Anyhow, I think you should consider moving Backspace to where I have it in my layouts and then migrate Insert to Fn + Backspace. This will free up one of those keys. Maybe even jettison the Greek and Math keys to do so. Up to you as it's your proposal.  
 
Here is another variant, with a centered QWERTY row again, but with some interesting changes:

http://www.keyboard-layout-editor.com/#/layouts/ca64e4e86233f302a7d52150ec0909d5
I like the centered one, the del and backspace idea makes sense and putting insert on meta space is good too.
Not many people have replied yet, so I'm asking explicitly now: instead of having Ins/Del on the extra action buttons, we could make them Del/Backspace. That means we have one more key in the main keyboard part. What do you think? Good idea or not?
Being impartial here. I would place Backspace at Meta + Spacebar so it is at/closer to the keyboard, keep Delete where it is.  

B)
No dedicated backspace key? That is not acceptable to me.

The bottom extra game button is very close to the keyboard, just above the O key on the Pandora. Compared to where backspace is on the Pandora (very top row), I think that's still an improvement. Not having backspace as a dedicated key would be a step backwards compared to the Pandora.
On my laptop Delete is Fn + Backspace. I'm not fond of it but it does the job. In your layout, with Fn(Meta) both on it's left half, placing Backspace under Fn + Spacebar would've been at least an improvement to the Pandora's location for it and not too difficult to do.

Anyhow, I think you should consider moving Backspace to where I have it in my layouts and then migrate Insert to Fn + Backspace. This will free up one of those keys. Maybe even jettison the Greek and Math keys to do so. Up to you as it's your proposal.  
Feeling a sense of Déjà vu here...  I struggled between backspace as anti-space as fn+space Vs Insert on Fn+space, removing Insert from it's ganged key set.

After consideration, I decided that of the two (backspace or Insert), Insert is the lesser used key and could live at Fn+space.

http://www.keyboard-layout-editor.com/#/layouts/ee8d3bc8b446f99c027105d3810f8d07
 
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
 
Not many people have replied yet, so I'm asking explicitly now: instead of having Ins/Del on the extra action buttons, we could make them Del/Backspace. That means we have one more key in the main keyboard part. What do you think? Good idea or not?
I am absolutley pro Del/Backspace. It fits together and Ins is not that important to me, probably not that important to anyone. So I'd say put Ins as Meta somewhere else, like on space. Also the Del/Backspace Symbols are quite alike, which also adds some aesthetic points.
 
Last edited by a moderator:
I wouldn't have a problem either way but I can think of a possible problem.  If you had a program that used the gaming buttons as joystick buttons and also used the keyboard, you would no longer have backspace.  Like when using PNDManager now on the Pandora, you cannot use the shoulder button for shift because that button changes pages.  It may not be a problem but it is something to think about.
 
Back
Top