Two keyboard layout questions


Pyramancer

Fairly Idle Member
Joined
Feb 4, 2017
Messages
232
Age
124
I'm slightly confused about the current final plan for the keyboard layout. Specifically I have two questions:

1. In the Pyra video, and also on the keyboard page of the wiki (https://pyra-handheld.com/wiki/index.php?title=Keyboard) sometimes the alt and ctrl keys between the nubs seem to be on the main keyboard plane, and sometimes they seem to be on the Fn-shifted plane. Are they Fn-shifted (or are they not Fn-shifted) in the current final version?

2. Where is the Fn key? (I mean the shift key that gives the orange symbols.) On most of the images that I've seen it's clearly labelled in the bottom right corner of the keyboard, but on the wiki page in the image labelled "Pyra Mainboard V5.x Keymat" (which I assume is the latest?), I can't find it at all. What am I missing?

Thanks!
 
1. Alt and Ctrl are not shifted. they are just that, it's labeled start and select, but if it's like the Pandora there really is no start and select it's really just Alt and Ctrl. Perhaps a joystick button mode could be made that would make it act like joystick buttons, but the Pandora never got that treatment. Also the shoulder buttons act as Left or Right Alt and CTRL... I need to dig up some more details.

2. it should be right in the right hand corner like all the pictures show. plans were to make one of the Shoulder buttons act as an FN key as well, which I'm sure will be configurable.

Edit: Follow up, found the page you were looking at LMETA is the FN key as well as RMETA on the shoulder. that is showing the mapping not what it actually says on the keys.
 
On that page there is a keymat with Blue Meta layer - that is a Pandora keymat.

The ones with the Orange Fn layer are the Pyra keymats.

I floated the idea at one point to scrap the "Start" and "Select" labels and just/only call them Alt and Ctrl and was promptly told how I'm clearly not a gamer because gamers use those buttons even though there are hardly any native or Linux games actually mapped to use them though emulators use them sometimes so the labels may as well be there as they are simply ink that is not there so the light comes through and not causing any harm other than people not understanding that they are truly modifier buttons and not actually two different layers mapped to the button which would be silly to do to a modifier button right?

Yes, I really was trying to see how long of a run-on sentence I could create without becoming too repetitive.

It has been a long time since the keyboard threads completed. I can't recall off the top of my head whether it is the left modifiers or the right modifiers that are on the shoulders vs the main keyboard area. But - the left/right versions are held together shoulders+lidswitch/keyboard+PyraLogoKey.

The modifiers are all 10 on dedicated keys though. They are:
Shift, Alt, Ctrl, Fn, on the shoulders + Super as the lid switch hall sensor (Right versions I think)
Shift, Alt, Ctrl, Fn, on the keyboard area + Super as the Pyra logo key (Left versions I think)
 
Last edited:
The diagram under the heading 'Software assignment by the Linux kernel' suggests the shoulder buttons are the equivalent of the right hand modifiers on a full-sized keyboard. Right Shift and Fn on the left two shoulders and right ctrl and alt on the right hand two - I'm not clear yet which button is going to be L1 and which will be L2 but I think the diagram suggests that shift and ctrl will be on the lower/outer pair, and FN and alt on the inner/upper pair, left before right respectively. So your recollection was correct.

However, on that diagram the power button is labelled POWER and the lid switch as SW_LID, not LEFT/RIGHT SUPER, so I'm not sure they'd normally be considered as modifiers. IIRC my xmodmap stuff rightly, you can define almost anything as a modifier though.
 
If there will be xkbset and keymap editing, everything could be configurable, even for productivity applications.
Xkbset for sticky keys support, speeds up thumb-typing on small keyboards.
Then all regional/characteristic/frequently used keys may be configured by just keymap editing. If there would be possibility to swap some modifier with e.g. Compose key (swap keycodes?) then it will be a really fast thing to type on.
 
1. Alt and Ctrl are not shifted. they are just that, it's labeled start and select, but if it's like the Pandora there really is no start and select it's really just Alt and Ctrl.

Ah, I see.

So is the current final version the one with "Start" and "Select" written larger and "Alt" and "Ctrl" written in smaller text underneath, or the one that has "Alt" and "Ctrl" written in a larger font? Not that it really makes any difference; just curious.

they are truly modifier buttons and not actually two different layers mapped to the button which would be silly to do to a modifier button right?

Well, it would certainly have been a bit awkward if one had had to press two modifier keys to get alt and ctrl. (I spend a majority of my computing time in Emacs where those two keys are pretty important.) But I see that alt and ctrl are also on the shoulder buttons, which I suspect is going to be pretty awesome.

In fact I might not even use the two buttons in the middle if I always type on the Pyra with my thumbs -- have to see how it fits in my hands. (On my 200LX I only typed with my thumbs when I was standing up; when I was sitting at a table I typed fairly normally. If that's possible with the Pyra (probably not?) that is when the middle alt and ctrl would come in to play.

I had assumed that the Fn key would be done in hardware. Had that been true, then using Fn to get alt and ctrl would have been plausible, albeit somewhat horrible. But I think what I'm hearing is that Fn is going to be a true modifier key to GNU/Linux -- "meta" IIUC. That is very good. I think. Maybe.

Yes, I really was trying to see how long of a run-on sentence I could create without becoming too repetitive.

Nice. I was going to do likewise in this post but I have to rush to catch a train so everyone reading this is spared.
 
Good spot - I'd not noticed that one graphic with 'Start' and 'Alt' swapped over. As far as I can tell that was simply a mistake made in preparing the keyboard graphic for the renders of different coloured cases people were making. At least the prototype from last year has 'Start' as the main lettering with 'Alt' below it, as it was on Pandora: http://cloud.openpandora.org/index....tures/Prototype&files=Proto-ControlsClose.jpg
 
However, on that diagram the power button is labelled POWER and the lid switch as SW_LID, not LEFT/RIGHT SUPER, so I'm not sure they'd normally be considered as modifiers. IIRC my xmodmap stuff rightly, you can define almost anything as a modifier though.

Mmmm... you got a bit confused there.

I think that the power button is a dedicated interrupt to the SoC. It is not a modifier and it is not duplicated to the shoulders.

The DP dp logo key at the bottom of the center key stack is left super. Think 'Windows Key'. It is a modifier key. The lid switch will hopefully map as right super.
 
Mmmm... you got a bit confused there.

I think that the power button is a dedicated interrupt to the SoC. It is not a modifier and it is not duplicated to the shoulders.

The DP dp logo key at the bottom of the center key stack is left super. Think 'Windows Key'. It is a modifier key. The lid switch will hopefully map as right super.

Ah yes, I must have been mistaken. I see the bottom of the center stack, although I'll note it's actually labelled 'MENU' which I assume is the windows menu key, rather than the windows super key. That diagram's labelled 'default mappings for v5.x' and labels the shoulders things like 'RIGHTSHIFT' and 'RIGHTMETA' so I assume the menu button was the intended mapping then. That may have changed already, but it suggests neither it or the lid switch were the conventional super key, although as I noted before, I think it wouldn't stop you mapping them however you wanted to, even as modifiers.
 
Ah yes, I must have been mistaken. I see the bottom of the center stack, although I'll note it's actually labelled 'MENU' which I assume is the windows menu key, rather than the windows super key. That diagram's labelled 'default mappings for v5.x' and labels the shoulders things like 'RIGHTSHIFT' and 'RIGHTMETA' so I assume the menu button was the intended mapping then. That may have changed already, but it suggests neither it or the lid switch were the conventional super key, although as I noted before, I think it wouldn't stop you mapping them however you wanted to, even as modifiers.

Completely ignore the labels Start, Select and Menu unless you're knee deep in an emulator that someone has bothered to set up to use them that way. When you boot into Linux they will be left Alt, left Ctrl and (left?)Super. Fn and Shift are in the lower right corner to round out the on-keyboard area set of modifier keys.

In the keyboard threads we had discussed the values of having the lid switch activate as right Super. I'm not 100% sure if that is how it will ship, but I plan to try to set mine up that way.

The only key that cannot really be remapped is the Power key. It appears to feed directly into 'Palmas' - i.e. the SoC chipset without passing through the keyboard controller hardware.
 
Completely ignore the labels Start, Select and Menu unless you're knee deep in an emulator that someone has bothered to set up to use them that way. When you boot into Linux they will be left Alt, left Ctrl and (left?)Super.

That's what I mean; the graphic is documenting keycodes, not the legend on the keys. And the keys would have been recognised (on v5 boards at one point on time at least) as LEFTALT, LEFTCTRL and MENU. That's not the same as Super_L, the keycode that xev reports on this laptop when I press the super key (this keyboard only has one). This keyboard reports a keycode of 'Menu' when I hit the menu key instead.

Now, on this machine the super key does nothing while the menu key is equivalent of me right clicking the mouse (in this browser, but it seems to behave differently in different apps), but I guess you need to bind a key to a super key in this setup, which I've simply not bothered to do for now. Debian probably works differently to this build-your-own Arch environment. I assume on the Pyra's drop of Debian that key, whatever keycode it actually reports, will work to open the main menu.
 
Back
Top