Checking version of firmware loaded to keyboard

[piotr-dobrogost]

I apologize in advance if it's not the best place to ask this question but I couldn't find any qmk related forum.

Is there a way to find out what version of qmk firmware is currently loaded to keyboard?

[jackhumbert]

This is the best place to ask :)

Not currently! We've just recently started adopting version numbers for some areas (OLKB boards). What keyboard are you dealing with?

[piotr-dobrogost]

I have ErgoDox EZ and wanted to find out what version of firmware it came with. The reason is that I`m concerned with how dual-role keys work and wanted to make sure I have the latest version before raising issue. The problem is that for those keys to be registered as modifiers one has to wait for the timeout even after pressing some alphanumeric key almost immediately after pressing dual-role modifier. The problem is described at https://input.club/forums/topic/dual-role-keys#post-1989 :

I also want to do that: I’ve got control and ESC together on one key on my Ergodox EZ, so would like to do it on the Infinity Ergodox too. But what I don’t like on the QMK firmware so far is that I have to hold down the key long enough to be recognized as CTRL. If I press another key immediately after, I want it to send control press without waiting, then the next key.

And the answer to this is that tmk can do this https://input.club/forums/topic/dual-role-keys#post-2883 :

It might not be easy, but should be possible since it can be done with tmk on original ergodox. I can do Ctrl-Alt letter using dual role keys for Ctrl and Alt.

I've been searching for issue/pr where dual-role keys were discussed/introduced but there's no such one (https://github.com/jackhumbert/qmk_firmware/issues?utf8=%E2%9C%93&q=dual)

I've found this tmk issue https://github.com/tmk/tmk_keyboard/issues/49 and as qmk is a fork I wonder if you implemented this feature yourself or does it come from tmk?

ps. I'm typing this from EZ and it's so frustrating to keep looking for all those keys in their new places...

[eltang]

@piotr-dobrogost Check #142! Correct me if I'm wrong, but based on your description I believe that's the issue you're having.

[piotr-dobrogost]

@eltang Yes, it looks like this is the same as #142 (thanks for info) so this issue is now only about reading firmware's' version from keyboard.

[ezuk]

@piotr-dobrogost - reading the firmware version isn't possible (because there are no version numbers per se). But I can tell you that #142 was never made into a PR, so the change isn't reflected in the keymap settings. Would you like to try playing with that constant yourself and seeing if it helps? Are you all set up with a build env?

[piotr-dobrogost]

Let's move discussion about behavior of dual-role keys to #142.

[eltang]

I just found a print_version function in command.c, but I'm not sure if it's what you want (not being sure what it does might contribute to that).

[cbbrowne]

It's kind of an interesting idea; I imagine an implementation might look like having a key that, when pressed, reports the git commit hash of the version that you're running.
That would mean that "make" would need to capture the latest commit (and perhaps indicate, a "oops, that was a dirty branch, as it had code that wasn't checked in") and compile it in, along with a key binding to pull it out. A git commit number isn't exactly the friendliest piece of information; if someone can suggest something better, I'm all ears. FYI, this suggests the need to have a function/macro that can receive a string and make the keyboard emit keystrokes for all the characters found in the string. Given that, you could do more than merely have a git commit number.

[eltang]

@cbbrowne Such a function was recently created. Check it out here.

[jackhumbert]

Yeah, the latest commit hash would certainly point people in the right direction. That would be trivial to pull from git, but it would only work in copies of the firmware that were cloned (not downloaded), I believe.

Commit hashes are the only real thing that would be useful in relation to the repo - you could do build numbers in-between commits, but that's pretty localised.

[cbbrowne]

Ah, wonderful! That lets me simplify my keystroke that types out "cbbrowne" :-)

https://github.com/cbbrowne/qmk_firmware/commit/2fe06e4ef53f380eee6e91ece44f6a385ec32c2c

And yeah, the git hash only directly helps if you built out of a git repo. If you're doing your own thing out of something else, you'd need to capture some other piece of information. Actually, I'd say you need more than just the commit hash; you need to know which keymap it was, too. The point is kind of to start that conversation, figure out what is meaningful as indication of version.

[jackhumbert]

Saving the keymap file that's being compiled would be awesome! I'm sure we could store the datetime as well. Maybe that info, along with an optional git hash - very useful :)

[algernon]

It'd be reasonably easy to capture the keyboard and the keymap from within the makefile, and turn it into a define, and add a git hash if in a git checkout, or a timestamp otherwise, and let keymaps make use of that information. It would also make sense to make it possible to have a separate QMK version and a keymap version - eg, a keymap can remain unchanged while QMK changes, yet, bugs can still be fixed. Likewise, QMK can remain largely unchanged, but the keymap may change incompatibly (this assumes the keymap is not in the QMK repo, mind you, otherwise the git hash would change anyway).

Something like this, as the end result, would be very nice imo:

#define QMK_VERSION "g25d4772754186b8ab6ef86c28049da67a460f123"
#define QMK_KEYBOARD "ergodox_ez"
#define QMK_KEYMAP "default"
#define QMK_KEYMAP_VERSION "1.4"

If not in a git repo, either the build time, or the timestamp of the top-level directory could be used as a version, perhaps.

[piotr-dobrogost]

There's the question How can I get my C code to automatically print out its Git version hash? at Stackoverflow with an answer showing how to use git describe to get information on revision.

[jackhumbert]

Thanks @piotr-dobrogost! And thanks to @algernon, this has been merged with #408 :) here's the example mentioned:

SEQ_ONE_KEY (KC_V) {
  SEND_STRING (QMK_KEYBOARD "/" QMK_KEYMAP " @ " QMK_VERSION);
}

[piotr-dobrogost]

Thank you all for bringing this feature to life. I hope it will find its way to the default keymap of ErgoDox EZ.

[ezuk]

Reopening because I want to put this into the default firmware.

[ezuk]

Done! This is now in the default layout. Thank you, @piotr-dobrogost and @jackhumbert! Very awesome.

[piotr-dobrogost]

Thanks @ezuk. Will this feature be shown on Default Firmware Keymap at https://ergodox-ez.com/pages/our-firmware ?

[ezuk]

@piotr-dobrogost the main issue there is that there are already thousands of keyboards out in the wild without this feature, so I don't think I'll be showing it there. It would cause confusion for all of the people who don't have it (which is why I am not modifying the default keymap very often).

[piotr-dobrogost]

@ezuk How about also showing past versions of keymaps and information stating that one can establish what version of firmware is loaded only starting from version X of firmware which started to be loaded into keyboards sold after date Y?

[ezuk]

@piotr-dobrogost my experience is that people who care enough about the particular version of keymap they use end up on github anyway. That is a relatively minor (if important) subset of our users. Many customers simply want a really good keyboard, and are happy to pull it out of the box, plug it in, and go. I am really trying to keep their lives simple.

IMHO if I went to a website and tried figuring out how this thing works and saw a versioning note like that it might turn me off a little bit -- make it seem intimidating or complicated.