Unofficial Keyboard Layouts

[Antartica]

I don't see how it would work without having a Fn key.

If I'm not mistaken, the pyra will have in the order of 60-62 available keys (45 at the bottom, 4 from dpad, 3 from the middle buttons, 4 or 6 from the "fire" buttons, 4 from the shoulder buttons).

A standard international keyboard has 105 distinct keycodes (at the driver level). There is a  "bare-minimum" number of keycodes a keyboard needs to have: a-z,0-9,shift,space,tab,esc,enter and backspace (that is 26+10+6=42). That leaves us 18-20 keys in the pyra to use to generate the other 63 keys (105-42). Those 63 keys are the F1..F12, the normal PC modifiers (control, alt, altgr), symbols (dot, questionmark, etc), cursors, keypad, the home/end/... block, etc. There is some redundancy there, but not much.

Without Fn you would have to forget (for example) having F1..F12 as they need a keycode; you cannot assign them to a "software" key combination.

My point: you have to generate those as a distinct keycodes to be able to emulate a useful PC keyboard.

 

[Caine]

Without Fn you would have to forget (for example) having F1..F12 as they need a keycode; you cannot assign them to a "software" key combination.

My point: you have to generate those as a distinct keycodes to be able to emulate a useful PC keyboard.

The X windowing system provides facilities for transforming (combinations of) scancodes to unique keycodes.So if you have an extra modifier then this can be used to emulate an Fn key. However, any application that works around X in any way will not

benefit from these facilities and will have to implement that itself.

Hence, putting it in the keyboard driver (i.e. a real Fn key) will be easier for application developers, but you will not be able to move the

Fn key to another position or bind it as a gaming button (without changing the driver).

 

[Antartica]

The X windowing system provides facilities for transforming (combinations of) scancodes to unique keycodes.

So if you have an extra modifier then this can be used to emulate an Fn key. However, any application that works around X in any way will not
benefit from these facilities and will have to implement that itself.

That would be sufficient for most use cases, but it bothers me...

Right now on the pandora I can open a terminal, become root and "chvt 1". And there I have the console at VT1. I can change between consoles with Alt+F<n>, and return to X with Alt+F7.

That means that I can mess with the X configuration on the pandora and don't worry much about it, as it is self-sufficient and I can fix it from console, just like in a PC. If those keys only worked on X, it would be less of a mini-PC.

If all this is because it would be nice to be able to relocate the function key, I would even volunteer to make the needed changes in the keyboard driver so that it is configurable at runtime (via a file in /proc or /sys...). I mean, the driver will be pyra-specific anyway, and IMHO that is easier than modding X and every program that uses the keyboard without X...

 

[_wb_]

OK, you're right. Is it possible to have two Alt Gr keys that are distinguishable?


Also, is it possible to have three Shift keys that are distinguishable?

Two AltGr keys? What are you planning?

Usually you have different scancodes for left alt, right alt, left control, right control and left shift, right shift.


So the software can make the distinction.


<edit>Third shift, no not likely.</edit>

If there are going to be two shift keys on the keyboard and one as a shoulder button, then there are 3 shift keys, but there are only 2 different scancodes.

If there is one AltGr key on the keyboard and one as a shoulder button, then there are 2 AltGr keys, but only 1 scancode.

So if you would want to make a game that uses the shoulder buttons and the easily reachable keyboard buttons at the edges, it would be a problem.

 

[_wb_]

Would this work?

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

where in X, the scancodes for LSuper and RSuper are (by default) interpreted as Shift and AltGr, respectively. Can that be done?

This way, every button/key gets a unique scancode (so all keys can be distinguished from one another), but we can still have Shift and AltGr on the shoulder buttons.

 

[WizardStan]

If there are going to be two shift keys on the keyboard and one as a shoulder button, then there are 3 shift keys, but there are only 2 different scancodes.

We can define our own scancode for a 3rd shift key (or second AltGR, etc...). Existing applications and quick ports wouldn't be able to use it (unless they were just looking for the generic "shift" or "altgr" modifier) but newer homebrew could easily tell the difference, especially if we add them to SDL for easy access.

 

[Askarus]

If there are going to be two shift keys on the keyboard and one as a shoulder button, then there are 3 shift keys, but there are only 2 different scancodes.

Doesn't matter.

Left shoulder button and left Keyboard Shift can bot work as L-Shift.

Why not?

If there is one AltGr key on the keyboard and one as a shoulder button, then there are 2 AltGr keys, but only 1 scancode.

Is Alt Gr a good Key for shoulder button?

Do lots of games support it?

