F104+SSK+122+62+77+50+Ergo orders now open! New Kishsaver+Industrial Model F Keyboards

[Ellipse]

Here's the new production Hebrew set that is available thanks to Zed making it. It is installed on an F122 (also pictured are some original IBM keys, per the poster):
https://www.reddit.com/r/MechanicalKeyb ... _math_pad/

Are we missing any major IBM sets at this point? Or any other sets outside of APL?

[robo]

I imagine one other thing IBM had over Ellipse's operation, aside from, you know, having the resources of IBM at its peak, vs being one person, is that they presumably shipped their keyboards with keys installed, which seems to be important for keeping springs and flippers in place during the tumbles of shipping etc. and allows for testing of the board as it will be used by the customer.

[Jan Pospisil]

Oh, got my shipping email! Nice.
Ellipse, is there any news on the possibility of additional language sets? I know Zed was busy the last time I asked, but it's been a while.
(asking about Czech)

[Daniel_CH]

Received my F77 this morning, a little under a month after I placed my order, and 9 days after receiving my shipping notice.
Being in Europe, and considering how much demand there is for a single man to ship out, I was optimistically hoping for a 3 months wait, but I was ready for 6 (maybe more). So, on that front, I'm already extremely surprised, and pleased.
Everything was packaged as expected, and in perfect condition.

The key installation process was pretty much what I was prepared for. I had to work with a few of the springs (following the instructional video found in the online manual) for some buzzing and a couple that refused to buckle initially. Some still sound like they're buzzing a little, but I'm giving it a few days to break them in and see if it resolves on its own before doing more work.

During the first hour of usage, I noticed that if I pressed d and s really quickly in succession, it would sometimes come out "sd" instead of "ds" (I first noticed that while typing "words"). I then noticed the d key wouldn't always repeat properly. Turns out, it would only activate when released, instead of pressed. Working a bit on the spring and reinstalling the key a couple times seems to have fixed that issue entirely. Found out the j key had the same issue a bit later, fixed the same way without further problems.

I am not entirely convinced with the feel of the space bar so far. I did some adjustments, but it's not quite there yet. I'll have to see if a bit of lube can improve it, maybe doing more adjusting of the bar or metal tabs.
I also have an issue with right shift "grinding" a bit, as well as a "lazy" backspace. Both are using horizontal stabilizers, and I'm wondering if they are part of the issue. Is it possible that I have pushed them too far in? Or not enough? Any suggestions would be appreciated.
Right shift "grinds" regardless of where I press on the key. It's almost hard to press down if I hit the side edges of it. Thankfully I never use it, but the issue is there.
Backspace, on the other hand, feels perfect if I hit it on the spring side (right), but not so much when hitting it on the stabilizer side (which is unfortunately where my finger lands when typing). It feels a bit "mushy", if that makes sense. Maybe that's just how it is with these horizontal keys, but I'd still love to make it feel a bit better.

Other than that, the first hour of use, and the subsequent typing of this message, were both fantastic experiences, and I'm very happy with my purchase.

[Ellipse]

Daniel_CH please look through the manual - troubleshooting section to see the "wiggle" method to adjust the extra wide keys.

[sedevidi]

I finally had my F77 delivered, and I'm very happy with it!
I flashed NathanA's Vial firmware, and I'm very impressed too!
I now have to accustom myself to this new layout...
A few things:

• the firmware apparently just crashed for no apparent reason; un-plugging the keyboard rebooted it

• I'd like to setup the numpad as per "layout 3" on Ellipse's website, and I discover (Linux) that Shift + direction does not "extend the selection" but "switches to numeric"... I'll search for the proper QMK setup for this; any pointer appreciated...

A happy new owner!

[sedevidi]

Ah, nearly forgot about Vial app (fresh 0.5.2). As I understand it, everything is saved inside the keyboard, and reloaded when openning the app.
The specific layout is apparently saved, except for the "split backspace" option: split right/left shift and Enter style are restored, but not the split backspace checkbox. The key value is OK though when re-checking that box.

[HatefulLight]

Hello! I have finally received the F77 I ordered in 2018. I managed to get through the hell of fixing a non-responding enter key (the only key on the keyboard to do this), only to find I don't really understand how the keymapping works. I was under the impression that the keyboard would have been programmed to work with my chosen numpad (block 4), but it is not (it is instead set up for printscr/arrows/etc). From looking at the QMK generator website, I cannot figure out how to set up the layers to work with numlock the way I imagine they should (numlock is pressed once, now i have the numpad). Could someone please give me a file that is set up correctly for a regular layout F77 with numpad 4 (image below to verify layout)? I have not yet updated any firmware, but have confirmed that I run QMK (the pandrew QMK utility works).

Very excited to finally use this!

[NathanA]

• the firmware apparently just crashed for no apparent reason; un-plugging the keyboard rebooted it

Interesting; I'd definitely be interested if this keeps happening to you. I have only experienced instability when trying to build firmware from newer copies of Vial (checked out from git 'master' anytime within the last few months), which is why to-date I have kept the Vial firmware builds for New Model F at roughly the version 0.4.1 level (though as you noted later, newer versions of the Vial app have no problems working with this older firmware; that said, of course any newer 0.5.x features won't be available).

The symptoms when I have seen crashes or other weird behavior with fresher Vial codebase make it appear that certain Vial features (namely, Tap Dance and/or Combos) and pandrew's capsense matrix code are scribbling over each other's memory spaces. Those specific Vial features don't even have be actively used, just enabled in the build. So far I've been unable to get to the root of the issue, but to I'd love to chat with pandrew about this sometime...it would be nice to be able to keep up New F Vial firmwares with progress that's happening in Vial core development.

All that said, I have been "dogfooding" my own Vial hex files for many months now, and they have been perfectly stable for me...

• I'd like to setup the numpad as per "layout 3" on Ellipse's website, and I discover (Linux) that Shift + direction does not "extend the selection" but "switches to numeric"... I'll search for the proper QMK setup for this; any pointer appreciated...

