Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Saving Layers fails under strangely specific conditions #31

Closed
elkowar opened this issue Jan 17, 2020 · 11 comments
Closed

Saving Layers fails under strangely specific conditions #31

elkowar opened this issue Jan 17, 2020 · 11 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@elkowar
Copy link

elkowar commented Jan 17, 2020

The Bug

I've found a very strange bug that can happen when configuring secondary layers

Reproducing the Error

My current setup is:
layer 0: a mildly modified version of the default german Layer 0
Layer 1: a mildly modified version of the default Layer 1
Layer 2: a Layer with some navigation and special characters

When setting one of the Thumb-keys in Layer 0 to xxx whilst having set the key to transparent in Layer 1, as soon as I try to store that configuration, the keyboard suddenly disconnects and then reconnects, with the changes lost.
I was not yet able to fully understand when this happens, but it currently seems as tough it

  • only happens with the Thumb-keys
  • isn't strictly about layer 1: when not having ever changed the transparent-config of layer 1, I was first having the problem with Layer 2: as soon as I set the thumb-key to something other than transparent in layer 2, I was unable to set it back to transparent as long as I didn't change the key's config on Layer 0 to be non-xxx

Expected behavior
xxx-configuration should work with transparent, there should not be a keyboard disconnect when trying to save.

Screenshots & log

Log for an attempt to do said configuration

-1579249141649.log

Layer 0, with xxx on thumb-key

(works as long as the key is not transparent on Layer 1)
image

Layer 1

(as soon as i change the < on the thumb-key to transparent and try to save, the keyboard disconnects shortly, resetting the config to the last saved)
image

OS Info

  • OS: Windows 10
  • Bazecor Version: 0.1.0
@elkowar elkowar added the bug Something isn't working label Jan 17, 2020
@algernon
Copy link

Can you open the developer console (Ctrl+Shift+I) before saving the layout, reproduce the problem, and see if there are any errors present there?

@elkowar
Copy link
Author

elkowar commented Jan 22, 2020

there are no errors in the developer-console for me

@bagukiri
Copy link

Hello I have the same issue and here's my developer console log.

It happens when I try changing a color on a key on layer1 (or any layer for that matter). Changing the keybinding still works.

image

@bagukiri
Copy link

Found a workaround. Duplicating layer1 to a different layer and overwriting the original seems to restore my functionality.

algernon pushed a commit that referenced this issue Feb 28, 2020
@alexvy86
Copy link

alexvy86 commented Sep 3, 2020

I just ran into a very similar problem. I tried narrowing the setup that causes it, and so far what I have found is that if I try to set my right-side bottom-most thumb keys to Right Ctrl and Right Alt on Layer 0, and set both of them to Transparent on Layer 1, when I try to save the configuration then the saving icon keeps spinning indefinitely and the keyboard stops working altogether. The dev tools console shows a couple of logged messages, and eventually a "Communication timeout" error:

developer tools log

Here's a gif demonstrating the issue:

bazecor-cant-save-changes

For now my workaround is to set one of those two keys explicitly to the same key that Layer 0 has, but I don't see why setting them both to transparent should cause an issue.

Btw, I'm using Bazecor 0.2.2 on Windows 10.

@alexvy86
Copy link

alexvy86 commented Sep 3, 2020

I just tried restarting the computer with the Raise unplugged, like the workaround here suggests, but it didn't help.

@alexvy86
Copy link

alexvy86 commented Sep 9, 2020

I've managed to reproduce this at will with a specific change to one of my layers. Most of the keys in that layer are black (code 11). If I change any key to one of the first 10 colors in Bazecor (so any single-digit code, 0-9) then trying to save those changes hangs.

Here are some logs from Bazecor's developer console for several attempts. In the failure cases, only 4 focus.request messages are logged, and then Bazecor hangs (and the keyboard becomes completely unresponsive until I disconnect and reconnect it). With a diff-app I can see that the only difference in that message is the 1vs2-digit color code (see screnshot below).

color 11 - success
color 10 - success
color 3 - failure
color 0 - failure
color 9 - failure

image

@AlexDygma
Copy link
Member

Hello @alexvy86

I'm trying to reproduce your issue and im not able to, can you please check if with the newer version of Bazecor v0.2.4 do you still have the same problem?

Thanks in advance!

@AlexDygma AlexDygma self-assigned this Nov 12, 2020
@AlexDygma AlexDygma added this to the 0.2.5 milestone Nov 12, 2020
@alexvy86
Copy link

I just saw the new release earlier today, I'll try again after I download it and update this issue.

@alexvy86
Copy link

I can confirm neither of my issues happen anymore with Bazecor v0.2.4 😃. I can set several of my T# keys to transparent instead of hardcode the same configuration as the layer below (issue 1) and apply colors correctly to the keys in the all-black layer that I used for issue 2. Thanks @AlexDygma !

@AlexDygma
Copy link
Member

I can confirm neither of my issues happen anymore with Bazecor v0.2.4 😃. I can set several of my T# keys to transparent instead of hardcode the same configuration as the layer below (issue 1) and apply colors correctly to the keys in the all-black layer that I used for issue 2. Thanks @AlexDygma !

Glad it works for you! 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants