Palette color "6" can not be white

[eikowagenknecht]

Describe the bug Yes, you read correctly, it is this weird.

Also affects other bright colors like ECFCCB. As they become a bit darker, it's fine. #a3e635 works well for example. D9F99D (in between those) is also wrong, but not turned off. It just glows way darker than it should.

Darker colors work, especially RGB are fine.

To Reproduce Steps to reproduce the behavior:

1. Set palette color 6 to white and put it on a key.
2. Notice the key not glowing.

Expected behavior Palette 6 should behave like all the others.

Screenshots Red:

Green:

Blue:

White:

Desktop (please complete the following information):

• OS: Windows
• Bazecor Version: latest

Additional context Using it with a Defy.

[eikowagenknecht]

We just received our second Defy. I can confirm that it also happens there and also with Bazecor 1.3.10 rc2.

And it affects not only color no 6, but also 12 and 16 in the same way.

[GazHank]

I can replicate the issue, and I suspect it is a problem with the Defy firmware rather than Bazecor, my reasoning is that the palette info retrieved from the keyboard displays correctly within the debug console, but any keys mapped to item 6 (array index 5) are unlit. Per the attached screenshot you can see 2 palette items with a full white color, however only one of them is displaying incorrectly on the keyboard.

[eikowagenknecht]

Good reasoning. For what it's worth, both my Defy keyboards are on firmware 1.2.5-beta.

@Dygma: If this is the wrong repository to report bugs for the Defy firmware in, please point to a better one. I've just spent 10 minutes looking through all 44 (!) of Dygma's repositories, and most of them have nothing for the Defy firmware. Some have Defy in the name but Keyboard.io in the description, others don't have a readme. It looks pretty chaotic. This repository here seems to be the only one where issues are reported, but even here I'm not sure if the developers actually go through the issues on a regular basis. I understand that maintaining a product is a lot of work and that Dygma does not have a lot of staff, but from a customer perspective this looks a bit daunting at the moment and does not match the extremely high quality standard that Dygma sets with its website and marketing people.

Sorry to go off topic here, but this has been on my mind for a few days now. Don't take this the wrong way, I love the product and the people behind it seem very invested in delivering something great!

[GazHank]

@AlexDygma is https://github.com/Dygmalab/Kaleidoscope-Dygma the right repository for the firmware, or should we be looking somewhere else?

the firmware in that folder seems to reference a LED-Palette-Theme-Defy plugin (& Colormap-Defy), but the only version I can find is within the https://github.com/Dygmalab/KaleidoscopePuglinLedLibraryDefy repository

So far I can't see anything obvious that would only affect the 6th entry in the array, but I might be looking in completely the wrong place, or at an out of date set of code

[GazHank]

I don't think this is related, but... the comments and the code for memory allocation don't seem to match... the comment suggest adding 2 extra leds per layer, but the following line divides by 2 (halving the led allocation)

https://github.com/Dygmalab/KaleidoscopePuglinLedLibraryDefy/blob/ce4b62aad4bf5ee1575603a13ff34b3244c4cb26/src/LED-Palette-Theme-Defy.cpp#L32

I think either the code or comment is incorrect, but I don't think it is causing this issue... perhaps the divide by 2 is because each entry can store 2 color values (by splitting the uint8_t into 2 pieces)

[alexpargon]

Hey there @GazHank !

I will check this with the FW team, we are preparing a release that fixes the battery issues for tomorrow, so we should be able to add this fix also. let me check with the FW team!!

[alexpargon]

Good reasoning. For what it's worth, both my Defy keyboards are on firmware 1.2.5-beta.

@dygma: If this is the wrong repository to report bugs for the Defy firmware in, please point to a better one. I've just spent 10 minutes looking through all 44 (!) of Dygma's repositories, and most of them have nothing for the Defy firmware. Some have Defy in the name but Keyboard.io in the description, others don't have a readme. It looks pretty chaotic. This repository here seems to be the only one where issues are reported, but even here I'm not sure if the developers actually go through the issues on a regular basis. I understand that maintaining a product is a lot of work and that Dygma does not have a lot of staff, but from a customer perspective this looks a bit daunting at the moment and does not match the extremely high quality standard that Dygma sets with its website and marketing people.

Sorry to go off-topic here, but this has been on my mind for a few days now. Don't take this the wrong way, I love the product and the people behind it seem very invested in delivering something great!

Hello @eikowagenknecht

Indeed we are not on top of the GitHub issues, they receive attention from me (the only one in the SW team for now) occasionally (like once or twice a week) as we have 3 ways of receiving issues, being:

• Discord
• Customer Support
• GitHub issues

I'm not in control of what we work in, that's gauged by the CS team as they engage with the customers and know what is the biggest pain for all of you at any given moment.

They take the time to catalog every issue that appears anywhere but GitHub and reproduce them before pushing them to the "fix" list (if there are important issues here, I also push them to that list), with different priorities following our own strategic risk severity matrix.

And I think you can figure out the rest!

For the repositories, I manage the software ones, the FW team ( 3 programmers ) have been in a rush since we started working on the Defy's firmware, and they have been pressured to make it work, but not to maintain any type of order in the repos, in fact we have to finish the publishing of a comprehensive tool to flash the Defy wireless, all of the GPL parts have been liberated, but we do not have a one-way ticket for you all to compile it, that comes from the fact that some parts of the FW are from Nordic for example, and we have to prepare a repository that holds everything in code and as binary blobs for the non-open parts, and that takes time...

and I think you can figure out the rest again 🤣

Fortunately, we are closing at last several important things, and clarity and accessibility should receive a push in the coming months, for sure we will make the compilation tool for all of you, but the issues will probably still be handled the same way 😅 at least until we have more people in the SW department.

[eikowagenknecht]

@alexpargon, thanks for letting us in on what's going on behind the scenes. Sounds like you've got your hands full, and I hope you're doing well!

So, about juggling all these channels - Discord, email, GitHub, Reddit and the like. For a customer, it can also be a bit of a maze. We might skip reporting issues because we think you've probably got it covered (and we don't want to check all places), or we might just end up repeating what's already out there, adding unnecessary workload for your team. Either way, it's not ideal for you or us.

Have you considered making GitHub the go-to place for both software and firmware issues? Since your customer support team is already evaluating incoming reports, they could create GitHub issues for verified issues. This centralisation would make it easier for users to see what's already been reported and what's being worked on. This could reduce duplicate reporting, effectively reducing your workload.

Using GitHub's features such as projects or milestones could provide transparency on your current focus areas and make customers feel more in the loop. I know I'd like that :-)

Just a few ideas to make things run a little smoother, especially as you're working with limited resources.