It's the keyboard layout.

[TrashyMG]

Having the Trademark symbol on a key is really handy on this forum for 2 Month™ references. 

 

[_wb_]

LOL I knew you were pulling out legs - much nicer!

Why not have R Shift on the right and L Shift on the left ?....

why have right shift on the left trigger why not left shift?

Wanted to keep it consistent with the Pandora where Right Shift is on L1. Due to some concerns mentioned, I thought it "safer" to not have the Right Shifts on opposite extremes to prevent them from simultaneously being pressed(in case this causes some software to implode). A small advantage too is Left Shift can(I think) be remapped without affecting the Shoulder Shift(if we will have two keyboard Shift keys).   

I have attempted pressing both left and right Shift keys simultaneously on both my laptop and desktop and so far neither have degenerated into a raging ball of plasma, or in any other way self destructed. Does there actually exist software that dislikes having both left and right Shift keys pressed together?

No, but there might exist software that dislikes having both the Right Shift key and the other Right Shift key pressed together.

 

[WizardStan]

Anything that uses the standard SDL keyboard example (See part 3-12 at the bottom) as the definitive "how-to-keyboard" will fail.

The 3-12 example uses just directions, but it should be pretty easy to see how, if there were two UP buttons (or down, left, or right) it could lead to confusing the game by pressing them both at the same time. Extrapolate that to any game that uses R_SHIFT for something and you'll see where the problem is.

Note that "failure" doesn't necessarily mean explosions and death (or at least crash), it's just undesired behavior.

 

[Saber]

Saber, when you post your keyboard layouts, could you please also add a link to it so those of us coming from email notifications can have something to click on? I don't mind coming to the forum, but it would be nice to have something more direct, especially when reading on mobile.

Sorry about that. It's in my sig too. 

 

[Grench]

Anything that uses the standard SDL keyboard example (See part 3-12 at the bottom) as the definitive "how-to-keyboard" will fail.

The 3-12 example uses just directions, but it should be pretty easy to see how, if there were two UP buttons (or down, left, or right) it could lead to confusing the game by pressing them both at the same time. Extrapolate that to any game that uses R_SHIFT for something and you'll see where the problem is.

Note that "failure" doesn't necessarily mean explosions and death (or at least crash), it's just undesired behavior.

Not to mention that it's a waste of an otherwise perfectly good and innocent key that could be better used for other purposes.

 

[_wb_]

OK, here is one more attempt to do something "comradekingu-style", with P+1, L+2 available for locale-specific stuff:

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


By default, P+1, L+2 have ' " , < . > and their Meta actions are 6 dead diacritics (as indicated by the dotted circles ◌), for acute, umlaut, cedilla, caron, dot and circumflex.


