It's the keyboard layout.


Anyways, hope you and others like them in a preliminary sort of way.  :)
Your layout keeps getting better - kudos on that!

I notice you've gone a long ways toward better DosBox compatibility.  There is still some breakage though.

DosBox is going to expect every character that is in a shifted position on a 'normal' keyboard will still be paired with it's un-shifted companion.

So, there are examples like ;: that should be paired but are not.  Unfortunately this becomes a problem unless...

Like or hate my design, I may have struck on something useful in applying the shifted version of Alternate/Fn mappings.  You -could- place the : on shifted ;.  : would be altgr+shift+> then.

Give it some thought?  Fixing just a few of these would enable DosBox compatibility.
 
Anyways, hope you and others like them in a preliminary sort of way.  :)
Your layout keeps getting better - kudos on that!

I notice you've gone a long ways toward better DosBox compatibility.  There is still some breakage though.

DosBox is going to expect every character that is in a shifted position on a 'normal' keyboard will still be paired with it's un-shifted companion.

So, there are examples like ;: that should be paired but are not.  Unfortunately this becomes a problem unless...

Like or hate my design, I may have struck on something useful in applying the shifted version of Alternate/Fn mappings.  You -could- place the : on shifted ;.  : would be altgr+shift+> then.

Give it some thought?  Fixing just a few of these would enable DosBox compatibility.
DOSBox compatibility has always been a pervasive problem when designing a layout as you know. I'm not an expert with the emulator, but would switching both ; and : to shifted values and < > to AltGr values make any kind of difference in the right direction? What about simply swapping colon's position with the question mark?

Another idea I've posted before was to trick DOSBox somehow into thinking semicolon and colon are mirrored as well to Fn/AltGr + n, m but I don't know how feasible this is.    
 
Last edited by a moderator:
Saber, where did you get "AltGr + u, i, j, and k could theoretically be mapped(or not) as umlaut, circumflex, grave, and acute dead keys" from? I have never seen that on any keyboard.

Are you aware that AltGr+ u i j k does something else, at least regionally?  altGr+u=↓    altGr+i=→  altGr+j=ɗ   and  altGr+k=ĸ     j makes dead-keys like this: ʂʠⱳƭ 

Grench: ": would be altgr+shift+>"   Am i understanding correctly that you want altgr+shift+a button to produce :    ?

I'm not well versed in dosbox, but non-US/UK keyboards dont have ; and : on the same key. Dont they work in dosbox?
 
Last edited by a moderator:
Saber, where did you get "AltGr + u, i, j, and k could theoretically be mapped(or not) as umlaut, circumflex, grave, and acute dead keys" from? I have never seen that on any keyboard.

Are you aware that AltGr+ u i j k does something else, at least regionally?  altGr+u=↓    altGr+i=→  altGr+j=ɗ   and  altGr+k=ĸ     j makes dead-keys like this: ʂʠⱳƭ 
What I mean is ED could remove the umlauts from the layout in the first post and place dead keys for umlaut, circumflex, grave, and acute at AltGr + u, i, j, and k. More likely though he'll keep the German umlauts on the keyboard and let the Pyra's owner customize their individual layout by remapping to their own needs. 
 
Just for the curious, here is the diff of my qemu change to make it compatible with the Pandora keyboard (with still the printf I used to debug in comment)...

