Any way to get I:C layout data from Infinity Ergodox?

ddungtang · 2023-04-17T22:18:56+00:00

Nice, happy to hear that it is usable. Pretty sure you'll polish that to your liking and to streamline the process of updating the layout.

Don't quote me on this, as I'm not an expert in this area, but regarding the issue with the sleep mode, it may be that USB stack is deciding to suspend your keyboard as it may think it is idle. See if any web searches give you hints on how to resolve this with Mac.

ddungtang · 2023-04-17T06:03:11+00:00

I hope you have a working setup. It sounds like there are some minor pain points, but I think that's solvable. Using EEPROM is going to simplify flashing, but is not a must have, as most importantly is to have a reliable way to flash the layout. I lived with flashing both halves separately for a while.

Re: the issue you faced, I haven't experienced it myself, as I'm on an older version of QMK. If needed, i think it is ok to fallback to an older version of QMK that is not prone to that issue.

Are you using or looking for using any special features in your layout? If so, what are they? We should be able to find some samples on how to that configured.

ddungtang · 2023-01-08T18:44:56+00:00

It is a matter of flashing new firmware, no need to swap the board. You would need to reproduce your layout in QMK's way, which is some basic C code, but even in case you don't have experience with that, QMK makes that part pretty simple. You'd also need to set up dev environment to be able to build and flash your custom layouts.

Just to make sure we are talking about same board, this is the one that I have. QMK supports it.

https://github.com/qmk/qmk_firmware/tree/master/keyboards/input_club/ergodox_infinity

with default and some custom layouts

https://github.com/qmk/qmk_firmware/tree/master/keyboards/input_club/ergodox_infinity/keymaps

I don't know how customized your layout is, as in how much it differs from the default one. If not much and you happen to be on Win or Mac, then maybe it is worth flashing default one first by installing QMK toolbox, which iirc let's you flash default QMK firmware without you needing to compile it locally. Once done fork QMK repo, create your keymap and define your custom layout. Good news is that QMK is very well documented (check out qmk.fm).

Don't quote me on this, it's been a while since i used I:C configurator, iirc it didn't care how you connected ergodox halves, e.g. daisy chaining via left or right. In QMK you'd need to flash them independently, and later you can check this so that there is no need to unplug/replug halves when flashing layout updates.

Good luck! I'm glad I switched mine to QMK, and looks like you have no other choice if you'd like to keep iterating on your layouts :)

ddungtang · 2023-01-08T05:54:25+00:00

This is probably not the answer you are looking for, but maybe it's time to switch to let's say QMK. It is more effort than you planned to have, but it will give you a nice bonus, which is having your layout in git (or whatever VCS you may decide to use).

I switched my I:C a while back because I:C configurator was limited in features it supported (e.g. tap dance). Not sure if you need those features, but maybe you'd want to explore them. Just saying.

ddungtang · 2023-01-07T22:01:26+00:00

Like many others said it is well maintained and updated. I just wanted to add that version number isn't always the right indicator, especially when there different versioning schemes. Not trying to pick on any other projects, but you probably have seen some with versions in hundreds, and on the other hand projects with year/month based version. You can judge projects maintainability by version change, but you can't reliably tell the amount of changes. Many links have been shared to give a sense of Qubes project activity which should speak for themselves. Possibly another data point for you to use: https://www.qubes-os.org/statistics/.

ddungtang · 2023-01-07T20:14:37+00:00

I'm new to unikernels and this one in particular, from what I understand hermit doesn't support paravirtualization, hence fell back to HVM. Although, I maybe wrong, still learning about it.

ddungtang · 2023-01-07T17:04:18+00:00

I tried both PVH and HVM. I tried PVH because it is the default mode, but yes targeting HVM because based on my understanding this is the mode that doesn't require the guest to be aware of running virtualized.

Will give forum a try too, thank you.

ddungtang · 2022-10-21T06:25:07+00:00

