Current Keyboard Layout

[slaeshjag]

^ A select few programs uses scancodes, where it works out anyway. Examples would be dosbox/Qemu system emulation, whrere everything breaks until you set a matching keyboard layout as on the host system. These will require some degree of patching.

Apart from a few specific system emulators and a couple old windows games, I can't remember any issues with scancodes.

 

[WizardStan]

I know that every single application works with my german keyboard layout. That shows it's not using raw keycodes and won't break.

DosBox and QEMU are two applications that would definitely be broken.Where there are two the chance of there being more is not zero. I don't understand why you're refusing to acknowledge the possibility that there might be problems.

 

[notaz]

Almost all stuff I've released is using low level scancodes, but that was my own design decision. I think I saw somebody else to do that too in their PND.

The normal shell terminal should work with loadkeys:

http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-15.html

From what I remember loadkeys was pretty limited and we couldn't even fully do full pandora's keypad with it (some keys don't work to this day).
There are some things that are impossible with both loadkeys and xmodmap like making shift-backspace to do telete, we never managed to do it on pandora. I suspect there are many other such cases.

 

[comradekingu]

Its a void issue compared to what it takes to do it, and it wont get any worse. Can we move on?

 

[lennaick]

I know that every single application works with my german keyboard layout. That shows it's not using raw keycodes and won't break.

DosBox and QEMU are two applications that would definitely be broken.
Where there are two the chance of there being more is not zero. I don't understand why you're refusing to acknowledge the possibility that there might be problems.

http://www.dosbox.com/DOSBoxManual.html#KeyboardLayout

Additional layouts can be added by copying the corresponding .kl file into the directory of the DOSBox configuration file and using the first part of the filename as language code.


Example: For the file UZ.KL (keyboard layout for Uzbekistan) specify "keyboardlayout=uz" in the DOSBox configuration file.


The integration of keyboard layout packages (like keybrd2.sys) works similar.

Is it impossible to create a pyra.kl ?

 

[FaeMinx]

I don't think a custom keyboard driver is too much to consider. Is it possible to do both?

 

[MrConfusion]

Apart from a few specific system emulators and a couple old windows games, I can't remember any issues with scancodes.

TBH I no longer know what problem (raw input or keypairing) is being discussed, but want to point out that Dosbox does, in fact, not read scancodes directly from keyboard, SDL sits in between.

I haven't tried qemu, because I havent come across it's source code for the Pandora, but if it uses SDL, then neither does that one.


Same for UAE and Vice. They both go via SDL.

Old system emulators using SDL will not need patching because they would read keycodes from event inputs! SDL solves them all in one go. And SDL will likely need a framebuffer patch in any case!

(

However, if this discussion has turned into keyparings: Yes, they will need patching to accommodate the Pandora keypairings but that is a different issue that needs to be handled in any case if you want them to support several languages. And yes: logically only emus suffer from this, UAE has been patched, DosBox, QEmu has been patched... AtariST, did anyone even bother? Vice... well... when we get to the OldOld 8bit-era systems, everyone intuitively understands that the keyboard cannot work as is and some mapping has to be done and understood. I also doubt anyone wants to do productivity with those, whereas with Amiga and PC there are some nice things to at least try... Running GEOS on Vice on Pandora probably didn't even cross anyone's mind.

)

 

[TrashyMG]

Almost all stuff I've released is using low level scancodes, but that was my own design decision. I think I saw somebody else to do that too in their PND.

The normal shell terminal should work with loadkeys:

http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-15.html

From what I remember loadkeys was pretty limited and we couldn't even fully do full pandora's keypad with it (some keys don't work to this day).

There are some things that are impossible with both loadkeys and xmodmap like making shift-backspace to do telete, we never managed to do it on pandora. I suspect there are many other such cases.

From what I've been reading on the TCA8418 chip is that how the kernel level stuff currently works is that it doesn't output scancodes, but keycodes... I still have finish the work on my keyboard project to understand the OS side of it. But in the device tree source, it's clearly associating Row, Columns to keycodes. I'm not sure how this affects the programs that solely use scancodes, as I don't understand the OS side of things yet. 


Device Tree Source snippet: 

Spoiler

/* keyboard scanner */
tca8418@34 {
compatible = "ti,tca8418"; /* this translates into request_module("i2c:tca8418")
  so it must be known as a MODULE_ALIAS to modprobe -c */
reg = <0x34>;
/* the interrupt is specified as:
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
*/
interrupt-parent = <&gpio6>;
interrupts = <17 IRQ_TYPE_EDGE_RISING>; /* gpio6_177 low-to-high edge */
keypad,num-rows = <8>;
keypad,num-columns = <10>;
linux,keymap = <
/* The 32-bit big endian cell is packed as: row << 24 | column << 16 | key-code */
 
0x0306003b
0x0203003c
0x02040057
0x01080058
0x0102003d
0x0701003e
0x07030002
0x06070003
0x06010004
0x05050005
0x06060006
0x04030007
0x03070008
0x03050009
0x0205000a
0x0107000b
0x0702000e
0x0503000f
0x06040010
0x05080011
0x05020012
0x04060013
0x06020014
0x03040015
0x02080016
0x02020017
0x01060018
0x00050019
0x0004001c
0x0400002a
0x0506001e
0x0401001f
0x04040020
0x03080021
0x03020022
0x02060023
0x01030024
0x01040025
0x00080026
0x00020036
0x07060033
0x06030034
0x0507002c
0x0501002d
0x0405002e
0x0407002f
0x03030030
0x02070031
0x07040032
0x01050039
0x00070039
0x00000064
0x01090069
0x0309006a
0x00090067
0x0209006c
0x05090066
0x0709006b
0x04090068
0x0609006d
0x03000038
0x0200001d
0x01000001
0x00010036
0x0101004e
0x03010061
0x0201004a
0x07000110
0x06000111
>;
};

 

[EvilDragon]

Almost all stuff I've released is using low level scancodes, but that was my own design decision. I think I saw somebody else to do that too in their PND.

Well, but you change the key layout within your stuff as well (PicoDrive, PCSXReARMed, etc.), so that won't be an issue.

Games and programs originally developed for the Pyra won't have issues here anyways.

And portable programs for multiple systems probably don't use low level scancodes.

From what I remember loadkeys was pretty limited and we couldn't even fully do full pandora's keypad with it (some keys don't work to this day).

There are some things that are impossible with both loadkeys and xmodmap like making shift-backspace to do telete, we never managed to do it on pandora. I suspect there are many other such cases.

Okay, something to find out!

 

[WizardStan]

Is it impossible to create a pyra.kl ?

I know we could remap one key to another, I'm not sure if it could remap "meta+E->F4".But even if it is, that would still be classified as a problem that needs to be fixed. A problem that probably wouldn't take very long to fix but a problem all the same.

 

[MrConfusion]

Almost all stuff I've released is using low level scancodes, but that was my own design decision. I think I saw somebody else to do that too in their PND.

The normal shell terminal should work with loadkeys:

http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-15.html

From what I remember loadkeys was pretty limited and we couldn't even fully do full pandora's keypad with it (some keys don't work to this day).

There are some things that are impossible with both loadkeys and xmodmap like making shift-backspace to do telete, we never managed to do it on pandora. I suspect there are many other such cases.

I'm ready to put my butt to the line of fire when it comes to loadkeys which, though complex, does not generally disappoint and doesn't try to pamper the user with a bunch of silly coded-in-kernel switch-cases. XModmap on the other hand is an utter piece of **** and I well believe it woud mess up exactly something like Delete and Remove. But I was under the expression people want rightalt (AltGr) anyways and thus xmodmap is out of the equation and xkbd or (IMO better) inputtylike event daemon are required.

I tried loadkeys just now: no problems, I put code "Remove" to shifted Delete and it works as expected. Though I must admit. since I use vi I wouldn't have ever hit this issue to begin with...

Not going to bother even trying xmodmap, though ;-).

 

[bzar]

So IMO at least on the Pandora B-ZaRs inputty or something similar would be preferable for X: it could collect all the input devices into a single uinput, and do any neccessary transformations. The only downside that might exist is latency and I think that would have been a nonissue even on the Pandora - when the CPU is maxed the gaming experience will suffer anyway... At least personally I'd have to suffer from some dismal latency to find the convenience "not worth it".

The "something similar" part would be the way to go. Inputty loads 24M worth of Qt libs and takes ~10M in itself. Also though I haven't noticed any issues with lag on my desktop, potentially going through a JS environment might not be the best idea for a portable gaming device. Inputty is nice for specialized needs, but not really the leanest piece of software

 

[txus]

You guys are talking about key-converting daemons and patching/configuring a random number of software, which even leaves you with uncertainty of having solved it for everything (wayland, Android, ...?) and the problem of not being able to get the software from the standard Debian repositories, when it could be solved at driver level at the cost of not having it mainlined. Probably. Even if there is 100% no way of mainlining such driver, the development and maintenance cost of keeping a driver on a regularly updated branch should definitely be less than the option you are considering, right?

 

[Grench]

 

[EvilDragon]

Thanks a lot, Grench!

Not for withdrawing them, but for all the work you did (and the really smart layout).

I still think it's too complex for the casual user (and even myself ), but it was awesome to see such things are possible.

 

[WizardStan]

If custom keymats ever become a thing, something along the lines of Grench's fn-layer numbers will be what I go with.

 

[FaeMinx]

Yes, thank you Grench. I found your layout very inspired, and I would have put in the effort to learn how to use it... But I understand ED's point too.


I was not being sympathetic towards new users. For all I know it might turn out to be confusing to me too. Oh well.


A great pity we never got to actually test it.

 

[MrConfusion]

...when it could be solved at driver level...

Explain? Did it solve it on the Pandora?

 

[WizardStan]

Explain? Did it solve it on the Pandora?

Yes.This is talking about the problem whereby pressing "Fn+<x>" will return the scancode Fn (or most likely meta, or some other already existing modifier) and <x> instead of whatever it functionally modifies to. The Pandora didn't have an issue with this since it handled the modifier at the driver level, a solution that is not possible if it's to be kept in mainline.

Whether this will actually cause any real world problems or not has yet to be fully established.

 

[Haraldur]

DOSBOX caused be great trouble until I noticed the option to disable the use of scancodes instead of key-symbols. Thenceforth there seemed to be no trouble. Have I missed something?

Please may we have a top-level ESCAPE key? I would find it very useful for VIM and for the games Might and Magic III-V (and, I suspect, the Wizardry series as well, and many other DOS games; also, having top level keys F1-6 would be good for the M&M games, but that is too specific and problematic so... ignore that bit ).

I also agree that backspace should not be on an action-button, but somewhere else towards the top-right of the keyboard (perhaps two spaces right of the power button). Again, it would be useful for a multitude of DOS games, including the Might and Magic series.