It's the keyboard layout.


Except that of course that unlike the fn key on the Pandora it will also need to generate an input event of its own to be used on a shoulder button.
Yes, and this is where some tricks are going to come into play.Will it go full software route? That is, if "Fn+B='>'" (random example) will a program see "fn" and "B"?

Or will it be a "hardware" modifier, will it see "Fn" and ">" and the "B" is lost?
 
Except that of course that unlike the fn key on the Pandora it will also need to generate an input event of its own to be used on a shoulder button.
Yes, and this is where some tricks are going to come into play.
Will it go full software route? That is, if "Fn+B='>'" (random example) will a program see "fn" and "B"?


Or will it be a "hardware" modifier, will it see "Fn" and ">" and the "B" is lost?
OR...  The Fn buttons ARE two different buttons with TWO different actual applications.

Have the Fn on the keyboard be an "emulated hardware Fn".  It can and needs to always be "Fn".

Have the Fn on the shoulder be an "emulated software Fn".  It can and needs to change definitions to joystick buttons.

That would mean that DosBox compliance would only 'work' using the keyboard Fn.  That is acceptable to me.

Would that work?

Don't fear different.  Sometimes different can be far more flexible and efficient than attempts to fit "normal" into an abnormal construct.

http://www.keyboard-layout-editor.com/#/layouts/ee8d3bc8b446f99c027105d3810f8d07
 
Have the Fn on the keyboard be an "emulated hardware Fn".  It can and needs to always be "Fn".

Have the Fn on the shoulder be an "emulated software Fn".  It can and needs to change definitions to joystick buttons.

... 

Would that work?
Seems like a bad idea to me. If the buttons behave so fundamentally different, they should not be called the same.This way you are just introducing another modifier key which you map, by default, to Fn-like behaviour.

I'm not yet sure how, but I'm confident we can find a better solution than this.
 
Have the Fn on the keyboard be an "emulated hardware Fn".  It can and needs to always be "Fn".


Have the Fn on the shoulder be an "emulated software Fn".  It can and needs to change definitions to joystick buttons.


... 


Would that work?
Seems like a bad idea to me. If the buttons behave so fundamentally different, they should not be called the same.
This way you are just introducing another modifier key which you map, by default, to Fn-like behaviour.


I'm not yet sure how, but I'm confident we can find a better solution than this.
From the user's perspective, they won't actually behave differently - at least not until the shoulder buttons are taken over by a game.  Which is a behavior that pretty much every layout suggested must do.  I'm not inventing something in my earlier statement, I am simply stating what is the obvious required behavior if you think about the actual scenario.
 
According to ED's twittering here, he seems enamored with Eight-Bit's "International" Pyra keyboard layout:

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


Congratulations to Eight-Bit.  :)
I wouldn't say congrats to Eight-Bit.


I'd say congrats to anyone who discussed about it, made suggestions and created layouts.


It's a collaborative effort, I'm pretty sure you all affected each other :)
So, is that the Pyra keyboard layout then ED?
 
Congratulations to Eight-Bit.  :)
And condolences to everyone else...
Sorry Eight-Bit, I really don't like that one:

- No "Dosbox compatibility"

- Stretching to reach backspace

- The odd pairing of \ with ? instead of / with ?, which puts the more common / on the Fn layer and the less common \ on the primary.

- You will be accidentally triggering scroll lock all the time (alternate symbols on modifiers are a BAD idea)

- Pyra button paired with Esc means vimmers will be accidentally triggering their system menu all the time.
 
I never said I'll use that layout completely as is.

I'll probably move a few keys around. Especially ESC, which shouldn't be up there.
 
I never said I'll use that layout completely as is.

I'll probably move a few keys around. Especially ESC, which shouldn't be up there.
Perhaps a good idea to briefly review the final layout before committing to it. Just to filter out potential mistakes or oversights.From what I've seen most of the guys working actively on these layouts are pretty good in spotting possible problems.

Challenge will be to keep it brief :D
 
Aren't those Keys on the bottom Row on the Left and Right side very Hard to reach? It's hard to reach that Place on the original Nintendo DS. Maybe ED should test it on the prototype.
 
Aren't those Keys on the bottom Row on the Left and Right side very Hard to reach? It's hard to reach that Place on the original Nintendo DS. Maybe ED should test it on the prototype.
No need to test, they are at the exact same position as on the Pandora, and when typing, they are easy to reach :)
 
http://www.keyboard-layout-editor.com/#/layouts/a81177f6e3252a77ad426a1c85beace4

Aside from the clear randomness of the symbols, these in particular jump out:

  • Backspace way up top. Please don't.
  • Enter having a Fn value. Please don't.
  • Brightness toggles on one key. Please don't do this.  
  • Hardware toggles on one lonely key. Ya know.
  • Menu key? 
  • L1 should be Shift. 
  • { } should be on the opposite side from keyboard Fn.
I realize the international crowd is your bread and butter but must we have a sampling from every one of them as default? I always assumed you were present in some form during the many, many months of discussion but it appears you really were absent. Well, I'm sure the community will come together, again, for this.

I'm done for now but I'm intrigued to see what materializes out from you guys for the final product. Good luck. :)   
 
I never said I'll use that layout completely as is.

I'll probably move a few keys around. Especially ESC, which shouldn't be up there.
So DosBox compatibility is right out?That's a pity, I was looking forward to the Fn-Shift combos.

What about this particular layout got the "yes" and things about other layouts got a "no"? If this is the base you now want people to work with it'd help to avoid making mistakes if we knew what mistakes were to be avoided.
 
I never said I'll use that layout completely as is.

I'll probably move a few keys around. Especially ESC, which shouldn't be up there.
So DosBox compatibility is right out?That's a pity, I was looking forward to the Fn-Shift combos.

What about this particular layout got the "yes" and things about other layouts got a "no"? If this is the base you now want people to work with it'd help to avoid making mistakes if we knew what mistakes were to be avoided.
I've checked all keyboard layout linked from that google drive thing, and that one was the best so far.

All other ones had things missing or weird layouts.

I cannot possibly imagine there's a layout out there that works good for normal usage and also or DOSBox.

We got to live with that - we're not creating a DosBOX device, but a mini computer.
 
All other ones had things missing or weird layouts.
They may have been just not printed :) . For example in my layout ßäö are there under meta in their standard positions under US-International layout.

Anyway, my first thoughts on the presented layout:

  • How would one press Pyra with any key under Fn? Modifier keys should never be under modifiers nor should they have modified meanings. Maybe put pause under Fn instead of Pyra?
  • The Fn key here probably means a software modifier?
  • The action button labels look a bit "wonky" because of how A and B are handled.
  • Backspace is quite far. I understand the top-row location for Esc, but backspace should be closer by.
 
Back
Top