It's the keyboard layout.

[codifies]

I don't think key caps would be practical with a "rubber" keymap (I know its not rubber!)


The idea of a clipon stencil could allow people to put their own sticky label on a blank or spare stencil, simple clips could be very simply added to the design of the case... But *would* require some thought to get right...


Regarding scan codes as we'd have to modify libraries like SDL and glfw etc the allowing for custom keycodes isn't really an issue...

 

[blip]

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.

 

[_wb_]

_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.

R_Alt is at a shoulder button (R2)  in my proposal. Just like R_Ctrl and R_Shift. But if you need AltGr only for some special symbols like €, then I suggest to map them to Fn/Meta + letter, which is still available at most letters.

Fn/Meta + Z is still available in my layout if you need it for an LSGT key. I personally prefer to have < and > on two different keys.

 

[WizardStan]

there is still an event for a modifier

...

To me, any good program uses those keyboard, mouse or joypad events to make the interaction

Events are not characters, your exact words were "character input". I may have misunderstood what you intended to say but to me, talking about the "character codes" of keys which don't generate characters doesn't make sense.

 

[rygD]

I saw some discussion about replacing keycaps and such, but I didn't see anyone mention that the keycaps are, as I understand it, plastic pieces that are glued or otherwise held in the silicone of the keymat.  That should mean they ARE replaceable without gettinng an entirely new keymat.  If you want to split the spacebar you will still need at least a second keymat, and if you change the physical layout of your keycaps some things will probably have markings that are incorrect.  That last part is why I prefer as few markings on the letter keys as possible...not so much for me, but for others that want to change their layout.

Back to the keycaps in the silicone, I would like it if the caps were fitted into the mat and din't need to be glued, if possible.  I imagine a piece of the silicone sticking out along the inside into a slot around the cap, or around the top edges.  Some stupid benefits include trying other layout without needing to be commited to it, and easier cleaning.  Some cons are potentially losing a keycap, or people moving your caps around for fun, and possibly increased cost if that is not already planned.

 

[blip]

I still don't figure out how the embedded keyboard is wired when looking at the pictures of the PCB. The main board seems to have some sort of controller chip where traces from the keys go, but I'm not sure of that. Moreover, I don't know if external keyboards will be supported and how the OS will deal with their standard layouts.
 

_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.

R_Alt is at a shoulder button (R2)  in my proposal. Just like R_Ctrl and R_Shift. But if you need AltGr only for some special symbols like €, then I suggest to map them to Fn/Meta + letter, which is still available at most letters.

Fn/Meta + Z is still available in my layout if you need it for an LSGT key. I personally prefer to have < and > on two different keys.

R_Alt is AltGr on most ISO layouts and few ANSI layouts as colemak, us-international, and dvorak-international so you need L_Alt too for a real Alt Modifier.

Fn + letter will implies that all the xkb layout files will need to be seriously modified for Pyra because in my point of view, Fn is a low level keycode modifier instead of any other modifier like Meta or AltGr that are set in the high level of the XKB map. If you have to change xkb layouts, that means you will need the original layouts if you want to use an external keyboard (It can be done in an extra package in the repository but it double the number of xkb layouts stored in the Pyra)

When I talk about LSGT, it's about the key. The characters assigned on this key change, depending on the ISO layout chosen.

there is still an event for a modifier
...
To me, any good program uses those keyboard, mouse or joypad events to make the interaction

Events are not characters, your exact words were "character input". I may have misunderstood what you intended to say but to me, talking about the "character codes" of keys which don't generate characters doesn't make sense.

Sorry I badly express myself. I meant events since the beginning otherwise it's silly to think about characters, as you rightly pointed it

 

[pmprog]

Surely the answer is simple, you have a "Diacritic Rotator" key, that you press and hold, then you press and hold "A" (for example), and it'll rotate through all variations of the A character

Or you maybe do it more software based when you press and hold the D.R. button, then you tap your key (ie, A) and it pops up a window with all the associated diacritics, and you keep tapping until you reach the one you want, let go of the D.R. key, and it sends that character to the keyboard buffer

Then you'll only have to use two keys but infinite possibilities...

Magic

 

[bzar]

Surely the answer is simple, you have a "Diacritic Rotator" key, that you press and hold, then you press and hold "A" (for example), and it'll rotate through all variations of the A character

Or you maybe do it more software based when you press and hold the D.R. button, then you tap your key (ie, A) and it pops up a window with all the associated diacritics, and you keep tapping until you reach the one you want, let go of the D.R. key, and it sends that character to the keyboard buffer

Then you'll only have to use two keys but infinite possibilities...

Magic

Or maybe an always-on handwriting recognition on the touch screen that you can draw the non-ascii charaters on.

 

[codifies]

oh can we have a magic unicorn attachment so we can type via telepathy!

 

[WizardStan]

https://www.youtube.com/embed/9BnLbv6QYcA?feature=oembed

 

[pmprog]