Code:
diff --git a/ui/sdl.c b/ui/sdl.c
index 94c1d9d..75a53a8 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -284,8 +284,128 @@ static void sdl_process_key(SDL_KeyboardEvent *ev)
 
     if (kbd_layout) {
         keycode = sdl_keyevent_to_keycode_generic(ev);
+//printf("keycode=0x%04X (keymaped from 0x%04X)\n", keycode, ev->keysym.sym);
     } else {
         keycode = sdl_keyevent_to_keycode(ev);
+//printf("keycode=0x%04X (from 0x%04X)\n", keycode, ev->keysym.sym);
+    }
+
+    static int pando_lshift = 0;
+    static int pando_rshift = 0;
+
+    /* Special Pandora cases */
+    switch(ev->keysym.sym) {
+        case 0x0039:  // [
+        case 0x0030:  // ]
+             if (modifiers_state[0x2a]|modifiers_state[0x36]) {
+                if (ev->type == SDL_KEYDOWN) {
+                    // invert shift status
+                    pando_lshift = modifiers_state[0x2a];
+                    pando_rshift = modifiers_state[0x36];
+                }
+                if (pando_lshift)
+                    qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYUP);
+                if (pando_rshift)
+                    qemu_input_event_send_key_number(dcl->con, 0x36, ev->type == SDL_KEYUP);
+                if (ev->keysym.sym==0x0039)
+                    keycode = 0x1a;
+                else
+                    keycode = 0x1b;
+            }
+            break;
+        case 0x0032:
+            if (modifiers_state[0x2a]|modifiers_state[0x36])
+                keycode = 0x1a; // {
+            break;
+        case 0x0033:
+            if (modifiers_state[0x2a]|modifiers_state[0x36])
+                keycode = 0x1b; // }
+            break;
+        case 0x0034:
+            if (modifiers_state[0x2a]|modifiers_state[0x36])
+                keycode = 0x29;  // ~
+            break;
+        case 0x0022:    // "
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x28;
+            break;
+        case 0x005F:    // _
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x0c;
+            break;
+        case SDLK_AT:
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x3;
+            break;
+        case SDLK_EXCLAIM:
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x2;
+            break;
+        case SDLK_LEFTPAREN:
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x0a;
+            break;
+        case SDLK_RIGHTPAREN:
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x0b;
+            break;
+        case SDLK_COLON:
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x27;
+            break;
+        case SDLK_QUESTION:
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x35;
+            break;
+        case SDLK_HASH:
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x4;
+            break;
+        case 0x007c:    //|
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x2b;
+            break;
+        case SDLK_DOLLAR:
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 0x5;
+            break;
+/*        case 0x0031:
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            keycode = 167;   // § => § (doesn't exist on keyboard)
+            break;*/
+        case SDLK_PLUS:
+        case SDLK_ASTERISK:
+        case SDLK_AMPERSAND:
+            qemu_input_event_send_key_number(dcl->con, 0x2a, ev->type == SDL_KEYDOWN);
+            break;
+        // special case for Omapdss controls...
+        case 0x111: //up
+            if (keycode==0xb7) keycode=0xc8;
+            break;
+        case 0x112: //down
+            if (keycode==0x00) keycode=0xd0;
+            break;
+        case 0x114: //left
+            if (keycode==0xb8) keycode=0xcb;
+            break;
+        case 0x113: //right
+            if (keycode==0xc6) keycode=0xcd;
+            break;
+        case 0x116: //(A)
+            if (keycode==0x00) keycode=0xc7;
+            break;
+        case 0x117: //(
+            if (keycode==0x00) keycode=0xcf;
+            break;
+        case 0x119: //(X)
+            if (keycode==0x00) keycode=0xd1;
+            break;
+        case 0x118: //(Y)
+            if (keycode==0xb5) keycode=0xc9;
+            break;
+        default:
+            break;
+            // nothing
     }
 
     switch(keycode) {
@@ -315,6 +435,7 @@ static void sdl_process_key(SDL_KeyboardEvent *ev)
         return;
 #endif
     }
