Compile errors for the Lotus

[DorjeDorf]

Hi,

If I read correctly, the QMK was changed a while back and it seems your code for the Lotus58 might be incompatible with the new build.

Is there any chance you could review the code and possibly update it or help guide me to where I can fix the problems I am seeing?

This is the output during the compilation. it doesn't matter if I do it in your fork or just files copied to the direct git pull. I had to reenable debug and print to see these.

Thanks ;)

Compiling: keyboards/lotus58/keymaps/default/keymap.c                                              In file included from quantum/action.h:24,
                 from quantum/keymap.h:22,
                 from quantum/quantum.h:21,
                 from keyboards/lotus58/lotus58.h:19,
                 from keyboards/lotus58/keymaps/default/keymap.c:16:
quantum/keycode.h:93:17: error: redeclaration of enumerator 'KC_NUM_LOCK'
 #define KC_NUM  KC_NUM_LOCK
                 ^~~~~~~~~~~
keyboards/lotus58/keymaps/default/keymap.c:27:5: note: in expansion of macro 'KC_NUM'
     KC_NUM,
     ^~~~~~
quantum/keycode.h:321:5: note: previous definition of 'KC_NUM_LOCK' was here
     KC_NUM_LOCK,
     ^~~~~~~~~~~
keyboards/lotus58/keymaps/default/keymap.c:166:6: error: conflicting types for 'oled_task_user'
 void oled_task_user(void) {
      ^~~~~~~~~~~~~~
In file included from quantum/quantum.h:184,
                 from keyboards/lotus58/lotus58.h:19,
                 from keyboards/lotus58/keymaps/default/keymap.c:16:
drivers/oled/oled_driver.h:290:6: note: previous declaration of 'oled_task_user' was here
 bool oled_task_user(void);
      ^~~~~~~~~~~~~~
 [ERRORS]
 |
 |
 |
make[1]: *** [.build/obj_lotus58_default/keyboards/lotus58/keymaps/default/keymap.o] Error 1
make: *** [lotus58:default] Error 1
Make finished with errors

[TweetyDaBird]

Unfortunately, it seem QMK are going through a series of 'breaking changes', so yes the code will need updating. However, it should absolutely work with the fork as is. And I'm unsure how long I can keep updating things, as the QMK main parts keep getting bloated to the point where its soon running out of memory for splits using a Pro Micro if you use any extra features.

Will have a look and update, but unfortunately, as life is right now, it wont be immediate, sorry.

[DorjeDorf]

Fully understood and thank you :) I know the issue is visible on a Mac (even with a direct copy of your whole github repo).

I tried to compile the code on a very old QMK branch on Windows (just copying the config) - compilation worked, but bricked the arduino (had to reflash the bootloader).

I'll also chip away and will try to figure this out.

[RagingCactus]

I'm currently building a Lotus58. I have a basic firmware running now, but also very liberally changed the existing code.

I might release it when it's cleaned up a bit, but your specific problem is that void oled_task_user(void) was changed to bool oled_task_user(void).

Change it to this:

bool oled_task_user(void) {
    if (is_keyboard_master()) {
        print_status_narrow();
    } else {
        render_logo();
    }

    return false;
}

Caveat: I don't really know what I'm doing in QMK, I'm just learning as I go

[hundredfire]

I managed to compile a working firmware with the latest build of QMK (0.17.0) by modifying some parts that showed errors while compiling:

• removing the 'keycount' line in info.json
• removing the define NO_DEBUG, define NO_PRINT, define NO ACTION_MACRO and define NO_ACTION_FUNCTION in config.h (or just putting them in comments)
• renaming all mentions of layer _NUM to _RAISE and changing custom keycode KC_NUM to KC_RAISE in default/keymap.c (conflict with a new keycode called KC_NUM described in quantum/keymap.h
• Implement @RagingCactus change to void oled_task_user(void)
• At this point, if you try to compile, you will end up with a .hex that is slightly oversized, so I added 'LTO_ENABLE = yes' to my rules.mk

I started to meddle with QMK since just a few days ago, so I have no idea what these changes imply, but now it compiles without error. And both sides of the split work well after flashing. It even somehow managed to make my rotary encoder work, while it wouldn't with the default build provided in this repo.. weird? I'm not even sure how to request a pull from my local repo, so I won't be of much help. I would be glad if it could help just a little bit though Anyways, here is a zip :

lotus58.zip

[RagingCactus]

Seeing there is considerable interest here I will try to finish my firmware (LED positioning data is still wrong, latest QMK actually uses that for the heatmap effect for example) and put it up in a repo. I have a working LED matrix with typing effects and I'm already using my Lotus58 as a daily driver. I just have to fix the positioning data and tidy up keyboard vs keymap configuration a bit.

I'll make a note and hopefully finish it in the coming week.

[RagingCactus]

@hundredfire @DorjeDorf

See https://github.com/RagingCactus/qmk_firmware/tree/ragingcactus-develop/keyboards/lotus58 for my firmware. It contains variants for both the Pro Micro and RP2040 microcontroller boards.

Because of that, it is based on QMK upstream develop branch. Feel free to use what you can!

Edit: Rebased onto upstream stable, see https://github.com/RagingCactus/qmk_firmware/tree/ragingcactus-stable/keyboards/lotus58

[zdpkoszur]

Comment edit - works! :) Thanks to all of you guys here. Tweety's code works too ;)

[TweetyDaBird]

My code was updated a fair while ago if you want to use that

[RagingCactus]

@zdpkoszur I fixed this in my fork: https://github.com/RagingCactus/qmk_firmware/commit/4999b32b5a03b7e1e680d352d90f086fee1a6232

    Lotus58: Specify promicro variant as default

    This prevents build errors when not specifying a variant, for example
    when using the following command:

    qmk compile -kb lotus58 -km ragingcactus

    This will now build the promicro variant by default.

    Use one of the following commands to specifically build a variant:

    qmk compile -kb lotus58/promicro -km ragingcactus
    qmk compile -kb lotus58/kb2040 -km ragingcactus

That being said: If you have questions/issues regarding my fork, please direct them to me in the fork repo. I'm just sharing my personal firmware, it is very much "unofficial". I don't want to cause notification spam for the original author because of issues out of their control.

[DorjeDorf]

Thanks guys ;)