It's the keyboard layout.


I would appreciate it next time if you, or others, don’t wait to bring any issues you discover to the forefront right away
I didn't notice it until just now.
In many places this seems to be the case, especially in Windows, but under Linux, AltGr appears to emit a keycode of 225 why the Alt keys give 17
So you have two Alt keys and an AltGr key? How are you getting these codes? There's two codes to be aware of, the scan code and the key code. The scan code is the literal code on the keyboard and the keycode is what the OS provides to software (or maybe it was the other way around... or different names, shoot, I'm going back several years trying to remember. The important thing being that there's two codes). I don't have an AltGr key on my keyboard to verify, but it could be that what you're looking at is the scancode which is unique, but the keycode is still that of right-alt.Just did a search, SDL reports it as right-alt for Linux and Mac and ctrl+alt (like you say below) on Windows.

AltGr actually just maps to Ctrl+Alt
Ctrl+Alt is supposedly the alternative when there is no right-alt key. It could be that Windows has chosen a single path of support such that when you press the AltGr key it just emits a ctrl+alt for software to look for. Linux and Mac apparently emit a single right-alt code when pressed.
Whatever AltGr and Right Alt share between them on other keyboards, on the Pyra, they will not share the same keycode
I thought that's what comradekingu was getting at with his "F-ing and AltGr" comment, that it would behave like a full sized keyboard's AltGr: "If you have F-ing along with AltGr, then AltGr is AltGr". In that case, the AltGr would need to emit a right-alt keycode when pressed, but then how does it differentiate from the actual alt key?
While I have you here, is there anything positive you have to say(about v2)?
I'd keep caps lock off the tab. Way too much CHANCE OF SOMEONE ACCIDENTALLY YELLING at someone in IRC or on a forum or whatever, anywhere you're likely to press tab at all.On a personal opinion, if you don't like Grench's shift-fn layout then I'd at least try to maintain some semblance of layered order. If "{" is on "W", put "[" below it on "A" instead of nesting them, know what I mean? Rearrange the punctuation into the middle two rows and the extra language ones into the bottom row. 'Cause as long as they're "not where they're supposed to be" they may as well be more conveniently not where they're supposed to be.
 
  • Like
Reactions: szr
Wb: Well you are still without mediabuttons when the lid is open. Its conventient to have that.

Saber: This is the post where you decided to go back to the thread that i left because it didnt explain any of the changes made, and didnt answer questions.

Also, as has been said over and over, its really hard to visualize something presented in divided form ASCII.

This is the post that you can answer.

WizardStan:   In xev

state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, = Alt

XKeysymToKeycode returns keycode: 92  = AltGr

One alt on the select button, one alt on the shoulder, one altGr on the shoulder

I dont know that having different non-altGR alts does anything, but maybe its the same as the two ctrls. For all intents and purposes it is just a duplication of the alt key.
 
Last edited by a moderator:
Grench:

- what does "Diacritic DeadKey" do? Is it some sort of modifier key? Or Compose?
As we've discussed before, English is my primary language. I speak and read Spanish some, but German and French needs are a bit of a mystery to me. If you're willing to help iron out the wrinkles, I appreciate the help.
It is my understanding that if you have a DeadKey it acts as a 'sticky key' that any letter entered afterwards goes through a list on each press of accented versions. Since we already have a few of the ones for German as Fn-keys, German won't need it. However, proper French has a -lot- of modifications that can be done on the English letters:

http://en.wikipedia.org/wiki/French_orthography

- dedicated Fn keys for äüöß for German, OK. Dedicated ç and ñ for Spanish/Portuguese/French, OK. But why Æ and Œ? Feels like a rather random selection of special symbols.
For French as there is, to my understanding, no equivalent to create them on a diacritic shuffle.http://en.wikipedia.org/wiki/French_orthography

- comma and period as non-primary keys is a step backwards compared to Pandora
For DosBox, Comma(,) MUST reside on the same symbol pair as (<). Period (.) MUST reside on the same symbol pair as (>).With the requirement that the keyboard be usable both handheld (shoulders accessible) AND desktop (in a dock, no shoulders accessible), the modifiers MUST be present and usable on the keyboard. Placing them in Fn-alternate center top buttons is a bad alternative. So, there simply isn't room on the physical keys to put the symbols ,./;'[]\-= and their associated key pairs in their traditional places.