Not entirely clear to me what you mean...are you saying that you expect Shift + any number pad key to always result in a nav action (+ of course expanding selection due to Shift) regardless of the state of Num Lock? Because assuming Num Lock is on, Shift + a numpad key is still going to result in a number, not a nav action. [EDIT: I'm wrong! See further discussion in later posts!]

If you're saying this is happening while Num Lock is for sure off, though, then not 100% sure, but it almost sounds like your Linux is configured to ignore state of Num Lock if you activate a number pad key with a modifier. It is of course entirely the OS's prerogative what to do when particular scan codes are encountered; for example, going back to its classic origins, even modern macOS has no concept of "Num Lock" & the numpad always generates numbers and never nav actions, which as I recently learned makes F77 block option #3 extremely inconvenient on a Mac. Turns out I use the nav commands more often than the numbers on the numpad, and so to avoid having to continually change key mappings within the keyboard firmware when switching between Mac and Windows, I had to remap the keys at the OS level on my Mac to do what I wanted (nav default / as if Num Lock is "off"). But without Num Lock, I now have no way of toggling between nav commands and numbers with just the press of a single key.

A quick Google on my part unearthed this SO / AskUbuntu post, where someone describes a problem eerily similar-sounding to yours, implying this isn't actually the F77's fault but has something to do with how the OS itself is configured. Might be worth a look: https://askubuntu.com/questions/57079/x ... ke-windows

The specific layout is apparently saved, except for the "split backspace" option: split right/left shift and Enter style are restored, but not the split backspace checkbox. The key value is OK though when re-checking that box.

Yes, this is a known issue, although I thought it was previously discussed in this thread but cannot find it now (it may be that I only addressed it with somebody else via PMs).

It actually has nothing to do with Vial: the same problem also happens in the VIA app, and it happens in both the VIA and Vial apps regardless of whether you use VIA or Vial firmware. It also only happens on the F77, and not on the F62. I can reproduce the bug as far back as darkcruix's original VIA firmwares, so it has actually existed since the beginning. It's not clear to me if this is a VIA firmware bug on the keyboard (remember that at the firmware level, Vial is built on top of / is dependent on lots of VIA code), or some problem with the composition of the VIA JSON keyboard definition for the F77, but I also haven't taken a lot of time to debug this yet. As you noted, it works fine and is merely a weird cosmetic bug (you have to recheck the box after restarting the app every time you want to change that extra key).

[NathanA]

I was under the impression that the keyboard would have been programmed to work with my chosen numpad (block 4), but it is not (it is instead set up for printscr/arrows/etc).

F77 right block options #1 and #2 are the only official ones that Ellipse has ever offered for out-of-box use...you could order either of those, and your keyboard would come preconfigured/preflashed with the firmware config matching your preferred layout. #s 3, 4, and 5 were dreamed up by forum members here after the fact. Ellipse agreed to have keycaps with those legends produced, but never actually offered those as officially orderable layouts, and it was always understood that it would be the keyboard owner's responsibility to figure out how to make one of those layouts actually work. I always thought this was pretty clear given that you could easily pick #1 or #2 when ordering a keyboard (no muss, no fuss) & the keycaps covering both were included with all orders / the default set regardless of which option you picked, but to achieve 3/4/5 you had to order the particular keycaps with the printed legends you wanted separately.

When you ordered your keyboard, the order form for the keyboard itself only allowed you to pick from "0-9 and cursor keys" (option 2), or "Print/ScrLock/Pause/Ins/Del etc. keys + cursor keys" (option 1). It would seem that you must have selected the latter when you placed your order, so that's how your keyboard came preconfigured out of the box. Both your order confirmation e-mail and the packing slip that arrived with your 'board should confirm this.

From looking at the QMK generator website, I cannot figure out how to set up the layers to work with numlock the way I imagine they should (numlock is pressed once, now i have the numpad).

I am honestly not sure how to achieve this strictly with QMK at the present time. Somebody else might have an answer or idea. If you were using block option #3 it would be fairly simple (since it's more-or-less based on the standard and ubiquitous Enhanced/101 keyboard layout's numpad), but #4 complicates things. The problem comes down to that Num Lock is a stateful function whose state is actually maintained by the host (computer), not by the keyboard. This is precisely why if you have multiple keyboards attached to a PC, and you toggle Num Lock on one of them, it is toggled on all of them universally. (The Num Lock key just asks the host to toggle the feature. In actuality, the *PC* tells the *keyboards* whether Num Lock is on or off, not the other way around; the Num Lock LED just reflects the state of the host.) So the host also determines what action should be taken when one of the keypad keys is pressed depending on the state of Num Lock. Since (e.g.) it is standard for keypad 7 to act as Home when Num Lock is off, that's how most PC hosts act (unless otherwise configured). The keyboard firmware itself isn't sending "7" or "Home", it's sending the same scan code for that keypress regardless of whether Num Lock is on or off, and the PC software takes whatever action it thinks is appropriate depending on the state of Num Lock. Thus it isn't really feasible to cause the keyboard all by itself to make the 7 key act as 7 when "real" Num Lock is on but toggle Insert when it's off.

There are two potential ways around this that occur to me.

The first would be to implement this as a function layer on QMK that simulates Num Lock on and off, but doesn't actually change the state of Num Lock on the host. Instead, on the "Num Lock off" layer, you would have the keypad keys send the scan codes for the appropriate keys from the Enhanced 101 layout's nav cluster, and on the "Num Lock on" layer, have the keypad keys send the scan codes for the number keys that normally sit across the top of the alpha block. The problem with this is that QMK doesn't really have a good way of activating a layer for only a subset of keys (a-la emulating Num Lock). You can have upper layers "pass through" to lower layers for certain keys, so you may be able to take advantage of that. But then you'd effectively have to shift up all of your layers by one, reserving an entire layer for one of the two simulated Num Lock states. If I have some free time here at some point, I may take some of it to play around with this idea.

The second would be to simply remap how you want the keys to function within the host OS, instead of within the keyboard firmware: for example, configure Windows to toggle Insert when 7 is pressed with Num Lock off. (Also: don't ask me how to do this or whether it's even possible to do this. I don't know. It may be possible with registry edits, or may require some third-party utility that can actually do this to be installed first.) The downside to this solution is that it won't follow the keyboard if you choose to plug it into a different computer; instead, you'd have to configure every computer you plan to use the keyboard with to do what you want. Also, it would happen regardless of which keyboard you have plugged in to the computer, so you wouldn't be able to have the key function only change if that key was pressed on the F77, but not if it's pressed on some other keyboard that also happens to be plugged into the same computer.

(The double-zero is its own can of worms.)

E: I have also noticed that fn+numbers does not seem to activate the F keys. I assume the right blank key in between right alt and right shift is fn. Am I doing something wrong or is this also not programmed in yet?

I believe that if you ordered a keyboard without split right shift, the right Ctrl key is actually by default mapped to Fn. The blank key in between right Alt and right Ctrl is actually Num Lock. This can be seen on the default layout picture on the F77 ordering page (you'll have to scroll down a bit, well past the actual ordering options and the initial description text).

[HatefulLight]

F77 right block options #1 and #2 are the only official ones that Ellipse has ever offered for out-of-box use...you could order either of those, and your keyboard would come preconfigured/preflashed with the firmware config matching your preferred layout. #s 3, 4, and 5 were dreamed up by forum members here after the fact. Ellipse agreed to have keycaps with those legends produced, but never actually offered those as officially orderable layouts, and it was always understood that it would be the keyboard owner's responsibility to figure out how to make one of those layouts actually work. I always thought this was pretty clear given that you could easily pick #1 or #2 when ordering a keyboard (no muss, no fuss) & the keycaps covering both were included with all orders / the default set regardless of which option you picked, but to achieve 3/4/5 you had to order the particular keycaps with the printed legends you wanted separately.

When you ordered your keyboard, the order form for the keyboard itself only allowed you to pick from "0-9 and cursor keys" (option 2), or "Print/ScrLock/Pause/Ins/Del etc. keys + cursor keys" (option 1). It would seem that you must have selected the latter when you placed your order, so that's how your keyboard came preconfigured out of the box. Both your order confirmation e-mail and the packing slip that arrived with your 'board should confirm this.

Yes, I think I did order it set up for 2, which is convenient for current use at least. I hope the fact that the custom layout was offered means at least one person has figured out a way to use it the keyboard like that and will eventually share that way here.

I am honestly not sure how to achieve this strictly with QMK at the present time. Somebody else might have an answer or idea. If you were using block option #3 it would be fairly simple (since it's more-or-less based on the standard and ubiquitous Enhanced/101 keyboard layout's numpad), but #4 complicates things. The problem comes down to that Num Lock is a stateful function whose state is actually maintained by the host (computer), not by the keyboard. This is precisely why if you have multiple keyboards attached to a PC, and you toggle Num Lock on one of them, it is toggled on all of them universally. (The Num Lock key just asks the host to toggle the feature. In actuality, the *PC* tells the *keyboards* whether Num Lock is on or off, not the other way around; the Num Lock LED just reflects the state of the host.) So the host also determines what action should be taken when one of the keypad keys is pressed depending on the state of Num Lock. Since (e.g.) it is standard for keypad 7 to act as Home when Num Lock is off, that's how most PC hosts act (unless otherwise configured). The keyboard firmware itself isn't sending "7" or "Home", it's sending the same scan code for that keypress regardless of whether Num Lock is on or off, and the PC software takes whatever action it thinks is appropriate depending on the state of Num Lock. Thus it isn't really feasible to cause the keyboard all by itself to make the 7 key act as 7 when "real" Num Lock is on but toggle Insert when it's off.

There are two potential ways around this that occur to me.

The first would be to implement this as a function layer on QMK that simulates Num Lock on and off, but doesn't actually change the state of Num Lock on the host. Instead, on the "Num Lock off" layer, you would have the keypad keys send the scan codes for the appropriate keys from the Enhanced 101 layout's nav cluster, and on the "Num Lock on" layer, have the keypad keys send the scan codes for the number keys that normally sit across the top of the alpha block. The problem with this is that QMK doesn't really have a good way of activating a layer for only a subset of keys (a-la emulating Num Lock). You can have upper layers "pass through" to lower layers for certain keys, so you may be able to take advantage of that. But then you'd effectively have to shift up all of your layers by one, reserving an entire layer for one of the two simulated Num Lock states. If I have some free time here at some point, I may take some of it to play around with this idea.

The second would be to simply remap how you want the keys to function within the host OS, instead of within the keyboard firmware: for example, configure Windows to toggle Insert when 7 is pressed with Num Lock off. (Also: don't ask me how to do this or whether it's even possible to do this. I don't know. It may be possible with registry edits, or may require some third-party utility that can actually do this to be installed first.) The downside to this solution is that it won't follow the keyboard if you choose to plug it into a different computer; instead, you'd have to configure every computer you plan to use the keyboard with to do what you want. Also, it would happen regardless of which keyboard you have plugged in to the computer, so you wouldn't be able to have the key function only change if that key was pressed on the F77, but not if it's pressed on some other keyboard that also happens to be plugged into the same computer.

(The double-zero is its own can of worms.)

Haha, I had no idea this was going to be Non-Trivial. I'm at least glad the keyboard is fully usable and that it's the more useful block of keys that I do have access to. Thank you for your detailed answer! I figured to just make double-zero do some useful function, but I don't know what it would be yet.

I believe that if you ordered a keyboard without split right shift, the right Ctrl key is actually by default mapped to Fn. The blank key in between right Alt and right Ctrl is actually Num Lock. This can be seen on the default layout picture on the F77 ordering page (you'll have to scroll down a bit, well past the actual ordering options and the initial description text).

Yes, I figured this out a little bit afterwards and removed the question. I'm glad is this way, right-ctrl is much easier to hit for this purpose.

[sedevidi]

• I'd like to setup the numpad as per "layout 3" on Ellipse's website, and I discover (Linux) that Shift + direction does not "extend the selection" but "switches to numeric"... I'll search for the proper QMK setup for this; any pointer appreciated...

Not entirely clear to me what you mean...are you saying that you expect Shift + any number pad key to always result in a nav action (+ of course expanding selection due to Shift) regardless of the state of Num Lock? Because assuming Num Lock is on, Shift + a numpad key is still going to result in a number, not a nav action.
...
A quick Google on my part unearthed this SO / AskUbuntu post, where someone describes a problem eerily similar-sounding to yours, implying this isn't actually the F77's fault but has something to do with how the OS itself is configured. Might be worth a look: https://askubuntu.com/questions/57079/x ... ke-windows

That link is apparently the same issue. I found the "Make Shift+NumPad work like Windows" checkbox in the Gnome Tweak Tool, but it doesn't seem to do what I need.
The exact problem is:

• numlock ON: keys type numbers

• numlock ON: shift+keys moves the cursor while selecting

• numlock OFF: keys move the cursor

• numlock OFF: shift+keys types numbers

So: moving the cursor then selecting text implies to toggle numlock in between AND press shift...
I just also noticed that desktop keyboard shortcut using arrows or pageup/down rely on pressing the actual keys from the nav cluster, but do not work with the numpad keys even with numlock OFF.

So I'm thinking about the same solution you thought about above: dedicate a full layer to the numpad numbers, and make numlock toggle the keyboard layer instead of letting the host determine the numlock state. The F77 will then send nav cluster keys when not-pseudo-numlocked, and numpad keys when pseudo-numlocked. Some Fn+NumLock key must also remain somewhere, just in case the host is not in the correct numlock state. I don't know how it could work with other temporary layers (Fn+HHKB alpha keys).

As I understand, memory constraints in the firmware don't allow more than 3 layers, though...

Adding an LED to show the current layer would also help.

[NathanA]

• numlock ON: keys type numbers
• numlock ON: shift+keys moves the cursor while selecting
• numlock OFF: keys move the cursor
• numlock OFF: shift+keys types numbers

Hah, fascinating. But also...that's screwed up. So, I actually had no idea (...never tested it; never had a reason to...) that apparently even in Windows, if you Shift the keypad keys while Num Lock is on, it executes the nav commands. I would not have guessed/assumed that shifting the keypad keys does anything. The difference apparently is that shifting the keypad keys in Windows with Num Lock off continues to output nav commands, and then just modifies them as you would expect (making/expanding selections). (I now wonder if this works the same way going all the way back to MS-DOS, and I just never knew it.)

Why some Linux distros would change that, no idea. Perhaps they figured it would be more consistent if shifting keys affected by Num Lock works both ways, since shifting alpha keys when Caps Lock is on also acts as a negation in the same way. But yeah, with a less-than-100-key keyboard, that's a non-starter.

I actually just managed to get the simulated Num Lock working pretty easily within VIA/Vial. I'll respond to HatefulLight's post with the deets. But, yes: the major drawback is that there is no way for the host to know with this solution whether your simulated Num Lock is actually "on" or not, so no way to display the status of it anywhere. And since the keyboard itself lacks LEDs (at least when stock...), you have no way of knowing whether "Num Lock" is on or off until you hit a key.

EDIT: additional comments

Some Fn+NumLock key must also remain somewhere, just in case the host is not in the correct numlock state.

Eeehh...I mean, you can do that, but honestly why bother. Since your keyboard will never transmit any actual keypad scan codes to the host, does it ever practically matter if "real" Num Lock is on or off? Your keyboard will do exactly what you'd expect regardless of the host's Num Lock state.

I don't know how it could work with other temporary layers (Fn+HHKB alpha keys).

I address this below. Regular keyboard functions stay at layer 0, everything on layer 1 gets moved up to layer 2, and "Fn" key definition on layer 0 is reconfigured to access layer 2 instead of layer 1. Number keypad goes on layer 1 with all other keys set to passthrough to layer 0. So everything works as expected regardless of state of pseudo-NumLock as you call it. The only problem is that it displaces the few kinds of keyboard management functions that were on layer 2 (like bootloader mode, NKRO toggle, solenoid toggle & dwell time adjustments, etc.); you will have to find new homes for the ones you want to keep around.

[NathanA]

Haha, I had no idea this was going to be Non-Trivial.

So making the first option work (simulated Num Lock using QMK layers) turned out to be easier than I thought.

Of course, I did it within Vial. Should also be possible to do in VIA, too, if you prefer. I'm attaching my Vial layout file in case you want to give it a go. To use it, you will first need to download my Vial hex files (first flash eeprom_erase.hex, wait 5 seconds after it's finished, unplug/replug keyboard, then flash the F77 hex file), then download the Vial app, and finally run Vial and then File (menu) > Load Saved Layout... and load in the attached "vil" file (linked at the end of this post).

Default state is Num Lock is off & keypad functions match right block option #4 nav commands. If keyboard gets unplugged/replugged while Num Lock is on, it won't remember that and will default back to nav commands. Since this doesn't rely on the PC's Num Lock status, it will now be impossible for software to either toggle Num Lock or for you to trust what it claims the actual status of Num Lock is on your keyboard (it won't have any way of knowing), so if you forget what state it's in, you won't know whether it's On or Off until you try hitting a key.

This solution should also be reproducible in the web QMK Configurator, too, with the one exception of double-zero: this turned out to be easy to do using VIA/Vial macros, but QMK Configurator doesn't let you define simple macros. If you wanted to do a double-zero key with pure QMK, you'd have to set up a working build environment first and then edit your keymap.c file directly to define said macro before compiling your hex.

Implementation is simple: layer 0 is default layer with all key functions and with the right block set up to transmit the nav command keys. "Num Lock" key is set to TG(1) to toggle layer 1. Layer 1 has all keys fall through to layer 0 (including Num Lock...don't set that to TG(0)...I tried that & it doesn't work) except for the keys in the keypad that should transmit numbers instead, which you need to set to the top-row-above-alpha numbers, not to the numpad numbers (otherwise "real" Num Lock would have to be on for them to transmit numbers!). Everything that was *previously* on layer 1 is moved to layer 2, and whatever key you want to use as Fn on layer 0 has to be changed from MO(1) to MO(2). (Also, set Spacebar on layer 2 to blank instead of MO(2) which is now nonsensical.)

Since while running Vial with all features there isn't enough memory in the controller for more than 3 layers, the few kinda "QMK-meta" keys (like restart in bootloader mode, etc.) can no longer exist on their own layer. So you will have to find some spare keys on the 3rd layer (actually called layer 2, since layer numbers start at 0) to put those on. Previously bootloader mode was set to 'R' for Reset, but you probably don't want to risk accidentally tripping that while trying to engage your Fn layer for everyday tasks. In the layout file that I attached, I chose to put bootloader mode and NKRO toggle on the keypad - and + keys respectively, which should be well out of harm's way. So with this layout, you would now hit Fn and keypad - to get to bootloader mode instead of Fn + Spacebar + R.

Also, since Num Lock is now occupying the space it is assigned in right block option #4 (upper-left key of keypad), the right blank key between right Alt and right Ctrl is now free. So in this layout, that key is now Fn and right Ctrl is an actual Ctrl key.

Getting this working helped me out, too, since now using this keyboard while plugged into a Mac is not nearly so painful...

Hope this helps & have fun!

[NathanA]

...oh, also in other "TIL" news, until I did some poking around today in Vial, I had no idea that QMK has a built-in version of the Esc key that sends ~ when you press Shift+Esc.

This. Changes. Everything.

...no, really. It is clearly super difficult to change years of established muscle memory...

(I presume it would be possible to craft some complex QMK formula that does this, but it's extremely convenient that this just exists out-of-the-box, so to speak.)

[Jean-Loup]

I just received my F77 ISO (UK) keyboard last week, ordered in Feb 2017! I didn't realise that I'd have to assemble all the keys on the keyboard myself, I genuinely believed the keyboard was shipping entirely pre-assembled. I hope to get time to put my keyboard together next month and would like to order a few extra keys and make a custom layout. I mostly use MS Word, Markdown or LaTeX, but have no knowledge of hardware, software or programming, and I know nothing about flashing keyboards.

I am considering ordering a few extra keys and hope to make a custom keymap to mimic my ISO-UK Macbook Pro's layout, with just a few little tweaks (cf. my ugly collage picture of my draft layout) Just to quickly see which keys I want to order and how the configuration works, I headed to Purdea Andrei's QMK Configurator website and selected the layout: ISO_hhkb_split_shift_regular_backspace (see picture)

I have then configured the KAYMAP using a mixture of the ANSI and the ISO KEYCODES (see picture) to make the Keymap appear how I wish to use it.

QUESTIONS TO THE COMMUNITY

1. I have a key as part of my F77 purchase that I do not see in Andrei's QMK configurator - the number 2 key in the number row with @ and € symbol (FYI - identical to the number 2 key on my UK macbook laptop), but I don't see any equivalent option on the QMK configurator. Is this a known issue with the QMK configurator? I don't even see the € symbol anywhere on the configurator website...?

I've just watched:
- MechMerlin's video "QMK Tutorial: QMK Configurator" at: https://youtu.be/-imgglzDMdY
- and MechMerlin's video "QMK Tutorial: QMK Toolbox (Flashing Firmware On Your Keyboard)" at: https://youtu.be/fuBJbdCFF0Q

2. Can anyone vouch for the ease and accuracy of following this step-by-step video guide for a complete newbie using Andrei's QMK configurator on a f77 and a Mac?

3. Okay, so on a keyboard on a Mac, how do you activate a "layer"? (as in the QMK programmable layers...) Sorry, this feels like it must be such an obvious question, but I truly don't have a clue.

4. How would I program the numbers row keys to act as function keys? So that when I press fn + 1 = F1, Fn+2 = F2, etc?

The idea of installing keys and flashing the board myself scares me a bit, especially after reading some nightmare stories and videos like Chyrosan's. I'm hoping that Andrei's QMK configurator and the MechMerlin videos have paved the way to painless and beginner-friendly configurations. I guess I'm looking for a little reassurance from the community.

Cheers!

[Daniel_CH]

@Jean-Loup

I can vouch for the key installation being a relatively quick and painless procedure, as long as you follow the instructions and take a moment to check Ellipse's videos on the topic. It took me about half an hour to get the board filled and adjust a few of the springs.

As for the firmware, I haven't touched it and don't plan to, but there's plenty of recent information in this thread, and it's apparently impossible to brick your board past the point of recovery, so I'm sure you'll be fine.

Daniel_CH please look through the manual - troubleshooting section to see the "wiggle" method to adjust the extra wide keys.

I somehow missed that part of the manual. It helped! Thank you.

[NathanA]

First off,
`

sohot.jpg (43.41 KiB) Viewed 25197 times

QUESTIONS TO THE COMMUNITY

Before getting into them, since we are going to be talking about key outputs & remappings & layers, a quick keyboard primer would probably be helpful:

When you press a key on a keyboard, like say the '1' key, the keyboard isn't transmitting (the ASCII or Unicode encoding of) a literal number 1. Rather, it's telling the computer that "the key that is (as us mere humans would describe it) the second key from the left in the top row got pressed". At that point, the (software on the) computer has to decide how it is going to respond to that particular key getting pressed. Generally, it responds by outputting a numeral 1. But it doesn't have to: that's just conventionally what most do, because that's the legend that is printed on that key cap on most keyboards. But the computer software could be reprogrammed to do something different in response to that particular key getting pressed.

Likewise, you can also (re)program a keyboard to tell the computer that a different key got pressed than the one that actually did: you could (in a sense) tell the keyboard to "lie" to the computer and say that the 3 key got pressed instead of the 1 key. The computer wouldn't know, so from its perspective, you pressed 3 when you actually pressed 1. (I mean, at the end of the day, what's printed on the key and what spot on the 'board you put that key cap on is arbitrary, right? But generally speaking, most reasonable people want them to match up as well as be located in a relatively sane arrangement. )

So the determination re: what happens when a given key gets pressed is a result of a combination of both the keyboard and the computer taken together, not strictly one or the other.

That said...

1. I have a key as part of my F77 purchase that I do not see in Andrei's QMK configurator - the number 2 key in the number row with @ and € symbol (FYI - identical to the number 2 key on my UK macbook laptop), but I don't see any equivalent option on the QMK configurator. Is this a known issue with the QMK configurator? I don't even see the € symbol anywhere on the configurator website...?

Just because none of the software that configures the key mappings is aware of that particular character doesn't mean anything. If you press the '2' key on your Model F, it is going to send the exact same sequence to the computer that the laptop's built-in keyboard sends if you press its '2' key. From the computer's perspective, it's the exact same keystroke that happened, regardless of the source. Thus, any modifiers that you add to that keystroke will also behave identically: if you have told macOS that you are using an ISO UK layout keyboard, and Option + Shift + 2 or Option + 2 (or whatever the combo happens to be) normally causes the computer to output the Euro symbol, the same thing will happen when you press whatever key on your Model F you've configured to be the '2' key. The decision to output that symbol when that particular key sequence is seen is a decision that macOS is making, not your keyboard.

2. Can anyone vouch for the ease and accuracy of following this step-by-step video guide for a complete newbie using Andrei's QMK configurator on a f77 and a Mac?

I just watched them, and I'd say yes: those are generally correct. In particular, QMK Toolbox is absolutely the right solution for flashing a QMK-capable keyboard on a Mac for sure. The things I would add and the caveats I'd give would include:

• The MCU on the controller for this keyboard is the ATmega32u2, not the more common u4. Make sure to choose correctly.
• You cannot force this keyboard into bootloader mode using either the "Bootmagic" or "Bootmagic Lite" methods that the second video shows. Depending on what firmware it is running, you may be able to use LShift + RShift + B while the keyboard is plugged in, or there may be another key sequence that has already been mapped to "bootloader mode" like Fn + Spacebar + R is on most stock 'board firmwares from Ellipse. Or you may have chosen a different combo whenever you last configured the keyboard.
• If no key sequence seems to kick the keyboard into bootloader mode, you can try to see if the pandrew utility can detect it, and if so, use it to force the keyboard into bootloader mode.
• If all else fails, this keyboard does not have any kind of reset "button" on its circuit board as the video discussed. Instead, it has 2 open pads that need to be manually shorted together while you plug the keyboard into the computer. Ellipse's manual on his site has more information, as do posts further back in this very thread.

If I were you, though, I'd strongly consider flashing either VIA or Vial firmwares to your keyboard. They are (two different variants of) QMK-based firmwares that give you the added benefit of being able to change keyboard config/key mappings without reflashing every time you want to make a change: instead of going to a web site, compiling and downloading a hex file, putting your keyboard into bootloader mode, and then flashing it, you just run an app on your computer that lets you change your keyboard layout in real-time. You flash your keyboard once, and then after that never have to flash it again (unless e.g. a firmware update comes out that fixes a bug that's annoying you).

3. Okay, so on a keyboard on a Mac, how do you activate a "layer"? (as in the QMK programmable layers...) Sorry, this feels like it must be such an obvious question, but I truly don't have a clue.

Part of the answer is that it has absolutely nothing to do with whether you have a Mac or not...that part of the equation is absolutely immaterial and doesn't change the answer to the question in the slightest.

This again goes back to the first principles I opened with. A "layer" in QMK is just a way of being able to have more available keys to press than you have physical keys that are present on your keyboard. You can think of them as "virtual" keys, if that's at all helpful. You designate a particular key as a special modifier key that causes QMK to select a different "layer" when you press it. At that point, if you press another key while holding down that layer-selecting key, the function of the key you press can be completely different than if you weren't pressing the layer-selecting key. So for example, you could configure a second "layer" of keys on your keyboard where the spot that is normally occupied by the 'B' key causes the keyboard to instead send a Tab. You can then configure QMK to use Caps Lock to select this second layer. Then if you press Caps Lock + B, the keyboard sends the same code to the computer that it would send if you pressed the actual Tab key.

This is a rather mundane example of course, just to explain the concept. Where it can become truly useful -- especially in the case of a keyboard with fewer-than-average keys on it like the F62 or F77 -- is that if there is a key that you just can't live without but for which there is no open spot, you can stick it on a second layer and access it that way. Or you can map a macro that's built into the keyboard to keys on the second layer, etc.

The crucial way that this whole concept differs from when you're using other common modifiers like Shift / Control / Option / Command / etc. is that the computer knows and is aware that those other modifier keys are being pressed, and the computer is involved in determining what happens when you employ a key chord that includes one or more of those modifiers. But the key you designate to select a QMK layer doesn't send a key-down event to the computer. 100% of what's taking place there is taking place wholly within the keyboard alone, and the computer has no idea that additional key is being pressed. So in the above example, if you make Caps Lock your select-2nd-QMK-layer key, not only is it no longer acting as Caps Lock, but your computer has no idea that Caps Lock got pressed when you did Caps Lock + B. From the computer's perspective, it only saw Tab happen. Not some analogue to Shift + Tab or Caps Lock + Tab or (Mac) Fn + Tab ...just plain ol' Tab.

4. How would I program the numbers row keys to act as function keys? So that when I press fn + 1 = F1, Fn+2 = F2, etc?

This is exactly where the QMK layers thing comes in handy: as noted, there is no dedicated function row on this F77 keyboard, and real-estate on a board with fewer keys on it is valuable. So: if you don't want to lose additional keys on your keyboard (like for example the right 3x5 block of keys) to act as dedicated F1-F12 keys, you instead put F1-F12 on a second QMK layer, and naturally the top number row is a great place for that. Once you pick a key on the 'board to be your QMK "Fn" (second-layer-select) key, you press that key plus the appropriate number key to get the keyboard to output F-whatever to the computer.

The default layout that Ellipse pre-loaded onto your keyboard should already have this set up for you, but if you compile a new QMK firmware for yourself, you will have to reproduce this if you want to maintain it. If you didn't get Split Right Shift option, then by default the key normally labeled Ctrl on the bottom-right is acting as QMK second layer select ("Fn" for short). So you'd press RCtrl+2 for F2 out of the box. If you have a Split Right Shift, the key to the right of Shift is your QMK "Fn" key by default.

Note that "Fn" in this context has nothing to do with the key marked Fn on your MacBook's built-in keyboard, whose sole purpose is pretty much to allow you to use the top F1-F12 row to either act as actual F-keys or to act as the shortcuts for certain system functions (volume up/down, screen brightness, etc.). As far as I know, there is no way to duplicate that key within QMK. Would love to know if I'm wrong...

Hopefully this is starting to "gel" for you now a bit after reading all of this, and now that you know some of this stuff, it may influence how you've been thinking to re-arrange your keyboard. For example, you didn't designate any key (at least that I can see) to be a (QMK) "Fn" key, which I dare say is going to make your life more difficult! (In QMK parlance, the layer select key is called "MO" for MOmentary layer select [only is selecting the layer as long as it is being held down]. Layers are zero-index, so the 1st layer is layer 0, the 2nd layer 1, etc. Layer 0 is the "default" layer and is what you do all of your regular key mapping on. To program a key to act as the second-layer-select, you would configure the action for that key to be MO(1) for MOmentarily select layer 1. The MO(x) key function is located under the Quantum tab of QMK Configurator.)

Congrats if you managed to read through all of that, and hope this helps.

[NathanA]

Note that "Fn" in this context has nothing to do with the key marked Fn on your MacBook's built-in keyboard, [...] As far as I know, there is no way to duplicate that key within QMK. Would love to know if I'm wrong...

Well, quickly Googled it, and here is a fascinating post about the subject, along with further interesting discussion in the Github issue that is linked to at the end.

So it turns out the answer is (a very qualified) yes...so for most people, no.

[sedevidi]

So making the first option work (simulated Num Lock using QMK layers) turned out to be easier than I thought.

I followed your detailed instructions, and re-did the same with my initial setup, except aiming for block #3, and the added difficulty that in my locale, the number row needs shift to output numbers, so... I had to use true numpad number keys in the numpad number layer (which is kind of logical).
The downside is that I need to make sure the host is in numlock state, or the direction keys are no numbers, and subtly different: eg. nav cluster PgUp vs. numpad non-numlock PgUp, which work in a text editor or Firefox, but not as desktop shortcuts. I thus added KC_NUMLOCK on the numlock key in layer 2 (Fn+Numlock will toggle system numlock state).
And also added numpad number keys at their location in layer 2: Fn+2 is thus "2" in both default layer and navcluster layer 1.
The keyboard is now very much like I wanted it. A bit more easy tuning with Vial, and I'll be OK (I just need to get used to the split backspace, which I apparently hit on the "Del" side more than I anticipated, and the large spacebar, which makes AltGr a long way on the right).
I also fixed a little problem in your initial settings: LGUI was mapped to nothing in layer 1 (Fn), rendering a key combo needing LGUI + some other key triggered with Fn non-working. Changing LGUI to KC_TRANS (transparent) made the combo work.
Thanks to all!

[Ellipse]

PS/2 support for xwhatsit controller:

I read in the AT90USB162 datasheet "USB pad multiplexed with PS/2 peripheral for single cable capability" - it would be cool if it had ps/2 support! Would that be possible to do with one of those passive USB-PS2 adapters that used to come with some computer mice, even if the controller has a USB-C connector?

How easy would it be to adjust the current controller to make a dozen or so ones with this chip instead of the ATMEGA32U2 chip? Per pandrew: this chip has "16k of flash memory. Qmk firmware currently uses around 22k. That's not to say it's impossible. It's probably possible to strip away many QMK features and get it working, but it won't be great."

I think the tradeoff in some additional functionality would be worth it to the folks who strongly prefer PS/2 connectivity.


Great work NathanA on getting the layer tap functionality figured out to support the additional right side blocks in a better way than having to hold down Fn+ the right side block key to activate the relocated "Ins/Del/etc." functionality of these other blocks. Hopefully this functionality is also easy to implement in QMK. If anyone has tested this QMK tap functionality on their new Model F please do share!

[NathanA]

[...] except aiming for block #3, and the added difficulty that in my locale, the number row needs shift to output numbers, so... I had to use true numpad number keys in the numpad number layer [...]
The downside is that I need to make sure the host is in numlock state, or the direction keys are no numbers, [...] I thus added KC_NUMLOCK on the numlock key in layer 2 (Fn+Numlock will toggle system numlock state).

I had no idea AZERTY required Shift to be applied to get numbers from the top row number keys!

Just to be clear: you have "Num Lock" key set to TG(1) on layer 0, but set to actual Num Lock on layer 2, so you have to press both NumLock followed by Fn+NumLock to get numbers from the keypad? (After you do Fn+NumLock once though, it should remain enabled, so then you can toggle back and forth between numbers and nav commands just by pressing NumLock?)

You actually don't need to do all this to get working pseudo-NumLock, even with French AZERTY. You can have single keys send modifiers along with the assigned keystroke, so instead of using keypad 1, you can use top row 1 but have Shift be applied to it automatically so that you get a number. You don't even need to use macros to do this.

Here is a screenshot of Vial configured with a numpad layer without requiring "real" Num Lock that I think should work for AZERTY:
`

azerty-numpad.png (26.72 KiB) Viewed 25008 times

`
To set the keys with the Shift modifier applied to them, I just used the built-in keys in the Vial list that show the shifted values for the top number row in a QWERTY context, which I highlighted in red...using these applies the Shift modifier for you automatically (e.g. the '!' key is Shift+1 because on a QWERTY keyboard Shift+1 is how you get '!'). But you can also manually edit any key in Vial simply by double-clicking it, which will give you a text box that you can use to type in the exact QMK key value you want sent when that key is pressed. You can see in the screenshot that all of the key values for the numbers are a "box within a box"...outer box is the modifier (LSft in this case for Left Shift) and inner box is the key being modified.

One thing that wasn't clear to me when I was putting together this example is how AZERTY handles the full-stop (.) key on the numpad. I thought France used decimal commas, but every example picture I could find of an AZERTY keyboard shows a period key in the numpad area instead of a comma. Does that key actually output . or does it output , even though the legend on the keycap is a . ?

In my example from above, I put the regular comma key in that spot. But if you want it to output a period/full-stop instead, then you can substitute as appropriate. On AZERTY it appears that . is achieved in the alpha block area by Shift+; so you will have to apply Shift modifier to that key just like with all of the numbers. However, since QMK is QWERTY-centric internally, and since the ; and . key on AZERTY is in the same place as the < and , key on QWERY, you need to set that to KC_COMMA to get the right key. Thus the full key definition would look like this with the Shift modifier applied:
`

azerty-numpad-period.png (2.83 KiB) Viewed 25008 times

`

I also fixed a little problem in your initial settings: LGUI was mapped to nothing in layer 1 (Fn), rendering a key combo needing LGUI + some other key triggered with Fn non-working. Changing LGUI to KC_TRANS (transparent) made the combo work.

I'll go check it out, but all of the layout/keymap files that I included were directly derived from the ones that Ellipse includes in his firmware package; I didn't create any of those. But yes: if you need a particular key to respond just like it would normally respond on layer 0 while you are holding down Fn, you need to set that key to KC_TRANS on the Fn layer.

[NathanA]

PS/2 support for xwhatsit controller:

I read in the AT90USB162 datasheet "USB pad multiplexed with PS/2 peripheral for single cable capability" - it would be cool if it had ps/2 support! Would that be possible to do with one of those passive USB-PS2 adapters that used to come with some computer mice, even if the controller has a USB-C connector?

How easy would it be to adjust the current controller to make a dozen or so ones with this chip instead of the ATMEGA32U2 chip? Per pandrew: this chip has "16k of flash memory. Qmk firmware currently uses around 22k. That's not to say it's impossible. It's probably possible to strip away many QMK features and get it working, but it won't be great."

I think the tradeoff in some additional functionality would be worth it to the folks who strongly prefer PS/2 connectivity.

I actually looked into this a while back, because I was interested in making it possible to use my F77 with older PCs. My question was whether it was possible to "bit-bang" the PS/2 protocol on the USB pins of the ATmega##uX MCUs to do exactly this (use a passive USB-to-PS/2 adapter).

The short version is that, you and pandrew are correct: it is not possible to do this with the AVR variants that have built-in USB. It is possible to do with AT90USB162. HOWEVER: the big problem is that QMK has zero support for acting as a PS/2 keyboard. It can support adapting a PS/2 mouse to USB for (apparently) certain USB keyboards that have a PS/2 mouse port on them, but cannot directly present a PS/2 device on the PS/2 bus.

The solution is likely to use a different open source keyboard firmware project called 'ps2avr' (https://sourceforge.net/projects/ps2avr/) which is made to do exactly this: make non-USB AVR variants talk PS/2 protocol to a host. This means that you would get none of the QMK features though, and the keyboard would ONLY support PS/2, not both PS/2 and USB simultaneously...though in theory you should be able to have a ps2avr firmware for PS/2 support and a separate (stripped down) QMK firmware for USB support, and then flash from ps2avr to QMK if you need to use it as a USB keyboard (and vice-versa when you want to go back to PS/2). Also, either pandrew or someone else would also have to take the time to port the pandrew capsense stuff from QMK to ps2avr, and I don't know what the relative difficulty level of that project would be.

I believe the AT90USB162 is basically pin-compatible with ATmega32u2, so it shouldn't require too many changes to the existing PCB design to change the MCU. But yes, it is unfortunate that it has half the memory of the 32u2. I believe there are non-USB versions of ATmega that have the same 32K of memory (e.g. ATmega32A) that would also be compatible with ps2avr firmware, but those are not pin-compatible with the 32u2, so the PCB would likely require some adjustments to the design to accommodate one of those.

For my own uses, I ended up buying an active USB to PS/2 adapter. Yes they exist, but there aren't many of them, they are expensive, they are hard to find, and they aren't always compatible with 100% of USB keyboards or 100% of PS/2 hosts.

The one I bought was this one, but when I bought it, it was "only" $75, and it looks like the price has gone up since then. I can confirm that it works with my F77 running QMK...but ONLY as long as I have a QMK firmware flashed to my keyboard that was built WITHOUT the MouseKeys feature included. Something about the QMK MouseKeys feature really confuses this adapter (probably something to do with the particulars of how QMK is presenting both a keyboard and a mouse simultaneously over the USB bus).

Great work NathanA on getting the layer tap functionality figured out to support the additional right side blocks in a better way than having to hold down Fn+ the right side block key to activate the relocated "Ins/Del/etc." functionality of these other blocks. Hopefully this functionality is also easy to implement in QMK.

Most everything that I did in Vial should be easily reproducible in QMK. You would just have to make QMK JSON files that mimic the same layout I made.

The one thing that would not be possible to do just by creating a JSON file is the double-zero (00) key on Option #4. That requires a macro. VIA and Vial have built-in support for defining macros and assigning them to arbitrary keys, and those macros are included in the JSON export that VIA/Vial produces when you save your layout to a file. From what I've been able to gather, though, regular QMK cannot have macros defined in JSON. To define a macro with QMK, you have to write the C code for that macro and put it in the keymap.c file for that layout. So to build a QMK hex file for right block option 4, you would not be able to just 'qmk compile option4.json'. When you run 'qmk compile' and feed it a JSON, what it's actually doing is generating a temporary/throwaway keymap.c file on-the-fly (using the information from the JSON) which then gets fed to the C compiler. So you can't both have a JSON for your key layout that you feed to the QMK compiler script and also include a custom keymap.c with your macro(s). It's one or the other. So you would have to have an entirely different workflow for generating the option 4 hex file than for all of the other hex files.

[sedevidi]

I had no idea AZERTY required Shift to be applied to get numbers from the top row number keys!

Yes, that Shift+numrow is ugly. We can type SOME accented characters without any modifier though... And some punctuation too, which is nice. AFNOR (french normalization) is designing a new AZERTY layout to solve those issues, but I don't see any desire from manufacturers to follow...

Just to be clear: you have "Num Lock" key set to TG(1) on layer 0, but set to actual Num Lock on layer 2, so you have to press both NumLock followed by Fn+NumLock to get numbers from the keypad? (After you do Fn+NumLock once though, it should remain enabled, so then you can toggle back and forth between numbers and nav commands just by pressing NumLock?)

That's exactly it. I also added a desktop extention that show the lock statuses (num, caps). In theory, numlock should always be ON since boot, but I needed the key there, just in case (and used it once).

You actually don't need to do all this to get working pseudo-NumLock, even with French AZERTY. You can have single keys send modifiers along with the assigned keystroke, so instead of using keypad 1, you can use top row 1 but have Shift be applied to it automatically so that you get a number. You don't even need to use macros to do this.

Here is a screenshot of Vial configured with a numpad layer without requiring "real" Num Lock that I think should work for AZERTY:

I was wondering what those buttons were for in the Vial interface! I just tested this layout, and it works. I'll report if I see any practical issue in the long run.
I still have numpad numbers on layer2, just to be able to compare if need be.
I also still have some numpad keys on my semi-number-right-block (layer1, without Fn): numpad enter, +, - (plus * and / on layer2 instead of "Reset").
I located "Reset" on Fn+Esc, and removed haptic keycodes.

One thing that wasn't clear to me when I was putting together this example is how AZERTY handles the full-stop (.) key on the numpad. I thought France used decimal commas, but every example picture I could find of an AZERTY keyboard shows a period key in the numpad area instead of a comma. Does that key actually output . or does it output , even though the legend on the keycap is a . ?

Ah, that's another ugly thing! The mapping to "," is at application level. Some application do, some don't... Gnome calc does not convert "." to "," but interprets them the same. Libreoffice Calc needs a regular "," for number, but does not convert numpad-".", but I think Microsoft Excel does. Maybe there is a checkbox somewhere in Libreoffice to hack this, that I didn't look for. I vaguely remember that Libreoffice did the substitution for me some time ago... And any actual computer code need "."...

In my example from above, I put the regular comma key in that spot. But if you want it to output a period/full-stop instead, then you can substitute as appropriate. On AZERTY it appears that . is achieved in the alpha block area by Shift+; so you will have to apply Shift modifier to that key just like with all of the numbers. However, since QMK is QWERTY-centric internally, and since the ; and . key on AZERTY is in the same place as the < and , key on QWERY, you need to set that to KC_COMMA to get the right key. Thus the full key definition would look like this with the Shift modifier applied:

I forgot that this was one of the good thing of a fully programmable keyboard, and just did this. Thanks! I'm not sure it's practical for my usage though...

Attached is my new improved layout, based on all your valuable input. I discover QMK and Vial, and would not have been able to do that without reading a lot of doc, or your posts

Nota to everyone: using Vial is a real joy, as it allows to really modify the keyboard settings in real time. Just a change a key, and use it. Save the config in a file if need be, but Vial will read the whole settings from the keyboard upon startup.

[Muirium]

The symbol row is actually my favourite thing about Azerty. Perhaps the only thing, come to think of it.

[Ellipse]

Thanks NathanA for the ps/2 feedback! That is good to know.

Here is a nice photo (shared with permission) of the Industrial Gray keyboard with the Industrial SSK 12 key set and a right side block arranged in an alternative way.

ISSK - Copy.JPG (2.47 MiB) Viewed 24869 times

[U47]

So, without trying to spelunk through the hundreds of pages in this thread, what is the reason the QMK source code for the new model Fs isn't included in the QMK repository?

Pretty off-putting to have to hunt through forums to find directions pointing to an off-brand "beta" QMK Configurer website just to download the source.

(Also, the default F77 firmware which shipped with my board didn't support the solenoid. I would've expected that to be spelled somewhere in the manual in bold font.)

[NathanA]

So, without trying to spelunk through the hundreds of pages in this thread, what is the reason the QMK source code for the new model Fs isn't included in the QMK repository?

Pretty off-putting to have to hunt through forums to find directions pointing to an off-brand "beta" QMK Configurer website just to download the source.

The reason is because the ***QMK authors*** have refused to merge in the support for the new model Fs. Not because it hasn't been tried or has been withheld from them. Apparently there are parts of how it is written that don't meet their coding standards, and they want it refactored in particular ways before it can be considered for inclusion in the official tree. As the programming side of this project is basically a 100% volunteer effort, that just hasn't been finished yet.

Also, the links to both the separate web QMK Configurator as well as the repository for the fork have both been in the manual for months now.

(Also, the default F77 firmware which shipped with my board didn't support the solenoid. I would've expected that to be spelled somewhere in the manual in bold font.)

This just isn't even close to true, which is why no such thing is spelled out in the manual or anywhere else.

[Shihatsu]

Shihatsu regarding your suggestions, as noted a while back there was an issue with the countersunk holes breaking through the original prototype. Overall they weakened the board as they could not be screwed in tight enough to avoid a gap between parts of the compact case. The new design with exposed screws fixed that issue. However I will note that with the more recent beam spring project those screws are countersunk and I have not seen the same issues appear. However the compact case design has been finalized with the current design, which uses custom-made torx screws from brand new molds that have already been produced. Regarding the tilt there are bumpers of varying heights that can adjust the angle of the board. I have no plans to recreate the molds for additional IBM style supports, though maybe some folks could design some 3d printed options? I recall one or two projects with 3d printed feet for the new Model F keyboards.

Totally understandable and transparent - as always, thank you!
Having some feed will be good, but this will also trigger my search for perfection. I will try to find someone who will make an angled backplate. Would it be possbile to provide some CAD files for the current bottom plate of the ultra compacts? That would make things far more easy for me...

[gipetto]

PS/2 support for xwhatsit controller:

How easy would it be to adjust the current controller to make a dozen or so ones with this chip instead of the ATMEGA32U2 chip? Per pandrew: this chip has "16k of flash memory. Qmk firmware currently uses around 22k. That's not to say it's impossible. It's probably possible to strip away many QMK features and get it working, but it won't be great."

I think the tradeoff in some additional functionality would be worth it to the folks who strongly prefer PS/2 connectivity.

All you need to do to enable ps/2 support is to find two unused gpio pins on the atmega32u2 chip. you can route them to a jst header on the pcb, ideally the same as the usb cable uses, so when the user wants to use ps2, they hook a cable up to that header. there might be a few extra discrete components that ps2avr boards use that but you get the idea.
then you have the mammoth task of integrating capsense into the ps2avr firmware.
If there are no free pins available then there may be speaker pins that can be repurposed for instance