https://www.youtube.com/embed/9BnLbv6QYcA?feature=oembed

Yes! That's exactly what I'm talking about... Let's get one of these installed ASAP!

 

[codifies]

After I laughed hard I showed the wife who agrees that is the pinnacle of user interface paradigms and as such further keyboard design is simply backward looking and counter productive...


So ends the keyboard thread - yay last post!

 

[_wb_]

No way.

 

[_wb_]

I still don't figure out how the embedded keyboard is wired when looking at the pictures of the PCB. The main board seems to have some sort of controller chip where traces from the keys go, but I'm not sure of that. Moreover, I don't know if external keyboards will be supported and how the OS will deal with their standard layouts.

_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.

R_Alt is at a shoulder button (R2)  in my proposal. Just like R_Ctrl and R_Shift. But if you need AltGr only for some special symbols like €, then I suggest to map them to Fn/Meta + letter, which is still available at most letters.

Fn/Meta + Z is still available in my layout if you need it for an LSGT key. I personally prefer to have < and > on two different keys.

R_Alt is AltGr on most ISO layouts and few ANSI layouts as colemak, us-international, and dvorak-international so you need L_Alt too for a real Alt Modifier.

Fn + letter will implies that all the xkb layout files will need to be seriously modified for Pyra because in my point of view, Fn is a low level keycode modifier instead of any other modifier like Meta or AltGr that are set in the high level of the XKB map. If you have to change xkb layouts, that means you will need the original layouts if you want to use an external keyboard (It can be done in an extra package in the repository but it double the number of xkb layouts stored in the Pyra)

When I talk about LSGT, it's about the key. The characters assigned on this key change, depending on the ISO layout chosen.