Like it or not, the keyboard has fewer keys than a 'full sized normal' keyboard. There are compromises that need to be made in order to have key mappings for ALL of the standard keys. You will notice that I put the least used SysRq, ScrlLck and Break on those hard to reach top center keys. I made an error there - I was supposed to put PrtScr where I put ScrlLck (which gets dumped). They pair up nicely

- semi-nonsensical symbols like § ¥ ł ৳ ₪, I don't really see the point. It just adds clutter, and I don't think it really helps as a mnemonic for remappers.
I'm flexible on those - they were space filler and I felt the mnemonic would be helpful. If they're going to be 'anything or blank' I'd just as soon have them as currency symbols. I'm flexible on this, though and could live without them.
- labeled keys for USB/3G and WiFi/BT seem like a bad idea, since there is probably more hardware stuff we want to have toggles for, while the toggles we think about now might turn out to be irrelevant (e.g. USB may not use any power when not in use, so no reason to toggle it). I prefer my solution of having one 'hardware settings' button that shows an overlay menu (implemented in (low-level) software).
Overlay menus work fine at the OS level, but when you're in a full screen application can be cumbersome. Having the radios and ports on switches read at the OS level, though, makes them easy to change even while in an application without disrupting the application. I.e. if you're knee deep in a game on an emulator and want to increase the screen brightness or disable the radios to eek out the last hour of juice, you can adjust without leaving the application layer.
- in my experience, Ctrl and Alt lock is something you never need, and which is annoying if you accidentally enter it.
It was something novel that I came up with and has specific applications in playing some FPS and RPG games that use normal, shift+, Ctrl+ and Alt+ 1-0 and/or F1-F12 to control weapon or spell selections and the like. It means that the user can select each 'bank' of controls in the games and have it 'stick' until they change it further. Since we have 2 Alt, 2 Ctrl, 2 Shift and 2Fn (or whatever) keys, pressing both at one time has a consistent shift+shift = 'Caps Lock' type experience.
Give it a 'mental try' and I suspect you'll like it.

- What is the normal function of START/SELECT/PAUSE (without Fn)? Which button would you use to "show the Start menu" (the 'Pandora' button)?
What codes to the normal functions of those keys generate on a Pandora? I'm assuming 'Pause' is the same as a 'normal keyboard' Pause key. But Start and Select - I have no idea what the Pandora is sending back to the OS for those.

Wb: Well you are still without mediabuttons when the lid is open. Its conventient to have that.
That gives me an idea... Instead of all of the currency symbols on my unused Fn+number keys, I could map in the media player keys. With the FnLock concept, they could even be held top-line if the user chose to. Good or bad idea?
 
Last edited by a moderator:
  • Like
Reactions: szr
Please remember that ED must read this thread to make a decission. And I doubt he has time to read the whole Thread so please compress all the colleted arguments, ideas and facts in one short post so that ED can decide and move forward!
 
I would to ask for a wee bit of clarification concerning caps-lock on the Pyra. There seem to be two different versions floating about, caps-lock like it behaves on a full-size keyboard (which only affects letter keys, but not number and symbols) and shift-lock, which is as if the shift key is being held down (and also what many smart phones and tablets [arguable incorrectly] refer to as caps-lock.)

It seems like most samples I've seen, like Grench's above, seem to be of a shift-lock variety, which frankly might be more useful than a traditional/real caps-lock given the smaller keyboard. On the other hand, there might be some games or programs might be expecting a real caps-lock key, though I can't presently think of any (where it can't be changed.)

Do I assuming correct that in most cases that it is in fact a shift-lock and not a real caps-lock?
 
Saber:

- How do you solve the three shift problem? Do you make the two keyboard shifts both look like a LeftShift, so they cannot be distinguished?

- Same remark as above about the 'hardware toggles'.

- Is AltGr+N a dead acute accent? A bit weird to have dead acute labeled but none of the other diacritics.

- Why a dedicated AltGr key for § and µ? Don't seem to be important symbols to me.

- The layout is German-centric with äüöß labels.
Left Shift is below Tab and Right Shift is on both L2 shoulder and nearby the Enter key. Both Right Shifts are indistinguishable from one another, but if Askarus has his way and Compose is on AltGr + Spacebar, then your postulation to make both keyboard keys Left Shift sounds like a good plan. :)   

 