In a language-specific configuration, you would lose those diacritics (the idea being that you don't need them if you speak a language that just needs three extra letters at P+1 and L+2), and you get to choose:

• Either you have language specific letters (Ü Ö Ä, or Å Ø Æ, for example) in those spots as dedicated, primary keys, and have the original punctuation symbols behind Meta
• Or keep the punctuation symbols as dedicated keys and have the language specific letters behind Meta (so not at the primary layer, but at least in the correct spots)

You still get to keep a dedicated keyboard Meta, Shift and Tab whatever you do.

Otherwise, this proposal has the same features as my previous proposal, except that Tab is now in a weirder place, Shift and Meta are no longer neighbors, ` ~ has been replaced by ' " as a dedicated key, and the number row is no longer correctly aligned to the QWERTY row.

Will acute be possible with with this layout? Anyways, very sexy!

Acute accent would be Meta+' by default, so yes. You would however lose it if you remap the ' " key to, say, åÅ, because then ' " would be Meta+åÅ.

The idea is that you don't need those dead diacritics (acute, umlaut, cedilla, caron, dot, circumflex) if you speak German/Scandinavian (the languages for which it makes sense to map three extra dedicated keys: either ÜÖÄ, ÅÖÄ, ÅØÆ or ÅÆØ).

And even for multilingual use it is still possible to make for example a German/French layout which has dedicated ÜÖÄ and ß at Meta+S, plus for French àçèé at Meta+ACVB and dead circumflex at Meta+F (all unlabeled but there's room available).

 

[Saber]

Anything that uses the standard SDL keyboard example (See part 3-12 at the bottom) as the definitive "how-to-keyboard" will fail.


The 3-12 example uses just directions, but it should be pretty easy to see how, if there were two UP buttons (or down, left, or right) it could lead to confusing the game by pressing them both at the same time. Extrapolate that to any game that uses R_SHIFT for something and you'll see where the problem is.


Note that "failure" doesn't necessarily mean explosions and death (or at least crash), it's just undesired behavior.

Without opening another can of Borscht about the subject, I have a question for the forum that relates to this. On the Pandora, to my knowledge, the Spacebar is Left Space and Right Space but does this "splitting" in hardware(and software?) exist on all keyboards with a Spacebar? 

 

[TrashyMG]

On the Pandora, to my knowledge, the Spacebar is Left Space and Right Space but does this "splitting" in hardware(and software?) exist on all keyboards with a Spacebar? 

There is no such thing as left and right space... It IS using two pads tied together in the keyboard matrix though. 

 

[Saber]

On the Pandora, to my knowledge, the Spacebar is Left Space and Right Space but does this "splitting" in hardware(and software?) exist on all keyboards with a Spacebar? 

There is no such thing as left and right space... It IS using two pads tied together in the keyboard matrix though. 

Okay and thanks but it's curious then how the two buttons share "space" communally:

https://github.com/torvalds/linux/blob/master/include/uapi/linux/input.h#L272

 

[myNewUsername]

OK, here is one more attempt to do something "comradekingu-style", with P+1, L+2 available for locale-specific stuff:

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


By default, P+1, L+2 have ' " , < . > and their Meta actions are 6 dead diacritics (as indicated by the dotted circles ◌), for acute, umlaut, cedilla, caron, dot and circumflex.


In a language-specific configuration, you would lose those diacritics (the idea being that you don't need them if you speak a language that just needs three extra letters at P+1 and L+2), and you get to choose:

• Either you have language specific letters (Ü Ö Ä, or Å Ø Æ, for example) in those spots as dedicated, primary keys, and have the original punctuation symbols behind Meta
• Or keep the punctuation symbols as dedicated keys and have the language specific letters behind Meta (so not at the primary layer, but at least in the correct spots)

You still get to keep a dedicated keyboard Meta, Shift and Tab whatever you do.

Otherwise, this proposal has the same features as my previous proposal, except that Tab is now in a weirder place, Shift and Meta are no longer neighbors, ` ~ has been replaced by ' " as a dedicated key, and the number row is no longer correctly aligned to the QWERTY row.

Will acute be possible with with this layout? Anyways, very sexy!

Acute accent would be Meta+' by default, so yes. You would however lose it if you remap the ' " key to, say, åÅ, because then ' " would be Meta+åÅ.

The idea is that you don't need those dead diacritics (acute, umlaut, cedilla, caron, dot, circumflex) if you speak German/Scandinavian (the languages for which it makes sense to map three extra dedicated keys: either ÜÖÄ, ÅÖÄ, ÅØÆ or ÅÆØ).

And even for multilingual use it is still possible to make for example a German/French layout which has dedicated ÜÖÄ and ß at Meta+S, plus for French àçèé at Meta+ACVB and dead circumflex at Meta+F (all unlabeled but there's room available).

Acute is used in norwegian on some 'foreing' words although rarely. example: allé = avenue, moské = mosque. I am possibly not seeing the implications, but if acute can be available (un-labeled) somewhere on the norwegian version, this layout is great success from the perspective of your humble commentator. Will break the concept of only three international keys though.

 

[TrashyMG]

Okay and thanks but it's curious then how the two buttons share "space" communally:   https://github.com/t...ux/input.h#L272

I only see one space in that code...


How it will be done on the Pyra they're will be two keypads which will essentially be the same key. 


In the omap5 Device tree source code the TCA8418 keypad matrix IC is setup for both keys to output the keycode for space.

http://dev.pyra-handheld.com/index.php/p/pyra-kernel/source/tree/bb5ff8280402a708dc06d4d8c0a820b3ab91b758/arch/arm/boot/dts/omap5-pyra.dts

In the TCA8418 section of code there is a bunch of hex values, that defines what keycode is used when a specific key is hit in a specific row/column.. I made a spreadsheet to decipher what Nikolaus initially setup (obviously not final layout). 


here is an excerpt:

 

[comradekingu]

The problem is he considers pandora layout to be OK, and in thinking so, uses all the advantage gained from new provisions on polishing a wreck.

Those who are OK with pandora-layout are OK with not following standards, this is however not the case for those who aren't OK with pandora layout.

A compromise needs to be a compatible solution, you cant have that by going down the route of exclusion and forever chasing issues that don't answer the real problem.

But you are flat out skipping buttons to make it happen. Preserving alignment between numbers and letters, and then skipping letters, for purpose of being a "normal" keyboard is creating more issues than it solves.

I'm not skipping US-QWERTY letters. I am skipping German and Scandinavian letters, just like I'm skipping some US-QWERTY symbols, because something has to be removed when you go from 104 keys to 67 keys, and I'd rather remove üöä / åøæ as primary keys than some of the other keys. But I agree that this is a matter of priorities and I understand that other people have different priorities than me.

You started with an ANSI keyboard, respected alignment between numbers and letters by removing some of the keys, supposedly you then arrive at normal keyboard.

Whether its keys in the sense of ANSI, or letters for the ISO or JIT, its still more important than the alignment of the number-row.

It stops being possible to respect typewriter layout with respect to letters and language-modifiers for anything beside English as soon as you make the alignment the most important issue.

Edit: I see the attempt to make amends by moving , and . up to the ASDF-row. Already there its dubious, but why would people want to exchange , and . which are used very often, for dedicated letters. Thats between a rock and a hard place. Also it feels like im a second class citizen that gets third rate support.

Coming along, hoping it improves to where its balanced.

 

[Saber]

Okay and thanks but it's curious then how the two buttons share "space" communally:   https://github.com/t...ux/input.h#L272

I only see one space in that list... How it will be done on the Pyra they're will be two keypads will be electrically tied together, making it essentially one switch,  it was said in some other thread that it would be easy to separate these for those that want to mod.

I see that too, one space, which to elucidate is on the Pandora two buttons(separate scancodes I think) that have been pressed together without clashes since introduction. Maybe it's as you say one pair tethered mechanically together as one button in unison.    

 

[_wb_]

OK, here is one more attempt to do something "comradekingu-style", with P+1, L+2 available for locale-specific stuff:

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


By default, P+1, L+2 have ' " , < . > and their Meta actions are 6 dead diacritics (as indicated by the dotted circles ◌), for acute, umlaut, cedilla, caron, dot and circumflex.


In a language-specific configuration, you would lose those diacritics (the idea being that you don't need them if you speak a language that just needs three extra letters at P+1 and L+2), and you get to choose:

• Either you have language specific letters (Ü Ö Ä, or Å Ø Æ, for example) in those spots as dedicated, primary keys, and have the original punctuation symbols behind Meta
• Or keep the punctuation symbols as dedicated keys and have the language specific letters behind Meta (so not at the primary layer, but at least in the correct spots)

You still get to keep a dedicated keyboard Meta, Shift and Tab whatever you do.

Otherwise, this proposal has the same features as my previous proposal, except that Tab is now in a weirder place, Shift and Meta are no longer neighbors, ` ~ has been replaced by ' " as a dedicated key, and the number row is no longer correctly aligned to the QWERTY row.

Will acute be possible with with this layout? Anyways, very sexy!

Acute accent would be Meta+' by default, so yes. You would however lose it if you remap the ' " key to, say, åÅ, because then ' " would be Meta+åÅ.

The idea is that you don't need those dead diacritics (acute, umlaut, cedilla, caron, dot, circumflex) if you speak German/Scandinavian (the languages for which it makes sense to map three extra dedicated keys: either ÜÖÄ, ÅÖÄ, ÅØÆ or ÅÆØ).

And even for multilingual use it is still possible to make for example a German/French layout which has dedicated ÜÖÄ and ß at Meta+S, plus for French àçèé at Meta+ACVB and dead circumflex at Meta+F (all unlabeled but there's room available).

Acute is used in norwegian on some 'foreing' words although rarely. example: allé = avenue, moské = mosque. I am possibly not seeing the implications, but if acute can be available (un-labeled) somewhere on the norwegian version, this layout is great success from the perspective of your humble commentator. Will break the concept of only three international keys though.

Well, this is how I would map the unlabeled Meta-keys on Meta+ASCVBN by default: http://www.keyboard-layout-editor.com/#/layouts/a2830a14a47828de04158ed2865062e4

Those are the most important letters needed for French, Spanish and Portuguese (and together with the dead acute, circumflex, tilde, diaeresis and grave, those languages can be efficiently typed). I kept them unlabeled for greater flexibility and to avoid "foreign clutter" on the keymat.

So if you only need acute on the letter E (éÉ), like in French which only has an acute on that letter, then that default Meta+V would be good enough for your needs.

Also we could duplicate all the dead diacritics in the P+1, L+2 area as unlabeled Shift+Meta keys elsewhere, e.g. as follows:

Shift : for dead umlaut

Shift { for dead caron

Shift } for dead circumflex

Shift \ for dead acute

(where you can remember which is where by rotating your head 90° to the right)

 

[Saber]

(where you can remember which is where by rotating your head 90° to the right)

Been a while since I've seen the head tilt feature. Hard to believe we've been working on this layout thing so long.  :lol:

 

[codifies]

polishing a wreck.

In English the idiom is  polishing a t..... right I see what you did there!

Just to reiterate I too think that slavishly following a previous design is unnecessarily restrictive, while the Pandora wasn't a terrible design (far from it) I've already seen better layouts on this thread...

 

[comradekingu]

The pandora layout is a hack. Its a crux when you do the same thing when you dont have to.

wb: Why so cryptic, whats wrong with the US international diactric-symbols? And why not all of them?

The french will look for their letters on number row, because thats where they are used to finding them. Big and small versals with shift makes sense too, albeit isnt standard. All of which is only possible while maintaining more important things (US shiftrow symbols) by having a language-layer key.

 

[_wb_]

Edit: I see the attempt to make amends by moving , and . up to the ASDF-row. Already there its dubious, but why would people want to exchange , and . which are used very often, for dedicated letters. Thats between a rock and a hard place. Coming along, hoping it improves to where its balanced.

, and . are used very often in formal written language. A bit less so in informal language like irc, game chat, sms or IM messages, etc. Putting them behind a modifier is not the end of the world. For example, the standard French AZERTY keyboard has period (.) as a Shift-key — exclamation mark (!) is a primary key though, so perhaps French people just shout more than others.

If I would want to have dedicated primary keys for Å Ø Æ, then I would rather put , . ' behind Meta (and < > " behind Shift+Meta) than to lose keyboard Shift and Meta, even though I'm a big fan of shoulder button modifiers.

 

[WizardStan]

Maybe it's as you say one pair tethered mechanically together as one button in unison

Exactly that. Both pads are tied together such that when one is closed the other in the keyboard matrix is closed as well. You can't have a situation where both switches are closed and then one is opened because so long as one is closed they both are, at the physical level. It's a very easy-to-cut trace so no problem for someone with an interest to split them apart and get two distinct keys out of it. From my understanding ED intends to keep it the same on the Pyra.

 

[comradekingu]

The French are the mustard race. The issue is there for everyone else (period).