Possible improvements over standard keyboards

davkol

30 Jul 2015, 12:59

Have you seen my ErgoDox recording? (layout)

User avatar
Ray

30 Jul 2015, 14:13

trapicki wrote:
Ray wrote:
rsbseb wrote: I personally dispise the continued use of generic scan codes.
So what you really want to ask for isn't unicode support, but support for an not yet existing set of universal and unified scancodes!
Currently, the keyboard sends a scan code, that is translated to some meaning by the keyboard driver and keyboard layout mapping. Quite a few indirections. If you decide for example to separate [ ans { on an US keyboard, you have to send "[" for the first and "Shift-[" for the second.
With unicode on firmware level you are shifting an indirection from the software to the firmware side which shadows the hardware-level of the keypresses. This is okay for the usecase where the keyboard is used for entering text. But that isn't the only context a keyboard is used in.
Let's look at another one that is currently appealing to a fair share of people that are willing to pay more than the minimun on keyboards: games. Here the keyboard acts as a gamepad with several dozens of buttons. If you assign 'A' to left, and 'Fn' to jump, but your keyboard sends for Fn+A the unicode for 'Aleph', game developers will curse a lot. If you don't send a equivalent for scancodes, there is no way to know which buttons were pressed to get that Aleph.
Or as another case, maybe a program wants to distinguish between the numpad '3' and the '3' on top of the alphas. Maybe insert roman numbers when numpad numbers are pressed. Anyways the application knows the context, the keyboard never does!
The application can't interprete the keypresses in its context, if the keyboard tries to interprete what was meant by 'Fn+A' when it had no idea what was meant by it.

User avatar
trapicki

30 Jul 2015, 17:41

Ray wrote: Anyways the application knows the context, the keyboard never does!
There is quite a range of posibilites:
  • The keyboard sends just a key number, the software (OS, programs) interprets what that means.
  • The keyboard sends some code with some meaning, the software interprets this, with some default values, and some "translations". This is the currently used system, the translations are the keyboard mapping files. Manufacturers simple change the labeling, but not the scan codes for different languages. Moreover, some state is held and reported back to the keyboard, for example "Num Lock", which changes details in the interpretation.
  • The keyboard sends some code, the software interprets this, but no different mapping exist for the same scan codes.
  • The keyboard sends some code, the software asks the keyboard some time for the meaning of the code.
You can't prevent some mapping outside of the keyboard anyway, and there is no reason to do so anyway. It's just that through the development of the current keyboard system, all this is tangled up: Some characters can only be generated as combination of modifier and key, like $, and that even differs across languages: in German, / is Shift-7, and ] is AltGr-0. That in turn is sent as Ctrl-Alt-0, which makes it impossible in German layouts to press Ctrl-]. I once had a program that had this shortcut for a quite important function. No way to do this with German layout, besides being an awkward combination at the German layout.

For games, mapping is arbitrary anyway. Any program that nails down shortcuts and key mappings will break for some layout anyway.

So why not just get it clean: The keyboard sends some meaningful code, the software does not do some obscure magic, and we have a lot less problems.

davkol

30 Jul 2015, 18:01

trapicki wrote: …and ] is AltGr-0. That in turn is sent as Ctrl-Alt-0, which makes it impossible in German layouts to press Ctrl-].
Either your keyboard, or your OS sucks.

AltGr-0 means
  • key code 100 press;
  • key code 11 press;
  • key code 11 release;
  • key code 100 release.
For a Ctrl-AltGr-0, add key code 29 or 97 press and release.

User avatar
Muirium
µ

30 Jul 2015, 18:57

Glad the Mac doesn't have AltGr. What a shitty hack of a mod: sending a macro!

User avatar
Ray

30 Jul 2015, 19:39

what's hacky about AltGr? It's a mod, just like shift. Shift+5 results in %, AltGr+7 in {. No macros or other wizardry involved.
It is stupid a new mod got introduced for ~9 Symbols though. And it is rediculously stupidly placed for a mod. Don't get me wrong, I like thumbkeys, but this is usually too far right. And the keys it modifies are pressed with fingers on the same hand… come on, that's like saying left shift is for keys left of G and right shift for the keys right of H!

User avatar
OleVoip

30 Jul 2015, 20:41

trapicki wrote: in German, / is Shift-7, and ] is AltGr-0. That in turn is sent as Ctrl-Alt-0, which makes it impossible in German layouts to press Ctrl-]. I once had a program that had this shortcut for a quite important function. No way to do this with German layout, besides being an awkward combination at the German layout.
On a German keyboard, press Ctrl along with the key where "]" is on a US keyboard (which is the German "+" key) and you get Ctrl-]. That's because Ctrl-] is not just the physical combination of two keypresses but it translates to a 7-bit ascii code.

Post Reply

Return to “Keyboards”