Not sure what you meant by “same remark as above about the ‘hardware toggles’. I presume you want to know if any Shift key will alter their function? The answer is it doesn’t matter which Shift key you press with the hardware toggles. They all will work uniformly with those four keys. Left Shift or Right Shift with screen brightness controls both toggle the keyboard backlights.

 

Acute diacritic is the only “native” dead key. Only AltGr + n is needed. Admittedly, I’m unware of how Acute behaved on the Pandora. Was it also a dead key? The other dead keys I’ve listed do require Shift + AltGr to activate them. As I’ve said previously, the user could custom map more dead keys over the German vowels or Micro/Section Sign if they want.

 

Section Sign is a carryover from the Pandora’s keyboard. Micro was asked for by ED to be included. Both are as useful as new tires on a car with no engine, but they are expendable placeholders should the individual want to remap over them without interfering with the other keys.

 

Indeed, this is a German-centric-like keyboard.  

 

I would appreciate it next time if you, or others, don’t wait to bring any issues you discover to the forefront right away
I didn't notice it until just now.
Whatever AltGr and Right Alt share between them on other keyboards, on the Pyra, they will not share the same keycode
In that case, the AltGr would need to emit a right-alt keycode when pressed, but then how does it differentiate from the actual alt key?
While I have you here, is there anything positive you have to say(about v2)?
I'd keep caps lock off the tab. Way too much CHANCE OF SOMEONE ACCIDENTALLY YELLING at someone in IRC or on a forum or whatever, anywhere you're likely to press tab at all.
On a personal opinion, if you don't like Grench's shift-fn layout then I'd at least try to maintain some semblance of layered order. If "{" is on "W", put "[" below it on "A" instead of nesting them, know what I mean? Rearrange the punctuation into the middle two rows and the extra language ones into the bottom row. 'Cause as long as they're "not where they're supposed to be" they may as well be more conveniently not where they're supposed to be.
So sorry, I thought you noticed my previous "DOSBox unfriendly" layouts.  :p

 

To address your post...

 

Why would our AltGr on the Pyra produce the same scancode as Right Alt on the Pyra? On a standard keyboard, they may(Linux too?) have identical codes but different behaviors, but on the Pyra they certainly won’t. Personally I don't care what we call it but maybe we should drop the Alt part of the name be unique and call it the Grrrr key?  ;)

 

I moved CAPS Lock to AltGr + Tab so we don’t have a mod value for Shift. Here I endeavored for people not to worry about whether either Shift or AltGr have to be pushed first, if we do this combination for another level of keys(like for the quirky DOSBox). Besides all that, a sane person should I hope know when they are in CAPS Lock mode. 

 

The brackets are nested, as their termed, because that’s how they appear on a German keyboard. We could split them though between rows, but then where do we place the = - + _ symbols, which were asked to be closer to the edge? We can't steal from Peter to pay Paul. As ED wanted, we have to perpetuate a balance between coders and non-coders. Placing matched pairs near one another on the same row I’ve been told is less jarring than when they’re on different levels.

 

I’m not sure I understand how you want the umlauted vowels. With the shoulder AltGr it isn’t an issue, but using the device with AltGr in the bottom right corner would demand keys frequently pushed be ergonomically toward the opposite corner. While the German characters are consequential for some, the majority would rather the essentials get the best spots(the device’s left half side) without dependency on the L2 trigger which I've avoided in my layouts. B)      

 

Wb: Well you are still without mediabuttons when the lid is open. Its conventient to have that.

Saber: This is the post where you decided to go back to the thread that i left because it didnt explain any of the changes made, and didnt answer questions.

Also, as has been said over and over, its really hard to visualize something presented in divided form ASCII.

This is the post that you can answer.
If your question is what does Right Alt do then my answer is it doesn't do what AltGr does. One is a railway conductor while the other is a diplomat. 
 
Last edited by a moderator:
My question is this, why isnt "R-alt" just named "Alt" Im guessing there is something i dont know.

Edit: Also you havent explained your rationale at all. The problems I posted are real.
 
Last edited by a moderator:
Please remember that ED must read this thread to make a decission. And I doubt he has time to read the whole Thread so please compress all the colleted arguments, ideas and facts in one short post so that ED can decide and move forward!
On this forum? You know we never do anything shorthand here. :)   