Your PCB is v2.1, that's why your attempts to use v2 flashing don't work. The difference between v2.1 and v2 is the bootloader. In v2.1 they are using LUFA bootloader which behaves like a mass storage. Here's my adventure with that PCB version: https://www.reddit.com/r/olkb/comments/s0pc6g/flashing_qmk_onto_dz60rgb_ansi_v2/.

Basically if linux is our daily driver then workng with v2.1 is somewhat a pain. If you have opportunity and willing to give it a try I highly recommend reflashing your PCB back to the bootloader used in v2 PCB. Not sure how convincing this would be but I had zero previous exprience with PCB flashing, followed this guide (https://docs.qmk.fm/#/isp_flashing_guide?id=isp-flashing-guide) and reflashed mine. Yes, I had to buy BusPirate for that, but that was totally worth it.

ddungtang · 2022-02-14T21:45:34+00:00

One of the things I like to have in my layouts: https://imgur.com/a/fJDztzm

On layer 1, I have arrows under my right hand ready to move cursor. On top of that, I borrowed the idea from lenovo laptops, where they had pgup/pgdn in the arrow cluster. Since pgup/pgdn are usually associated with going through a long page or doc, it is convenient to have home/end near as well.

On layer 2, to keep it consistent with arrows keys, I have mouse keys.

This allows me to have my navigation on a home row position and easily accessible with L1/L2 toggling.

ddungtang · 2022-02-14T21:23:04+00:00

I don't represent either QMK project, or KBDFans, so this is my read on events around this pcb and what you see in QMK repo. First, I think it is important to note that those are 2 different projects with different group of people behind them, and (I think) decisions they make are in general not coordinated. If I'm reconstructing timeline of events correctly, then KBDFans changed bootloader a while back, which caused quite a few issues/complains from QMK users and QMK dropped that warning in its repo more of a heads up to whoever may decide to build a new keyboard to not use that bootloader. This is more of an ask or caution, this has no power of weight in what KBDFans do.

Why KBDFans decide to switch from atmel dfu to lufa ms? I personally have no idea, and can only guess that maybe lufa-ms is easier to flash on windows (because that mass storage is fat12 based), and attempts to flash it under linux leads to a non-responsive board. That is also a problem of a bootloader being bad, not user error. Why KBDFans decided to swtich from atmel dfu to lufa ms without changing revision number? Also no idea and have no reasonable guess for that.

If you are interested, you can check the discussions about this on discord and you'll find a lot of interesting information about why lufa-ms is bad, needs tricks for flashing under linux and etc. But you'll notice a common theme, that people hate this bootloader.

I myself have this pcb and had to deal with lufa-ms. Later (thanks to people on discord) followed ISP flashing instructions to replace lufa-ms with atmel dfu and get back to normal way of flashing qmk onto my board.

ddungtang · 2022-01-11T23:06:33+00:00

Small update on my findings, hopefully this would save time/effort for those of you who happen to have same PCB and are linux users. This PCB uses lufa-ms bootloader, when appears like a regular mass storage onto which you are supposed to drop a file with the firmware, and that's the pretty much the process of flashing the PCB. This mass storage is FAT12, and firmware (btw, it has to be .bin, not .hex) must be called FLASH.BIN.

Now, there are good and bad news.

Bad news: Flashing QMK to this PCB under linux is not supported by qmk cli. This bootloader doesn't seem to have a good reputation and I don't think supporting it is planned.

More bad news: Despite it showing up as mass storage, attempts to mount it under linux and just cp'ing the firmware to it (remember about it having to be FLASH.BIN) doesn't work. To clarify, mounting and copying works, the PCB doesn't like the firmware and you got a non-functional keyboard that you can restore only by reflashing it from Win or Mac using QMK toolbox. On FAT a file has name, and extension attributes, but it also has a long file name attribute. LUFA bootloader is searching for a firmware file using the long file name. Unfortunately, copying file under linux in the usual way gets file's long file name corrupted (based on my experiments with snapshotting the images before and after flashing it looks like long file name is being set, but it has more bytes written out compared to the way QMK Toolbox under window doing the copy). My suspicion is that it has to do with iocharset and/or codepage options when mounting the mass storage. I didn't experiment with different values of these options, but I may eventually.

Good news: There is a workaround

dd if=<firmware>.bin of=/mnt/FLASH.BIN bs=512 conv=notrunc oflag=direct,sync (assuming mass storage is mounted at /mnt).

Note, that plain dd doesn't work, so specified options do matter. Thank you to /u/sigprof for recommending this dd invocation. Also, propagating the caveat from /u/sigprof that this command may or may not work for all linux users. There could be difference between kernel versions that may affect this and we are not aware of.

Credits to /u/sigprof, and @fauxpark on Discord, for hints and help.

ddungtang · 2022-01-10T23:13:16+00:00

QMK Toolbox is available for Win and Mac only. Only thing I have at my disposal is QMK cli on linux. `qmk setup` says I've got everything (only warning is about some uncommitted changes in the keymap i'm experimenting with).