+//printf(" => keycode=0x%04X\n", keycode);
 
     /* now send the key code */
     qemu_input_event_send_key_number(dcl->con, keycode,
 
DOSBox compatibility has always been a pervasive problem when designing a layout as you know
It's not just DosBox compatibility, Grench's idea solves the DosBox issue (and the QEMU issue that I wasn't aware of) while simultaneously putting keys where most people familiar with a "US Standard" keyboard will find them. That is, : is shift ; just like it is on a full sized keyboard, etc...
 
Last edited by a moderator:
http://www.freedos.org/software/?prog=keyb

http://www.freedos.org/wiki/index.php/Keyb

http://www.vogons.org/viewtopic.php?t=21824

Glad it can be solved. In my head a real keyboard has a <> button. Its the one extra button on ISO-keyboards. Placed to the left of Z.

I have used an american keyboard too, and i must say longshift on 10finger is nice.

Anyhow, putting <> ( ) and [] {} together seems like an obvious fix that the keyboard evolution put in strange places.
On my early layouts I had paired up like symbols and grouped 'like keys' as well - not realizing the chaos that it would cause in DosBox or as we realize now in QEMU as well.  It gives an aesthetically pleasing and very intuitive result.  However, I know now that it was an abject failure.

When the DosBox issues were brought up here, that's when I went back to the drawing board to develop a completely new solution that maintained the integrity of the key pairs while still fitting in the confines of the Pyra's physical layout.  I literally went into the keyboard tool site and blanked all of the keys and started fresh.  That led me to the Fn and Fn+shift alternative for key mappings.  It maintains the pairing from a standard US/UK keyboard and results in more 'keys' than we really needed to define symbols for English, German, French and Spanish.  Unfortunately it means that those non English characters had to move to non-standard locations - as the standard locations are seemingly spread at random.

Yes, language support for non English users is a bit of a compromise.  However, as ED stated, English is the priority, but other languages DO need to be taken into account and be able to function.  That was my objective - and still is.

So, I created what I hope is a DosBox friendly US layout then added the additional symbols that I understood to be needed for additional language support in the 'unused' positions giving preference to German, then French and finally Spanish.  It all started to click together.  Since the additional non-English language symbols are in non-standard positions, I feel it is important for them to be marked as such on the keyboard.

In the end I had positions for additional symbols blank (center number keys) that I figure people can re-map to whatever they want.  It is a lot easier to remember that, 'I mapped symbol Foo to the key with the Bar symbol' than it is to remember 'I mapped symbol Foo to the 2nd blank key's Fn+shift position'.  So, for usability, having some symbol there by default is better than none, even if the end user has no interest in typing the given symbol.

For those who are skipping the vast majority of this thread or don't want to scroll back to figure out WTF I'm talking about:

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

Hope this all makes sense.  Even if my layout is not used in the end, I hope that the ideas I found help.  I know I've learned a lot in this process.
 
  • Like
Reactions: szr
There is nothing standard about fn+shift, and nothing usable about the way you include letters for German and Spanish, nor the partly covered Danish/swedish/norwegian.

Cant figure out how to type French, but I do know how a french keyboard works, dont know if that will help me.
 
Last edited by a moderator:
My latest layouts are in my signature.
 
Last edited by a moderator:
  • Like
Reactions: szr
There is nothing standard about fn+shift
So? There's nothing standard about the Pyra at all, really, or at least its keyboard. There aren't enough keys to do anything standard. We are necessarily going to need to do non-standard things with, keys are going to have to be placed in non-standard ways. There's literally no standard that we can follow for this situation, we are forced to create our own standard.But just because there aren't any standards that we can follow 100% doesn't mean we can't learn from them. English standard keyboard says "shift"+";" = ":" so if we have to put ";" as an altgrfnmetamod key then I can't think of any reason not to make "shift"+"fn"+";" = ":".
 
(Fae: Its the one with ⌦ on it, you are pardoned. Taking into account how small that button is, its very hard to implement, making it even harder to see in reality. Adding a C to it, or Z+Ins for the other one, makes for low visual clarity)

WizardStan: Besides the call to authority of referencing the english keyboard _standard_ in this case, which adds confusion, the reason i can think of not to do that is because

  • english/US keyboards dont do shift+ and something else+  to type  [ ]  and { }.

They especially dont use fn to type the latter part of each. In no uncertain terms does any keyboard layout not mix fn with altGr.

  • Fn is a concept earlier mentioned to be a hardware modifier, and more importantly is a known key that does something else entirelly.

Further creating problems,

  • altGr is a known key, and does something else when typed along with the combo described.

If you want to do it, call the button hack, because thats what it is. There is, in this case, zero reason to do so, and it can be avoided. Blaming lack of keys for adding more ugliness is a slippery slope.

Talking about standards and then breaking them makes no sense. Adhere as strongly to standard as possible, where standard is majority, or a combination of mass. Not new inventions under the cover of being functionally proven and known to work.
 
Last edited by a moderator:
This is a wall but I'm being more verbose than usual because it seems like you're missing something in what I'm saying.

english/US keyboards dont do shift+ and something else+ to type [ ] and { }
Standard keyboards don't do <ANYTHING>+<something> to get "[" or "]". There aren't enough keys for dedicated [ and ] so we will NECCESSARILY have to put those (or if not those exact keys than some other "standard" keys) behind altgrfnmetamod combo. Standard english/US keyboards don't do altgrfnmetamod+<anything> to produce a single keycode either yet that's what we need to do. Your argument here is irrelevant.And I addressed it already anyway, since we CANNOT have dedicated [ and ] (or if we can for those two keys, something else WILL suffer and you can just mentally swap in those keys in this argument and it'll mean the same thing) and we WILL need to put [ and ] on altgr keys, then if you want to stick as close to the English keyboard standard then it actually makes MORE sense to have "shift"+<whatever> to get as many of the standard English shifted keys as possible, even if <whatever> is itself an altgr key combo.

They especially dont use fn to type the latter part of each. In no uncertain terms does any keyboard layout not mix fn with altGr
We're using AltGr and Fn interchangeable because whatever the Pyra's key is will in fact not really be either. It is not a full on hardware key like a standard Fn you find on a laptop, nor is it just a right alt modifier as the AltGr is on a full sized keyboard. It is a "do the thing that needs to be done" key. If you are getting confused by this and cannot separate the AltGr of a full sized keyboard with what the Pandora NEEDS the key to do then I suggest you stop calling it that. This argument here is also irrelevant.
altGr is a known key, and does something else when typed along with the combo described
As has been mentioned many, many times, the Pyra's AltGr key CANNOT UNDER EVERY CIRCUMSTANCE behave the same way as a full sized keyboard's AltGr. There are a few cases where we may be able to map the keys correctly, and in those situations the algrfnmetamodwhateverwecallit key plus those combos can be made to spit out "right-alt"+"whatever", but for the vast majority of keys it will, definitely, need to be treated more as an Fn key, where pressing it in combo with another key changes the scan code.It needs to be like that, it cannot be any other way. We can't, for example, press "altgr"+"U" and expect the software to realize that "right-alt"+"U" means "F8". No, when we press "altgr"+"U" it needs to output the F8 scancode. It can ALSO output some new scancode which is unique to the Pyra, an "altgrfnmetamodwhatever" scan code, but most software is going to ignore it. This argument is also irrelevant.

edit: In fact, this argument is just further evidence that we shouldn't call it AltGr, that ED made a mistake when he said he wanted one. He didn't know the technical details, and perhaps in theory it sounded nice, but the technical details are what are preventing it from being fully realized: accept the flaw, scrap that idea and use something else.

edit edit: More to the point, the Pyra WILL ALREADY HAVE AN ALTGR key. In every layout there has always been two Alt keys, one on the keyboard and one on the triggers. One of them will be left-alt, the other will be right-alt. The one that is right-alt will already behave identically to a standard full sized keyboard.

Talking about standards and then breaking them makes no sense
I disagree. Talking about standards and HOW WE CANNOT FOLLOW ANYTHING 100% and then providing examples of how we can follow a standard as closely as possible to avoid confusion makes perfect sense.
Adhere as strongly to standard as possible, where standard is majority, or a combination of mass. Not new inventions under the cover of being functionally proven and known to work.
We MUST, absolutely, no question, without a single doubt, invent something new. There is no standard, none, zero, zilch, nada, nothing like this has ever existed in such a way that we can use. Period, no debate, absolute truth. Start with that. Can we agree to this? That there is no standard that we can apply one-to-one? If we can't agree to that then you are living in a world that I can't even imagine and the debate needs to end right now, we will never reach an agreement and the best thing is to just lay out the arguments side by side, independently, and let EvilDragon decide.If you can agree with that, if you do see that there is no standard we can fully use, that we will need to invent something in order to get it to work, then take a closer look at what I've been saying.

My argument is that Grench's layout DOES adhere as closely to English keyboard layout standards as possible. He may have "{" tucked behind "shift"+"fn"+"J", but that's only because "[" is on "fn"+"J". "shift"+"[" is "{", so if "[" is "fn"+"J" then it MAKES SENSE AND ADHERES TO THE STANDARD that "shift"+"fn"+"J" be "{". If you do not agree that it makes sense then you will have to come up with a counter argument that doesn't depend on the artificial belief that we can't use "shift"+"fn" because "that combo doesn't exist on standard keyboards". Of course it doesn't exist, standard keyboards have enough keys.
 
Last edited by a moderator:
In that wall of text I realized something but it's worth pointing out in its own post, regarding the AltGr key.

The AltGr key is, literally, right-alt. When you press AltGr on a full sized keyboard plus any other key you are, in fact, sending the scan codes for "right-alt"+"whatever". It is not generating a new scan code and for that reason we cannot use it that way, we must, at least in some cases, use it in the Fn sense where it actually changes the scancode being produced.

That being said, every layout I've ever seen for the Pyra already has an AltGr, even the ones that have labeled the "magic-do-the-thing" key as Fn or Meta or Mod. You see, every layout has had two alt keys. Presumably one of them is "left-alt" and the other is "right-alt". "Right-Alt" is AltGr. That is it. Right there, there's your AltGr key. It's on the shoulder or it's on the keyboard, or if we really want we can get rid of the SysRq and ScrollLock and replace them with the Pandora's CTRL and ALT for a total of three alt keys and you can decide which one will be the left and which will be the right later.

Just pick which Alt key, of the two, you want to be AltGr and change the name. That solves all the consufion problems: it becomes an AltGr key that does exactly what it does on a full sized keyboard without sacrificing anything. We are then free to label that "magic-do-the-thing" key in the lower right (usually they're lower right, has anyone put it on the left? Whatever) whatever we want.

Call it mod, or Fn. Not AltGr because we've already established that it cannot behave like a keyboard AltGr, we already have an AltGr in the form of a "right-alt" key, and some people are getting confused over it. I also wouldn't recommend "meta" because that might get confused with ctrl. And it seems some people get confused with the existing "Fn" keys on laptops.

How about we stick with "Mod"? Does that key already exist in a way that would cause confusion? That properly describes what it does, it "modifies" whatever you're hitting next in some way, the way of which is typically described on the keyboard itself.
 
Last edited by a moderator:
  • Like
Reactions: szr
As stated, AltGr on the Pyra will not behave like the user's AltGr but it should be called "AltGr". I don't believe ED made an error in selecting AltGr over Fn or Meta. His choice allows there to be two AltGr's, one on the L2 Shoulder and the other on the keyboard. The default, shifted, and third level modifier are enough. Underneath there will I assume be a Shift + AltGr fourth level for the umlaut capitals, and this is where we can "hide" some symbols which don't play nice with DOSBox/QEMU if we have too. Really no need to panic over this by making a mountain range out of an ant hill. 

Also,  I like some of Grench's layout and his efforts but , and . shouldn't be concealed under modifiers. 
 
Back
Top