Underglow overlays for nice_nano don't work on nice_nano_v2

[Nicell]

The existing nice_nano.overlay/confs for shield underglow don't apply to the nice_nano_v2.

We might want to instead make general spi definitions in the shield DT for &pro_micro pins.

[malinges]

Zephyr seems to support board revisions, maybe that could help?

• https://docs.zephyrproject.org/latest/guides/porting/board_porting.html#multiple-board-revisions
• https://github.com/zephyrproject-rtos/zephyr/pull/29990
• https://docs.zephyrproject.org/latest/application/index.html#building-for-a-board-revision

[malinges]

I just got it to work, it's pretty easy actually once you figure out the filename conventions: malinges/zmk@08674fc7d20ebda4bc1fb0729e6865694ba88d65 You can then build for a nice!nano v2 with west build [-p] -b nice_nano@2 [...]. And last but not least, RGB underglow actually works with the resulting firmware (tested on a reviung41). I'd be happy to submit a PR if you think it's a good idea.

[Nicell]

@malinges board revisions seem neat! I'm a bit worried about backwards compatibility however with how we currently have them set up. I'm not sure if it's possible to redirect a board name to another board+revision.

[malinges]

@Nicell agreed, the main issue with this approach is that it's a breaking change. Unless it's possible to create some kind of board alias, but I don't have enough experience with ZMK/Zephyr to know if it's even possible (and a quick Google search doesn't come up with anything promising).

But yes, I quickly chatted about this being a breaking change on Discord (#boards-shields) and a few people seemed (legitimately) concerned about it too. Although maybe it's less of an issue for the nice!nano v2 since it's only been supported by ZMK for around 1.5 month? ;-)

As a last resort, do you think it could be possible to duplicate the nano v2's definitions for a given deprecation period, then get rid of the old defs once the deprecation period "expires"? Unfortunately I'm not familiar enough with ZMK's development process to know what would be a satisfying solution here.

[malinges]

Interestingly, Zephyr has both a board alias system and a board deprecation system.

The board deprecation system doesn't help since it doesn't look configurable from the application side (so ZMK can't add its own deprecated boards to the list).

The board alias system however is configurable and, using a little trick, can be used to override the board revision too! The only downside is that it requires the path to the board aliases file to be specified through an environment variable (because the whole system is meant as a developer productivity shortcut, not a board deprecation system, since this already exists). Not sure if this could be integrated cleanly into ZMK. But still, it works:

root@8b04e556a95c:/workspaces/zmk/app# ZEPHYR_BOARD_ALIASES=./board_aliases.cmake west build -p -b nice_nano_v2
[...]
-- Aliased BOARD=nice_nano_v2 changed to nice_nano
-- Board: nice_nano_v2, Revision: 2.0.0, Shield(s): reviung41
[...]
-- Found BOARD.dts: /workspaces/zmk/app/boards/arm/nice_nano/nice_nano.dts
-- Found devicetree overlay: /workspaces/zmk/app/boards/arm/nice_nano/nice_nano_2_0_0.overlay
-- Found devicetree overlay: /workspaces/zmk/app/boards/shields/reviung41/reviung41.overlay
-- Found devicetree overlay: /workspaces/zmk/app/boards/shields/reviung41/boards/nice_nano.overlay
-- Found devicetree overlay: /workspaces/zmk-config/config/reviung41.keymap
[...]
Wrote 342016 bytes to /workspaces/zmk/app/build/zephyr/zmk.uf2
root@8b04e556a95c:/workspaces/zmk/app# 

[malinges]

To sum everything up, here are the 3 available options AFAICT:

• require users to manually define the RGB-related DT bits (spi1 and led_strip) in their .keymap file (current situation)
• duplicate RGB-related DT configuration in both nice_nano.overlay and nice_nano_v2.overlay
• use Zephyr's board revision system, which is made for this purpose and would get rid of duplication, but would be a breaking change (requiring users to compile with -b nice_nano@2 instead of the current -b nice_nano_v2) - it would also set a precedent as other ZMK boards with multiple revisions (like the nRFMicro) don't currently use this system either

[auipga]

I just included the nice_nano.overlay on my nice_nano_v2 powered kyria.

#include <../boards/shields/kyria/boards/nice_nano.overlay>

[Poent]

Could someone detail the process for implementing the manual workaround for this? I've got a corne running off the Nice!Nano v2 and believe that I am seeing the same issue described here (RGB underglow not working). How would I go about manually defininf the spi1 and led_strip details in my keymap file, as recommended by @malinges?

[Ardakilic]

@Poent This is what I did for Reviung 41:

https://github.com/Ardakilic/zmk-config/blob/master/config/reviung41.keymap#L12-L47

I simply copied the contents of the overlay file to my keymap

[killua99]

Hi, just to bring this topic active again, this method isn't working for Sofle RGV v2.1 with nice!nano v2 my compilation break and when I use this SPI1 lines, it didn't enable the underglow either

[infused-kim]

@killua99 I have created a PR that adds underglow to the sofle, but it hasn’t been merged yet.

You can find the PR and the fork here: https://github.com/zmkfirmware/zmk/pull/1188

I have also created a separate fork that has many other enhancements for the sofle.

You can check it out here:

https://github.com/infused-kim/zmk-config-sofle

[killua99]

@infused-kim thanks for sharing this, I did try https://github.com/killua99/zmk-config/actions/runs/2074274430 but not luck. I'm starting to think is soldering issues rather firmware. I follow some guide https://docs.beekeeb.com/build-guide/sofle-rgb-v2.1-soflekeyboard-build-log-guide-with-photos#rgb-leds-for-the-right-hand to sold the leds but I not sure if that is correct.

I'll keep trying builds and resold some leds to try it out.

[maximus5684]

@killua99 / @infused-kim Are either of you using the version of the Sofle purchased from Keyhive? This is the one I have and it is very non-standard. I'm working on adding the board to ZMK and enabling as many features as I can (currently key grid is fixed and underglow LEDs are working). If either of you have this board and are interested, let me know and I'll post a link to my fork.

Regarding the options above, my preference/recommendation (take with a grain of salt because I'm new here) would be for duplication for a deprication period.

[killua99]

@maximus5684 from beekeeb I read the warning about the Keyhive version, I'm not sure if beekeeb sells that version.

[killua99]

The Sofle maintainers opened an issue about ZMK firmware support. https://github.com/josefadamcik/SofleKeyboard/issues/142

[Xoffio]

I Think this issue can be close. We should have a note on the documentation page for new people. I took the time to added and it just need to be merge.

[KLingO-MS]

Does anyone else have problem with RGB underglow after ZMK swtiched to new Zephyr and pincontrol syntax ? This is how my nice_nano_2.overlay looks like - it build but does not turn on RGB .. it is based on old syntax that worked well on reviung41 (in old I had this SPI config inside keymap file .. like in the comments above)

`#include <dt-bindings/led/led.h>

&pinctrl { spi1_default: spi1_default { group1 { psels = <NRF_PSEL(SPIM_SCK, 0, 5)>, <NRF_PSEL(SPIM_MOSI, 0, 6)>, <NRF_PSEL(SPIM_MISO, 0, 7)>; }; };

spi1_sleep: spi1_sleep {
    group1 {
        psels = <NRF_PSEL(SPIM_SCK, 0, 5)>,
                <NRF_PSEL(SPIM_MOSI, 0, 6)>,
                <NRF_PSEL(SPIM_MISO, 0, 7)>;
        low-power-enable;
    };
};

};

&spi1 { compatible = "nordic,nrf-spim"; status = "okay";

pinctrl-0 = <&spi1_default>;
pinctrl-1 = <&spi1_sleep>;
pinctrl-names = "default", "sleep";

led_strip: ws2812@0 {
    compatible = "worldsemi,ws2812-spi";
    label = "WS2812";

    /* SPI */
    reg = <0>; /* ignored, but necessary for SPI bindings */
    spi-max-frequency = <4000000>;

    /* WS2812 */
    chain-length = <11>; /* arbitrary; change at will */
    spi-one-frame = <0x70>;
    spi-zero-frame = <0x40>;

    color-mapping = <LED_COLOR_ID_GREEN LED_COLOR_ID_RED LED_COLOR_ID_BLUE>;
};

};

/ { chosen { zmk,underglow = &led_strip; }; };`

[caksoylar]

I believe this issue is resolved in practice by #1499 since Pete added v2 overlays for every shield that has a v1 overlay.

[spacemishka]

Does anyone else have problem with RGB underglow after ZMK swtiched to new Zephyr and pincontrol syntax ? This is how my nice_nano_2.overlay looks like - it build but does not turn on RGB .. it is based on old syntax that worked well on reviung41 (in old I had this SPI config inside keymap file .. like in the comments above)

`#include <dt-bindings/led/led.h>

&pinctrl { spi1_default: spi1_default { group1 { psels = <NRF_PSEL(SPIM_SCK, 0, 5)>, <NRF_PSEL(SPIM_MOSI, 0, 6)>, <NRF_PSEL(SPIM_MISO, 0, 7)>; }; };

spi1_sleep: spi1_sleep {
  group1 {
      psels = <NRF_PSEL(SPIM_SCK, 0, 5)>,
              <NRF_PSEL(SPIM_MOSI, 0, 6)>,
              <NRF_PSEL(SPIM_MISO, 0, 7)>;
      low-power-enable;
  };
};

};

&spi1 { compatible = "nordic,nrf-spim"; status = "okay";

pinctrl-0 = <&spi1_default>;
pinctrl-1 = <&spi1_sleep>;
pinctrl-names = "default", "sleep";

led_strip: ws2812@0 {
  compatible = "worldsemi,ws2812-spi";
  label = "WS2812";

  /* SPI */
  reg = <0>; /* ignored, but necessary for SPI bindings */
  spi-max-frequency = <4000000>;

  /* WS2812 */
  chain-length = <11>; /* arbitrary; change at will */
  spi-one-frame = <0x70>;
  spi-zero-frame = <0x40>;

  color-mapping = <LED_COLOR_ID_GREEN LED_COLOR_ID_RED LED_COLOR_ID_BLUE>;
};

};

/ { chosen { zmk,underglow = &led_strip; }; };`

RGB needs mostlikly 5V minimum to drive blue leds. But the control pin can be 3V3.