I would to ask for a wee bit of clarification concerning caps-lock on the Pyra. There seem to be two different versions floating about, caps-lock like it behaves on a full-size keyboard (which only affects letter keys, but not number and symbols) and shift-lock, which is as if the shift key is being held down (and also what many smart phones and tablets [arguable incorrectly] refer to as caps-lock.)

It seems like most samples I've seen, like Grench's above, seem to be of a shift-lock variety, which frankly might be more useful than a traditional/real caps-lock given the smaller keyboard. On the other hand, there might be some games or programs might be expecting a real caps-lock key, though I can't presently think of any (where it can't be changed.)

Do I assuming correct that in most cases that it is in fact a shift-lock and not a real caps-lock?
On my layout, CAPS Lock is reserved only for the letters. AltGr is the only other lock key. Too much mode overlap with Shift Lock, Control Lock, Alt Lock.  
 
Nono, R.alt here  its one of the shoulders.

I guess my follow-up question is: why is there no visual clue as to the button named start also being alt?

To quote ED:
 

And be rational - there is NO layout everyone loves. What we need to find is the best compromise for all users and usecases.
I dont see how you could exclude more users, and you arent answering any questions. But you are requesting feedback.

Edit: When will the layout reach finality. It has changed in versions 2c already, which is kind of strange since ED has announced the final cutoff for months now.

"I think I'm almost nearly finished." doesnt really look like you are committing to anything.

So you point to ED, and ED asks us to question your layout, and then you don't answer...

Edit2:  ED says this: "

  • The main languages used where the Pandora sold are English, French and German. It should support these languages as good as possible (with English being the main one)"
You say this:

"Indeed, this is a German-centric-like keyboard. "

 

What about french?

 

Or any of the places without official sales-places. It isnt very far fetched to suggest pandora sold way less than it could in non-english places because it had such a lacking keyboard.


Edit3: This is something we dont have to repeat.
 
Last edited by a moderator:
Nono, R.alt here  its one of the shoulders.

I guess my follow-up question is: why is there no visual clue as to the button named start also being alt?

To quote ED:

And be rational - there is NO layout everyone loves. What we need to find is the best compromise for all users and usecases.
I dont see how you could exclude more users, and you arent answering any questions.
I'm sorry and I don't mean to make you feel excluded but I don't know what questions you want answered. If we are talking about why R2 isn't called just "Alt", then it is because Left Alt is the Start button and I want the difference between them to be known, like Right Shift on the shoulder button. My rationale though is to create a usable layout for most, nothing less than that.    
 
Last edited by a moderator:
Nono, R.alt here  its one of the shoulders.

I guess my follow-up question is: why is there no visual clue as to the button named start also being alt?

To quote ED:

And be rational - there is NO layout everyone loves. What we need to find is the best compromise for all users and usecases.
I dont see how you could exclude more users, and you arent answering any questions. But you are requesting feedback.

Edit: When will the layout reach finality. It has changed in versions 2c already, which is kind of strange since ED has announced the final cutoff for months now.

"I think I'm almost nearly finished." doesnt really look like you are committing to anything.

So you point to ED, and ED asks us to question your layout, and then you don't answer...

Edit2:  ED says this: "

  • The main languages used where the Pandora sold are English, French and German. It should support these languages as good as possible (with English being the main one)"
You say this:

"Indeed, this is a German-centric-like keyboard. "

 

What about french?

 

Or any of the places without official sales-places. It isnt very far fetched to suggest pandora sold way less than it could in non-english places because it had such a lacking keyboard.


Edit3: This is something we dont have to repeat.
May I ask why you are so worked about this? Shouldn't your concern be how the layout affects YOU Allan.

I would like your input on what you'd change, no abstracts, no metaphors, just a clear statement on what YOU want in the layout. I don't want to hear about how the French or the Slavics are misrepresented or how ED or I don't listen to the members. Tell me exactly what you need. 
 
Last edited by a moderator:
I know that there is a difference, yes, you want it pointed out, why?  What does R.alt do thats different from (L.)alt?

Yes, there is a R.shift. Why is it on the left shoulder?

That layout doesn't affect me, because i would never use it, same as the pandora, it doesnt work for me. (Not even if i type english only) Given enough keys im technical enough to hack my own, no problem about me.