There's already problems with CTRL and Shift sometimes.

So if you would want to make a game that uses the shoulder buttons and the easily reachable keyboard buttons at the edges, it would be a problem.

You can't press Fn now as well for games and it's not a problem.

I didn't need it for Jedi Knight and that game uses nearly the whole Keyboard.

Also if you map the L Trigger and Left shift button as the same Shift Key it's pretty unlikely to need the button on the left hand side where usually the D-Pad and moving stick is.

Also you have 2 Lines above the shift Key (closer to the thumb.

I don't think there will be several games that have problems because they need so much buttons that they need the L-shift Key and not any other one can be used better.

Remember, you have 2 more shoulder buttons, 2 Buttons in the nubs and 2 Gaming buttons.

I also wouldn't say the L-Shift key is that easy to reach, that you need it for games.

 

[Granitehead]

If there are going to be two shift keys on the keyboard and one as a shoulder button, then there are 3 shift keys, but there are only 2 different scancodes.

 Doesn't matter.

Left shoulder button and left Keyboard Shift can bot work as L-Shift.

Why not?

Because then one of the buttons is lost, if they need to have the same function at all times.

 

[Christoph.Krn]

Right now on the pandora I can open a terminal, become root and "chvt 1". And there I have the console at VT1. I can change between consoles with Alt+F<n>, and return to X with Alt+F7.

That means that I can mess with the X configuration on the pandora and don't worry much about it, as it is self-sufficient and I can fix it from console, just like in a PC. If those keys only worked on X, it would be less of a mini-PC.

This bothers me too, a lot actually.
Not that I do edit X configurations very often, but I would no longer consider the device a mini desktop-like computer out of the box.

 

[levi]

I didn't know about chvt until this discussion, but I've tried using Alt+F before, and to be honest the digital gymnastics you need to get into to reach that combo is a good example of something that's bloody awkward on Pandora that could be improved in Pyra - and if it worked from inside X too that'd be even better.

 

[_wb_]

Why wouldn't AltGr keys work in the console?

 

[levi]

If you implement it using xmodmap, as I understand it, as soon as you go outside X (on another terminal, for example), you lose it.

 

[slaeshjag]

The normal tty does apply a keyboard map too though.

 

[Caine]

The normal tty does apply a keyboard map too though.

You're right, loadkeys seems to be the tool. Didn't know about that one.
If it has the same expressivity that mitigates the issue of a software modifier.

 

[Antartica]

AFAIK, it doesn't have the same expressivity.

The reverse of "loadkeys" is "dumpkeys". If you execute that on the console, it dumps the current keymap to stdout (that keymap is usable with loadkeys). "dumpkeys -l", gives additional information, such as the supported modifier keys.

The problem with loadkeys is that the composing abilities of that map are rather limited; the only "modifier" keys are: shift, altgr, control, alt, shiftl, shiftr, ctrll, ctrlr, capsshift. It doesn't support other keys as modifiers. On top of that, composing seems to be geared to dead keys ( "`", "^",  etc ).

In regard of using loadkeys, another thing that should be considered is: is there any program that uses raw keyboard when on console? (specifically: what does SDL use?). Those programs would bypass the kernel keymap (just as X does) and thus miss the "composed" keys.

All this makes me to prefer having the Fn key in the driver.

Anyway, as I said in the other post, having the Fn defined using the X facilities is a workable solution, it's just that I prefer having it working both in console and in X.

 

[levi]

It should be possible to code the driver such that if the Fn button is pressed in isolation it returns a code for that key, or if you press it in combination with a gaming button, returns the two codes, but if you press it with a key that makes a 'special' character then it should just return that one code and not the Fn keycode or the actual key pressed key code.


But I don't know what the problems were coding Fn functionality into the Pandora driver were, so I don't know how workable that solution is.

 

[Saber]

Redesigned the Pyra layout on the first page.

 

[Grench]

Redesigned the Pyra layout on the first page.

I like it. And thank you for mapping the 6 buttons the right way for Pandora software compatibility.

 

[Saber]

Thank you Grench.

It took some time but I like how it came out.

 

[comradekingu]

Provided the keyboard cant house every key under the sun, is it a bad idea to have the rest available on a on-screen basis when you hold down a modifier key?

I think A-Z+3 and 0-9 and punctuation + some coding is what should be available as button, as that is the main focus.

Having all sorts of modifier and smart what have you, means shifting focus, and inherrently taking away focus at the same time.

Edit: cant find anything to improve on, but maybe the . , and (spacebar) could have a different texture (and form?) so its easy to tap it with the joint of the tumb and keep hitting letters with the tip.