The firmware is going to be moved to QMK

[fredizzimo]

Hi All,

I have started the process of moving this fork from TMK to QMK. For more information check this

This means that process of adding new features will slow down for some time. But on the other hand, I think everyone will be more happy when it's done.

[ec1oud]

Looks like it's going well. I tried QMK, with all your improvements merged in, and it already works about as well for me on the Infinity as it does on the Ergodox EZ, plus of course having LCD and LED support. Congrats on getting so much done in so little time!

I just needed to repeat my hacks to stop the LED animation and get my favorite default brightness level.

[fredizzimo]

Thans @ec1oud,

Yes, the QMK fork, now has about the same level of features as this repository. Which means that the basic works.

Soon the Infinity will be more integrated with the Ez could, so that they can share the same keymaps. The pull request is here.

The rest of the development is a bit slow at the moment, since I finally want to build my own personal keymap, and I'm doing that right now. The development will also slow down for another reason, my summer vacation ends, and I have to return back to work.

But after my keymap I'm planning to integrate unit testing support to QMK. And also the visualizer emulator, which let's you test visualization stuff on the PC. It can be found in the LED branch of this repository, but is completely undocumented, and only works in Cygwin.

Then it's time to finally do the improvements for the visualizer, that I have been planning. I think I might convert it to C++, for more safety, and easier usage. I also want to add support for layers, so that you can overlay effects on top of each other. One example use would be a brightness setting, when you change it the display would temporarily display the new setting, but then soon after fade back to it's previous animation. I also want to make it easier, and safer to pass parameters to the animations when you start them, and that's where C++ again would help to create a better interface.

Further suggestions are of course welcome!

[Skrymir]

Really looking forward to having shared keymaps and some of the nice options the ez firmware has.

Thanks for the work

[ec1oud]

Yes indeed... shared keymaps make my life easier, having both keyboards. Thanks.

OK, you asked for suggestions... ;-) Here's a far-out one.

One of the features from the firmware which was developed specifically for the Infinity is a side-channel (virtual serial port) where it's possible to connect and send commands to do some basic things. So that might be a nice thing to work on, although personally, I was thinking I'd like it to have a Scheme interpreter. Which may sound crazy, but you need some kind of language to be able to send custom messages from the PC to the LCD displays, control backlight colors and LED brightness, run visualizations etc., so rather than making up a language, why not use a language that is already known to have one of the best power/compactness ratios? (I'd use TinyScheme, I've done that in another context before. It only adds kilobytes to an ARM executable. Well, maybe a few tens of KB if memory serves.) Maybe it would then even be possible to upload keymaps that way too: temporarily override the existing one, just to try it out. It would be easier than doing experiments by rebuilding the whole firmware. And if Scheme had the ability to install lambda callbacks on keys and key sequences, and to output to the screen, then the keyboard becomes a mini-computer onto which you could install a custom calculator, mail checker, note-taker, password manager or whatever. It's inevitable, isn't it?

I don't know whether you have the ability to write to flash memory from inside the firmware, though. If not, the programs would need to be volatile, and that's OK too - I could write a udev rule to re-upload my scripts whenever the keyboard is plugged in, or something like that. It's even better for security if uploaded programs cannot write to flash. Otherwise the downside is it becomes too easy for a spy to write a keylogger. OTOH non-volatility is nice to have too. If it could write to flash, the next inevitability is for the keyboard to run a trimmed-down OS, which provides hardware access and process/thread management, and write most of the actual functionality in Scheme.

And now you know why I have dedicated parentheses keys on my keymap... I don't write Scheme every day, but when I do, I prefer Ergodox. ;-)

Ah well, no hurry, I might try it myself some day if I ever find the time to understand ChibiOS and the existing firmware well enough.

[fredizzimo]

The idea of having a dedicated language is definitely an interesting thought. However, I think that scheme might be a bit hardcore for most users that want to write visualization code.

Controlling the keyboard from the PC, is not the first thing on my TODO list either, but contributors are welcome, since IMO, the keyboard should be pluggable into any computer and just work.

But anyway if I would do it, I would take the following approach. We don't need a language, as we basically need to do only the following things.

1. Change the LCD backlight color
2. Send a monochrome image with the new LCD contents
   3 Send a gray scale image with the new LED contents

The speed of the USB port is more than good enough for that. We would then need a host software/driver which connects to the keyboard. Then it could act as a webserver accepting standard json request, converts them to binary for USB transfer, and the keyboard then interprets them. With this approach you could write the software on the PC side using any programming language.

The emulator software, which I mentioned above could also be written so that it sends the same commands to the keyboards. This way you could write everything in the emulator, the keymap and visualization, and never have to upload the flash of your keyboard.

[leshow]

I recently flashed the QMK firmware and my LCD screen is not working at all. Was this ever integrated into QMK?