Why and how is sysRq important?
It's shortcut for low level command directly in the kernel, you can regain control of a session if there is a problem and if you still can't access terminal it allows you to shutdown or reboot properly without corrupting data.
Wikipedia is pretty exhaustive about it :
https://en.wikipedia.org/wiki/Magic_SysRq_key
The keyboard controller isnt hardcoded, nor hardware-interrupt.
Dvorak is already out if you want to do doublewide space.
Given 104 keys, US layout would work without hassle.
A computer keyboard works like this : the keypress creates an interruption in a matrix that gives a certain output to its controller, the controller transmits a 7 bits keycode to the computer, the OS reads a table (for GNU/Linux it's mainly xkb who reads a map of the chosen layout) then it translates the keycode into events that could be related to a character or a modifier.
The only layout included in the Linux kernel is us-qwerty, this is why I call it legacy, all of the others layouts needs an external map to translate keycodes, and this is what xkb files are for.
So I admit I'm not following closely the project and I don't know how the embedded keyboard is planned to be wired, all I know is that a standard device controller (pointing device, keyboard, gamepad) sends keycodes and even the keyboard of laptops uses an internal PS/2 interface.
What games are troublesome without A-Z and basic first level punctuation? Isnt it easier to just put a layer in between them taking over the framebuffer and input?
If they are FOSS games, fixing broken functionality where its broken sounds like a better idea.
It's a work to do on every games that have a bug report called "Doesn't work with the xxx layout" and sometimes it may need a huge rewriting because the initial developer was US-centered or sometimes it's a limitation of the language or the engine used.
SDL games are often a problem when they doesn't allow to chose your keys because if you want to play on keyboard you have to deal with the odd configuration file. FCE Ultra (included in Mednafen) is one of those tricky program to setup with non-qwerty layout. If the gamepad part is a real gamepad, this should be quickly configured with an extra layer emulating keyboard and mouse events like qjoypad or antimicro does.
Another related issue is that some games don't allow non-ascii characters for keybinding or consider the non-ascii as a unique key. That's occur in Java games as Minecraft and on SDL games as Xonotic, Red Eclipse or Vegastike (in the UK-qwerty mode, not in the keycode mode).
This last game shows another problem : ingame tutorial and keybinding chart in the help menu are static and doesn't provide the actual characters of you keyboard. I saw that too in Double Fine's "Costume Quest", that's bad development and not an isolated problem.
So it's not always simple to fix, even for FOSS.
Keycaps idea is novel, but couldnt be done. I have researched that extensivly, and you basically need a wider keyboard to do it well.
Additional keymats dont increase the price of the basic product, since they are optional. Selling to more people brings the price down.
That's what I was afraid of for the feasibility of labelling caps. It's difficult to make for such small keys.
Yes, sorry, I forgot that the removable keymat should be an option over the classic keyboard and not a replacement. You're perfectly right :-/ As Codifies said it just needs a proper method to be attached.
(WizardStan) That's actually necessary. There's no character code for ctrl, alt, or shift, nor the arrow and F1-12 keys; backspace, enter, insert, delete, home, end, PgUp and PgDn are all just "ctrl"+"something" characters, so there's a lot of potential for programatic confusion if you're using characters instead of key codes.
Further, if using the character mechanism there's no way to know when a key has been pressed vs released, you just get a stream of characters from the OS (with the time between each character being kernel configuarable and not ever fast enough for real-time reactions) and kind of have to guess where the key press starts and ends, and you'll be wrong if you need it to be millisecond accurate.
Finally, you say "some" games when really it's "pretty much every PC game written since the dawn of time". Like, obviously not text input games, at least not all of them.
WizardSan, that's absolutely not true IMHO. In GNU/Linux, Xev shows you the keycode and the keypress event output by xkb without any lag : Even if there is no character placed for a keycode in a map, there is still an event for a modifier (xkb allows you to change the place of all keys, with or without a character displayed) To me, any good program uses those keyboard, mouse or joypad events to make the interaction. Those scanning directly the keycode and bypassing the "layout manager" do their keyboard inputs process in the wrong way. Even Grub uses a customisable mapping and not directly the keypresses. SDL makes the same, in its way too with keysyms.
The "press or released" for what I think you are talking about depends on what your hardware is capable of and the setting : micro-controlers as Arduino can output the keycode at pressing as standard keyboard or releasing the key or with a delay, OS-independant sticky keys and even chord keyboard. xkb can do nearly the same, but later in the HMI protocol.
Is
http://www.keyboard-...e928661ed411158 close to what you were thinking of, guest_blip_*?
That's the spirit
even if I thought to keep the four alpha keys on the right in the same arrangement as an ISO keyboard with respectively [ ] ' \ on Fn+ O,P,L and ; But I didn't really think of a layout.
_wb_ did something interesting too but missed the R_Alt (AltGr) because it's always needed for ISO layouts (even UK and Colemak) and LSGT ("lesser, greater" the 105th ISO key) that IMHO could be placed on Fn+z.
To have deal with 60% and even 40% keyboards, the best is to keep close the different keys from a bloc to allow a better compatibility with all the different ISO layouts.
(feel free to make an account, you are very welcome)
I'm just passing by every 6 Months, to take some news of the project. I already have too many forums to follow and I won't certainly be very useful here
If I was here in the beginning of the keyboard creation, I might made a crazy/disturbing/unconventional/ergonomic proposition designed for thumb typing efficiency and comfort (keys placed in arc-shaped row and different sizes, that kind of weird stuff) but it's way too late in the process.
As I said, I don't really care about the embedded keyboard for gaming and maybe I'll craft some "external keyboard / docking station / power bank" with the typing feel that suits me for computing.
