Unofficial Keyboard Layouts


Pipe (and backslash, but I don't use that) are behind the FN key too on this machine.


All the keys people thought they needed are listed on the wiki. The requirement I wrote about shell keys assumed most of them would require the FN key to be held, but that wouldn't be much of an issue if one of the shoulder buttons did FN. If we're not having FN at all, I'm not sure where all those keys will go.
 
alt-gr is where they'd go.
Most of the letter keys on my computer keyboard already have characters you get it you chord them with alt-gr (e.g. the QWERTY row is @łe¶ŧ←↓→øþ). The at symbol there could be overridden, as there's another one on my keyboard so it seems superfluous, but on a four row keyboard we still need to find space for all the symbols that aren't shifted numbers and all the F keys, and I don't think the AltGr map has enough free space for all those.

Granted, without AltGr the Pandora is unable to produce many of those symbols (some could perhaps be composed, but others require you to use a software app), so perhaps we don't need to support all of those symbols on the Pyra, but I'd suggest that if we call a key AltGr it should work like AltGr does on other keyboards.
 
alt-gr does different things on different keyboard layouts on different operating systems.

It's a much bigger problem that we don't have enough keys to use a real layout, rather than that we can't follow Xorg's default keymapping.
 
I'd suggest that if we call a key AltGr it should work like AltGr does on other keyboards.
Exactly!

Another thing to keep in mind is that if you plug in an external keyboard you'll want to be able to use it without switching to a different key mapping.   While there are some oddities with doing this on the Pandora, it mostly works because the Fn mapped symbols mostly map to the same key codes as they do on a real keyboard, but the further we deviate from a real layout the worse it will be.

- Neelix
 
^ Not really. It works somehwat as long as you plug in something simlar to US Qwerty.

If I were to plug in a swedish layout keyboard in a pandora, the layout is completely FUBAR.

We want a daemon to dynamically switch layout as external keyboards are plugged in.
 
I think it's a good idea to get rid of the "hardware" Fn key and make it a normal modifier key. That is a more elegant solution and allows the key to be used like a "real" key in games etc.

I don't like the name "Alt Gr" though, can't we call it "Meta" or "Super"?

If we have two of them (one on the keyboard, one on a shoulder button), it should correspond to a modifier key that appears twice on regular keyboard. On standard keyboards there is a left and a right "Windows key", which is usually called "Super". It makes sense to follow the Pandora convention and map the keyboard key to Left Super and the shoulder button to Right Super. I think of Alt Gr as just the Right Alt key, which may or may not behave differently from the Left Alt key.
 
I don't like the name "Alt Gr" though, can't we call it "Meta" or "Super"?
You might not like the label AltGr (stands for Alternate Graphic), but that is what it is commonly called.I do not recommend deviating from that unless we change its function as well.

Meta and super are different modifiers that doesn't affect what the key you press becomes.

Alt Gr is not an ALT key.
Exactly. Meta and Super already exist as modifiers. Let's not overload these.
 
Last edited by a moderator:
Meta and super are different modifiers that doesn't affect what the key you press becomes.

Alt Gr is not an ALT key.
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?
 
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>
 
Last edited by a moderator:
So, let me try to get this straight in my head. While FN+button produces a symbol, as Shift+1 produces an exclamation mark, the former is handled differently to the latter? In that, the former is somehow hidden from the OS, while the latter is a software keyboard mapping?


Can't we have a new key that behaves like shift, but produces a whole set of different characters according to the keyboard mapping, and we call it, oh I dunno, FN?


Edit: Or AltGr, I don't really care.


Edit2: Switched 'former' and 'latter' in the third sentence, first paragraph.
 
Last edited by a moderator:
Right. Is that different to when I said 'While FN+button produces a symbol, as Shift+1 [or AltGr+W] produces an exclamation mark [or an ł], the former is handled differently to the latter'. Does 'In that, the former is somehow hidden from the OS, while the latter is a software keyboard mapping' explain the difference between a hardware modifier and a software modifier, or have I got the wrong end of the stick?


Edit: My apoligies, I got my 'former' and 'latter' mixed up in the second sentence.
 
Last edited by a moderator:
So, let me try to get this straight in my head. While FN+button produces a symbol, as Shift+1 produces an exclamation mark, the former is handled differently to the latter? In that, the former is somehow hidden from the OS, while the latter is a software keyboard mapping?
Yes, whenever you strike a key on your keyboard a scancode is sent to the OS (this is just a specific number for each key)
In case of Fn+Key a single scancode is sent to the OS. In case of shift+key or AltGr+key, two scancodes are sent the one for shift/altgr and the one for the key.

Subsequently the OS converts the scancode(s) it receives into a keycode which represents a locale-dependent symbol E.g. a letter, number or punctuation symbol.

Bottom-line, as mentioned by others, Fn is not under control of the OS, whereas AltGr is.

Using AltGr makes it easier on the keyboard driver side as the scancodes don't need to be handled customly. On the other hand modifier + key combinations need to be handled by the OS and the Pyra will be using uncommon ones, merely shifting some of the work. <edit>It is less work on the OS level as standard mechanisms are in place for this</edit>

Also, if I am not mistaken, the scancode to keycode conversion is handled by XModmap which will not be present outside of the X windowing system

and might not function in emulated and/or virtualized environments either.

<edit2>Strictly speaking, the term OS is not entirely accurate here. However, I think the rough distinction of the mechanism should be clear.</edit2>
 
Last edited by a moderator:
Back
Top