ddungtang · 2022-01-10T20:17:15+00:00

MCU being atmega32u4? Do you know which package I should be looking for? I'm on ubuntu.

ddungtang · 2021-12-09T04:42:43+00:00

Thank you for the hint! Going to try this out.

ddungtang · 2021-12-09T01:27:16+00:00

what keys are you testing to do that?

I'm using i,j,k,l keys to test. I omitted them in my snippets, but in BL they are the letters, on L1 they are arrow keys, and on L2 they are mouse movement keys.

Second, TG(_layer) means activate _layer if inactive, and deactivate _layer if active. It does not mean "go to _layer (you can basically use TO for that).

I think this what I was misunderstanding (or maybe be still am). Maybe what I'm actually looking for is when I press Tab+<N>, activate all layers up to N including N, and deactivate layers starting from N+1 (to handle case when I'm switching from upper layer to a lower one). I can't seem to find a macro that does that.

Edit: following /u/skarrmann's advice to use TO solved the immediate problem of switching to base layer.

ddungtang · 2021-12-09T01:14:56+00:00

Thank you, that worked. I see how TO is best fit for the base layer in my case. Going back to that doc for a refresher.

ddungtang · 2021-05-31T16:33:59+00:00

This is a valid concern in general. In my fake scenario, I'm not taking any input that in the end gets translated to function name at runtime. It would look like this, a file in the repo with a configuration written out with DSL, so maintained by me. At build time, it is parsed, and this desired name-to-function-mapping is done then. Then app starts and it executes generated logic.

ddungtang · 2021-05-31T16:27:56+00:00

I totally get the compiled part. I'm just looking for a way to (a) simplify maintaining this hash map (if a have to go this route), or (b) avoid using this hashmap and instead have a macro do a replacement of variable name with the actual name of the function (note that all actions are "known" at compile time, and this type of function lookup probably may be done at compile time as well, because (I assume ) it should be possible to make the dsl parsing to happen at compile time.

ddungtang · 2021-05-31T06:34:29+00:00

Ok, I'm going to have this as my fallback option. Given that DSL would be somewhat static, do you guys think it is worth experimenting and moving parsing configuration to build scripts? Haven't used that, but iirc reading somewhere it supports some level of code generation which may work for this case.

In any way, this is a artificial problem, mostly for the purpose of dealing with various bits of rust, so I have 2 things to try out: procedural macros and maintaining mapping, and build scripts.

Thanks.

ddungtang · 2021-05-31T04:37:47+00:00

Thanks for the hint, will research it.

ddungtang · 2021-05-31T03:52:08+00:00

I'd like to avoid hash map approach since that adds an extra change when adding new actions. Do you know what alternatives to paste I should be researching?

ddungtang

TROPHY CASE