Fn/Meta/Sym/whatever will not be implemented at a very low level, but it will be implemented as an actual modifier key (an obscure one), for which the key events are visible to applications who know what to look for. Maybe we would use an existing, rarely used modifier, like Meta or Hyper. So yes, we will need custom xkb layouts. I don't think it's a good idea to let the Pyra keyboard try to look completely like a standard keyboard for which you can use standard xkb layout files, because it simply is not a standard keyboard. Most likely you'll want to use a different layout when using an external keyboard anyway, e.g. if you're German, and you connect a German keyboard, you'll have ZYÄÖÜß and the shifted number row in a German layout, while most likely, you'll want to use something different on the Pyra (e.g. the default plus ÄÖÜß at Meta+AOUS, or at some other position, but most likely not at ' ; [ - which is where those German keys are on a US-QWERTY keyboard). So having custom(izable) xkb layouts specific to the Pyra seems like a necessity to me.

Of course that doesn't mean that the default Pyra layout cannot attempt to resemble US-QWERTY and the ISO layout as much as possible. I think the most recent iteration of my proposal is quite good in that respect.

In an update to this previous post, I want to emphasize that one of the advantages of my layout proposal is that it intentionally leaves lots of letter keys without a Meta/Fn/Sym/whatever label, so they can be mapped optimally for your particular language(s). The following letters are free to map (with Meta/Fn/Sym/whatever) to whatever you want:

• A could be à, ä, å, æ
• B could be right single/double quote (paired with V for left quotes, like on a Canadian Multilingual keyboard)
• C could be ç, ¢, © or dead caron (for žčš)
• D could be đ, ð or perhaps some variant of E if multiple accented E's are needed (e.g. in French)
• E could be é, è, ê, ë, €, œ, æ
• F could be anything
• G could be Ğ or Ǧ
• H could be Ȟ or ħ
• I could be í, ì, ï or another variant of U or O
• J could be IJ
• N could be ñ
• O could be ö, ø, œ, ô
• Q could be another variant of A
• R could be ® or ¶ or another variant of E
• S could be ß, §, ş, š or another variant of A or E
• T could be þ, ŧ, ţ
• U could be ü, ù, ú
• V could be left single/double quote (paired with B) , or dead caron or circumflex (since it looks like a caron or upside-down circumflex)
• W could be another variant of E or A
• X could be » or ×
• Y could be ¥, ý or another variant of U
• Z could be « or ž or another variant of A

So I think my proposal makes it possible to efficiently input the following languages: (example mappings are given to show that it is possible, obviously it is a matter of taste where exactly you map the extra letters, these are just my suggestions)

• English (duh)
• German: map äöüß to Meta+AOUS
• French: map éèàçùœ to Meta+ERACUO and perhaps dead circumflex/diaeresis if you're not happy with the default (Shift+> for dead circumflex, Meta+" for dead diaeresis)
• Spanish: map ñáéíóú to Meta+NAEIOU
• Portuguese (also Brazil): same as Spanish, plus çâêôà for example at Meta+CSRIQ. Or use default dead acute for áéíóú, and map ñçâêôà to Meta+NCAEOQ
• Italian: map àèòùéç to Meta+AEOURC
• Dutch: no remapping needed, just use the default dead diacritics or Compose when you need áéíóúäëïöü or other accents
• Danish/Norwegian: map åøæ to Meta+AOE
• Swedish/Finnish: map äöå to Meta+AOS
• Turkish: map çşğıöü to Meta+CSGIOU
• Estonian: map äöüõ to Meta+AOUI
• Faroese: same as Danish plus Đ at Meta+D
• Polish: map ąęóśćńłźż to Meta+AEOSCNJXZ
• Romanian: map âăîşţ to Meta+AQIST
• Slovak: map ôäĺŕčšž to Meta+OALRCSZ use the default dead acute (Meta+') for long vowels
• Hungarian: map áéőű to Meta+AEOU and use the default dead acute and dead umlaut for óúöü
• South Slavic (Bosnian/Croatian/Serbian/Slovene): map Кžč to Meta+DSZC

The following default mapping could be provided (but I would prefer it not to be labeled!):

• A to Ä
• O to Ö
• U to Ü
• S to ß
• E to €

to cover German,

• C to ç
• Q to à
• W to è
• R to é
• Y to ù
• V to dead circumflex

to cover French and Portuguese,

• N to ñ

to cover Spanish,

• I to ò
• J to ì

to cover Italian,

• Z to Å

to cover Swedish,

• D to Æ
• F to Ø

to cover the rest of Scandinavia.

This default mapping would cover pretty much all of Western Europe and the two Americas.

 

[codifies]

I agree the less on the keymat the more flexible it is - by putting a character on a keymat key you in effect fixing its function in concrete

unlabelled characters could be shown with an overlay screen when a modifier key is pressed, but I still favour some kind of interchangeable physical overlay "card" (thin plastic) this would allow users to customize blank ones for whatever exotic keymap (like DOSbox etc) they choose

props to _wb_ for the comprehensive world wide round up of diacritic's ! but then he does come from a country that seems to speak at least 4 languages routinely (at least in the tourist traps like Bruges !)

 

[WizardStan]

by putting a character on a keymat key you in effect fixing its function in concrete

The counter argument is that by putting a character on the keymat it makes it easier to remember what you've changed the function to. Like "I replaced the yen symbol with an accented A" or something. There's good reasons on either side for whether to more fully populate keys or not.

 

[blip]

I don't think it's a good idea to let the Pyra keyboard try to look completely like a standard keyboard for which you can use standard xkb layout files, because it simply is not a standard keyboard.

What's a standard keyboard ? a 104 ANSI, a 105 ISO, a 109 JIS, a Tenkeyless, a 70%, a 60%, a 40%, a thumbshift, an Apple keyboard, an Ergodox ? There is no norm, no standard, just some consensus more or less followed by manufacturers since the 60's IBM modern typewriters (like the odd 2 right hands row shape instead of the early "brick wall" shape). Only the keycodes assignment is a standard and every keyboard follows them.


If you want to make a "azqwertzy-international" make a classic legacy us-qwerty layout, with all the standard keycodes provided, that let the layout easy to change with xkb. It will make less work to import the layouts than to rewrite them.


There is no unique layout that suits every language, even with concentrating your effort on Roman alphabet only : it will be extremely suboptimal. Bépo is a great exemple of what it's possible to do with dead letters, it covers a lot but not efficient at all and focused primarily on French language and typography. Colemak did a multilingual layer too but very limited. In such a keyboard, if you don't work with more layers like Neo v.2 does or dead letters like acute, agrave, dead_cedilla or dead_macron you have no chance to cover such different languages as Spanish, Türkish, Icelandic and Czech.


It's the same for programming : every language has its own syntax and PHP or C++ or Perl or sh developers have particular needs.


As I said, the perfect layout is the one you made to suit your needs so let people make their own.

 

[Neelix]

by putting a character on a keymat key you in effect fixing its function in concrete

The counter argument is that by putting a character on the keymat it makes it easier to remember what you've changed the function to. Like "I replaced the yen symbol with an accented A" or something. There's good reasons on either side for whether to more fully populate keys or not.

I don't really buy that argument...  Each key will already be labeled in some way regardless.  using an arbitrary symbol as a marker for another symbol seems somewhat counter productive to me, and since it would have to be done as a modifier combo anyway it seems to me it would be just easy to remember  that "À is on Fn+L"  as "À is on the Yen symbol"
- Neelix

 

[WizardStan]

Also a good counter-counter-argument.

 

[codifies]

by putting a character on a keymat key you in effect fixing its function in concrete

The counter argument is that by putting a character on the keymat it makes it easier to remember what you've changed the function to. Like "I replaced the yen symbol with an accented A" or something. There's good reasons on either side for whether to more fully pollute keys or not.

fixed your typo for you...

once something is on the keymat it cannot be changed, and there will probably only ever be one keymat...

easier to remember where the á is if you have written á on a removable template over the A key, or are using a pre-printed tempate with an á above the A or you have the Spanish version of the case with á printed on it

If á is on the keymat then its there in the way for all the other people in the world who don't need an á and its a keymap forced on the whole world forever....