What im really concerned about is "new, interested customers." The ones who feel overwhelmed if you dump a lot of "well you can just" on them.

I need exactly what ED states as goals in firstpost. My concerns are still here. Feel free to comment each and every one of those.

Edit: My other primary concern is that your layout changes an awful lot. In my head there is no reason to change something that works.

There could be very valid reasons, I just dont know about them.

If you dont want to explain anything, show the layout to someone who isn't technical, without explaining, then change it till they understand it.
 
Last edited by a moderator:
My question is this, why isnt "R-alt" just named "Alt" Im guessing there is something i dont know.
Most likely since left-Alt and right-Alt are really two distinct keys (even if they often map to the same function in many programs.) If you observe via something like `xev` you can see that left and right Alt keys emit separate codes. Also, while the left and right Alt keys usually are both just labeled "Alt" on most full-size keyboards, on a device like the Pyra, it helps to know which Alt (left or right) a key/button is. Same for Ctrl and Shift. Some programs treat each key of each L/R pair distinctly, especially in games.
 
I know that there is a difference, yes, you want it pointed out, why?  What does R.alt do thats different from (L.)alt?

Yes, there is a R.shift. Why is it on the left shoulder?

The layout doesnt affect me, because i would never use it, it doesnt work for me. Im technical enough to hack my own, no problem about me.

What im really concerned about is "New interested buyers" The ones who feel overwhelmed if you dump a lot of "well you can just" on them.

I need exactly what ED states as goals in firstpost. My concerns are still here. Feel free to comment each and every one of those.
Oh, I think I see. Right Alt on the Pyra will do the same things Left Alt did on the Pandora, Alt shortcuts. 

Right Shift is on the L1 shoulder because it was also L1 on the Pandora. Much of the software will "move" from the older machine to the Pyra so we should not change what L1, R1, Start, Select, and ABXY were assigned in order to keep the migration as painless as possible.

ED's goals are in the first post. Essentially a layout that'll be great for most and good but not perfect for everyone else.

If you don't mind, ask any questions you have in this thread. 
 
Last edited by a moderator:
So why isnt it called (Alt)? Are these all technical markings, or how you envision it being on the device?

That looks a lot like the L2 shoulder, if you want to follow the playstation-paradgimn of L1 L2 R1 R2

Do you happen to know why the right shift was on the left shoulder on the two-shoulders pandora?

If your concern is only software-compatibility, id like to know when that matters. Also id like to disagree,

most of the software library for the pandora is only in compiled form, without source-code available. And when it is,

it isnt automated.

So if i post everything as a question, you will answer?
 
Last edited by a moderator:
Why would our AltGr on the Pyra produce the same scancode as Right Alt on the Pyra? On a standard keyboard, they may(Linux too?) have identical codes but different behaviors, but on the Pyra they certainly won’t.
I'm not the one saying they will, I'm saying that that was my interpretation of what comradkingu was talking about. Ask him what he means, I'm just as confused as you are. It seems that he wants an "Fn" key in addition to a fully realized AltGr key, unless I've misunderstood. From his later responses I'm pretty sure that's what he means.
On the other hand, it looks as though AltGr does produce a different keycode from right-alt, except in SDL (and possibly other such libraries) where there are only two alt codes. So it's entirely possible for him to get what he wants with the caveat that we'd need a custom SDL.
 
A lot of the things on the pandora keyboard are highly arbitrary, like left hand extreme left shift on a two-thumb keyboard. If people actually liked what makes the pandora keyboard strange, id see a reason to keep its quirks.

Even if the pandora software is compiled form only. I imagine you mean there is a difference for native games. Not that i know of any games that rely on any such functionality, but fortunately its one of the things you can change. So if it wasnts shift, you map shift to left shoulder in game. If it wants a static keycode for left shoulder, you map your shoulder to that.

Edit: I want an unencumbered modifier. Fn is encumbered by default, it carries connotations of 1. hardware functions 2. hack f-row 3. Hack-numpad

Im not saying it doesnt send a different keycode, I fell off that argument when you said "they certainly wont". Certainly wont what? And why, if its non standard.

Printing, as it seems like you have done. L/R.alt  or  R.anything on the left side of the device, is non-standard, it looks hacky.
 
Last edited by a moderator:
Back
Top