search

fredizzimo / infinity_ergodox

Unofficial keyboard firmware for Input Club's Infinity Ergodox
GNU General Public License v2.0
61 stars 16 forks source link

The link to the computer has to be connected to the left hand #2

Closed fredizzimo closed 8 years ago

fredizzimo commented 8 years ago

Currently the computer link has to be connected to the left hand. It would be possible to make the link the other way, through a define for example.

kwkroll32 commented 8 years ago

I would appreciate if the right side could be the master half.

Is the ergodox infinity capable of dynamically assigning master/slave, allowing it to be left- or right-side dominant by swapping cables and without re-flashing?

fredizzimo commented 8 years ago

Hi,

Unfortunately the Infinity Ergodox doesn't have any direct hardware way to detect which half it's running on. It would have been nice if a pin could have been set to high or low for example.

But fortunately there's three options

  1. Do as the official kiibohd firmware, use a separate flash for the left and the right half. In this case you need to flash both halves with a different firmware. It would allow dynamic switching of the cable.
  2. Add a define to to the makefile, and therefore to the make command line, for example make RIGHTHANDED=yes. This would not allow dynamic switching, if you want to switch the sides, you have to recompile the firmware.
  3. Store the side in the EEPROM. This is the most flexible option, and would allow dynamic switching. There would be a key that you can map, which would switch the sides, and save it in EEPROM. After that value is saved on both sides, you could dynamically switch the the cable, and the special key does no longer need to be mapped. Alternatively I could implement a console command that could be used for switching the sides, but the console command support is currently not customizable from the keyboard side of TMK, so some additional work would be needed for that.

I would like to implement 3. But I would have to work with @tmk on the eeprom API as described here https://github.com/tmk/tmk_keyboard/issues/304, as I would want a future proof way of saving EEPROM values.

I can easily implement 2., probably already tomorrow. If you want 3. you have to wait a bit longer, but I'm planning to start working on the EEPROM stuff quite soon, so maybe not for too long.

bremoran commented 8 years ago

I would be happy with 1. I think that you could probably do like the official firmware and build both halves at once in the makefile by adding a few extra targets.

fredizzimo commented 8 years ago

I'm sorry, I did't have time do this yet. Most of the last weekend went into finalizing this https://github.com/tmk/tmk_core/pull/19. I would like to get the the tmk_core updated, so that I don't need a custom version for this keyboard.., it has been a long process, which started already when I started my fork, and we are still not in a place where both me and @tmk are happy.

Hopefully I will have some more time this weekend though.

I still think I will do .2 as it's almost the same effort to implement as 1. But it has the advantage that you don't need to compile the firmware twice with different settings if you want to switch the halves, it would be enough to compile it once, and upload the same to both halves.

fredizzimo commented 8 years ago

I have now added support for this, in commits 991de51a46f9554e004f2a0999f7f2b98c32e210 and 4c85c34773f9dab587b0a214c652081d4077a63f